Bluetab

an IBM Company

Bluetab

Cómo preparar la certificación AWS Data Analytics – Specialty

by

Cómo preparar la certificación AWS Data Analytics - Specialty

Sergi Lehkyi

Data Engineer

Sobre la certificación

El examen de especialidad AWS Data Analytics se centra principalmente en los servicios de AWS relacionados con datos, cubriendo los dominios:

  • Recolección de datos.
  • Gestión de datos y almacenamiento.
  • Procesamiento.
  • Análisis y visualización.
  • Seguridad.

El examen trata en profundidad los siguientes servicios de AWS:

  • Amazon S3
  • Amazon Redshift
  • Amazon Kinesis
  • Amazon EMR
  • Amazon ElasticSearch
  • Amazon Athena
  • AWS Glue
  • Amazon QuickSight
  • AWS Lake Formation
  • Amazon Managed Streaming for Apache Kafka (Amazon MSK)

*Todos los servicios de datos que puedan interactuar con los anteriores (SageMaker, Backup, Glacier, GuardDuty etc.)

Se puede encontrar más en la página web de [AWS Datalakes and Analytics], también aquí está la [guía oficial del examen] y [preguntas de muestra].

Todo el contenido de este artículo es válido para el examen de 2021. Recomendamos que revises si existe alguna actualización del examen.


Sobre el coste

El coste del examen es de $300 (€270 + 21% IVA si estás en España). Además, si ya has realizado otros exámenes de AWS, obtienes un 50% de descuento en el siguiente, por lo que éste examen sale por solo €163,35. Antes de la prueba oficial se puede hacer un examen de práctica que cuesta $40 (€36 + 21% de IVA si estás en España) y nuevamente, si ya obtuviste cualquier otra certificación de AWS, el coste es cero.


Dónde y cómo

Puedes realizar el examen en línea o ir a un centro de pruebas. Recomendamos ir a un centro de pruebas oficial, principalmente por la estabilidad de la conexión a internet. Es obligatorio el uso de mascarilla en la realización presencial. Sobre la documentación, es importante presentar dos acreditaciones.


Preparación

Con aproximadamente 2 horas al día (seis días a la semana) se puede preparar para el examen en un periodo de 6-8 semanas, siempre contando con experiencia previa en los servicios mencionados.

Recursos útiles durante la preparación:

[AWS Certified Data Analytics Specialty Exam Study Path from Tutorials Dojo] – es una lista bastante completa de temas que debes verificar antes del examen, con algunas preguntas de muestra, hojas de referencia para los servicios de análisis y algunos escenarios comunes en las preguntas del examen.

[AWS Analytics Overview] – un documento técnico con la descripción general de todos los servicios de análisis de AWS.

[Data Lakes and Analytics] – otra descripción general de los servicios de análisis de AWS.

[Data Analytics Fundamentals] – curso oficial de AWS, recomendable para comenzar la preparación.

[Exam Readiness: AWS Certified Data Analytics – Specialty] – curso oficial de AWS que te ayudará a cubrir todos los temas cubiertos en el examen.

[Visualizing with QuickSight] – un plan de estudio para mejorar tu comprensión sobre QuickSight. Imprescindible para dominar la parte de visualización del examen.

[AWS Hadoop Fundamentals] – aunque está un poco fuera de alcance, ayuda a comprender mejor Hadoop y cómo se integra en AWS EMR. Si conoces perfectamente Hadoop, este curso no es necesario.

Otros cursos de [AWS Training] cubriendo S3, RDS, SageMaker, etc. serán buenos para expandir su conocimiento ya que hay algunas preguntas que tocan estos temas y los cursos son realmente breves, pero informativos. En especial, echa un vistazo a todo lo relacionado con S3.

[Tutorials Dojo’s AWS Certified Data Analytics Specialty Practice Exams 2021] – esencial para poner a prueba tus conocimientos y descubrir dónde están tus puntos débiles. También es un buen indicador de su preparación para el examen; es recomendable obtener un 90% antes del examen.


Conclusión

Los exámenes de certificación de AWS necesitan esfuerzo y dedicación pero además, tener experiencia práctica ayuda mucho para enfrentarte a los mismos. Por ejemplo, si trabajas habitualmente con AWS Glue, seguramente no te hará falta estudiar mucho acerca de este servicio porque ya conoces sus capacidades y funcionalidad a partir de tu trabajo del día a día. Muchas veces esta experiencia es más relevante de cara al examen que revisar algunos posibles escenarios teóricos: si te has enfrentado directamente con los problemas estarás mucho más seguro de cara al examen.

Espero que este pequeño resumen te ayude a preparar la certificación y consigas mejorar tus capacidades profesionales en el análisis de datos. Anímate a realizarla y veras que, aunque requiere esfuerzo, es una meta perfectamente alcanzable.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Sergi Lehkyi
Data Engineer

En mi camino profesional he pasado por desarrollo web, administración de bases de datos, ciencia de datos y últimamente estoy enfocado en las tecnologías y soluciones de Cloud, especialmente AWS.

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

¿Existe el Azar?

by

¿Existe el Azar?

Lorelei Ambriz

Technician

Una breve e informal introducción a la teoría del caos matemático y la teoría de la probabilidad matemática.

Para poder responder a la pregunta sobre la existencia del azar, primero abordaremos otro concepto con el cual posiblemente ya estemos parcialmente familiarizados. Dicho concepto es el caos matemático, o también conocido coloquialmente como el efecto mariposa. Así como algunos conceptos relacionados a este: sistemas dinámicos y determinismo.


¿Qué es el caos matemático?

En resumen, la teoría del caos, o caos matemático (para no perder de vista las matemáticas) tiene como centro de estudio, los sistemas dinámicos que aparentan tener un comportamiento aleatorio, sin embargo estos son gobernados por patrones y determinismo.


¿Qué es un sistema dinámico?

Un sistema dinámico es un conjunto de fenómenos deterministas que interactúan uno con otro dentro de este conjunto en función de una colección de parámetros (usualmente el parámetro más usado es el tiempo).

Un ejemplo sencillo de sistema dinámico es un péndulo simple. Para detallar un poco más, mencionemos los componentes de este sistema. Un péndulo simple consiste en un tubo/varilla que en uno de los extremos sostiene un peso mientras que del otro, estará sostenido de forma que pueda columpiarse. Los componentes de este sistema son: la longitud de la varilla, el peso que carga, la fuerza gravitatoria y la altura inicial a la que hará su primera oscilación. El resultado de la ejecución de este sistema es una medición del tiempo.

Un ejemplo mucho más sofisticado es el planeta Tierra. Entre sus componentes más notorios están: árboles, agua, aire, radiación recibida por el sol, la geografía del planeta, etc. Uno de los resultados apreciables en este sistema como resultado de estos componentes es el clima de la Tierra.


¿Qué es el determinismo?

Decimos que un modelo es determinista cuando existe una ley o regla que siempre va a cumplir dicho modelo asociado a un fenómeno particular. O en otras palabras, está determinado por dichas leyes y las condiciones que le rodean. Por dar un ejemplo, como si se tratase de la descripción de la maquinaria en un reloj con péndulo. En esta maquinaria hay todo un sistema dinámico que cambia con respecto al tiempo. Poseé un conjunto de engranajes, manecillas y un péndulo, que organizados de forma específica, nos dará como resultado un dispositivo con el que medir el tiempo a lo largo de un día.

Para comprender y/o descubrir las leyes o reglas que gobiernan estos sistemas, los matemáticos, en resumen, recurrimos a la búsqueda de patrones con un razonamiento lógico deductivo así como algunas veces es necesaria la experimentación e incluso el método científico.


Y ahora, ¿Qué sigue?

Habiendo hablado un poco sobre sistemas dinámicos, determinismo y caos matemático introduciremos el siguiente concepto: estabilidad de sistemas dinámicos. ¿Cómo podemos considerar la estabilidad?. Sin entrar en el rigor matemático pero con algo de matemáticas, un sistema es estable cuando tenemos una curva ‘f’ definida por una condición inicial ‘x0’ en este sistema y trazamos una “tubería” alrededor de esta curva para que quede contenida en esta (vecindad de convergencia). Y entonces para cualquier condición inicial ‘t0’ cercana a ‘x0’, que nos define una curva ‘g’ ocurrirá uno de los siguientes casos:

  • Si g → f (tiende o cada vez se acerca más a f) entonces el sistema es asintóticamente estable.
  • Si g permanece dentro de la tubería en todo momento, entonces el sistema es estable.
  • Si a partir de un momento, g sale de la tubería y de cualquier tubería con centro en f, entonces el sistema es inestable.


Observación: si ‘g’ saliera 1 vez (o incluso n veces), entonces hacemos una tubería con centro en f que contenga a toda la curva g. Por eso se dice que sale de todas las tuberías posibles, porque entonces ‘g’ se vuelve completamente diferente a ‘f’ a partir de algún momento.

Ahora usando ejemplos con pares idénticos de péndulos para tener una mayor visibilidad de los casos anteriores:

  • Levanta el par de péndulos, y al soltarlos de forma simultánea, estos oscilarán con la misma frecuencia y se detendrán casi al mismo tiempo. Esto es estabilidad asintótica.
  • Levanta el par de péndulos, pero instalados sobre una “máquina de movimiento perpetuo”. Al soltarlos estos oscilarán con la misma frecuencia hasta que se detenga la máquina.
  • Ahora considera un par de péndulos dobles, y levanta dicho par a una misma posición. Al soltar los péndulos, después de unos segundos cada péndulo tendrá su trayectoria completamente diferente al otro. Esto es inestabilidad. De hecho, en este caso en particular, las trayectorias parecieran ser aleatorias. Sin embargo siguen cumpliendo las leyes que rigen a los péndulos.

Cabe recordar que aunque creamos ponemos a la misma altura los péndulos, en el mundo físico hay una diferencia mínima entre estas alturas. Para los sistemas estables, la estabilidad parece menospreciar dicha diferencia. En cambio, el sistema inestable es altamente sensible a estos cambios y esta pequeña diferencia inicial termina siendo una enorme diferencia al poco tiempo.


¿Dónde más podemos ver el caos matemático?

La respuesta es relativamente fácil: en casi todos los lugares a donde miremos. Desde las trayectorias y posición donde caen las hojas de un árbol al desprenderse de sus ramas, las acciones de las acciones en la bolsa, hasta incluso los procesos biológicos de los seres vivos y sin olvidar un ejemplo muy importante: el clima de la Tierra. Una persona podría reflexionar que todo el universo está gobernado por caos matemático, determinismo absoluto. Simplemente las relaciones que ocurren entre los componentes del universo pueden ser desde relativamente simples, a altamente complejas.


Ahora con todo lo planteado: ¿Existe el azar?

La respuesta pareciera ser que no. Sin embargo, notemos un detalle importante sobre lo que conocemos del azar: podemos tener la seguridad que un resultado o salida obtenido de un evento aleatorio es desconocido, ya que si lo supiéramos de antemano, entonces el evento no sería aleatorio. En este punto pareciera que podemos ver el caos matemático como azar, sin embargo este es determinista y eso nos implica que conociendo todos los componentes que definen esta curva (leyes, condiciones iniciales e interacciones entre todas las variables), podemos conocer de antemano todas las salidas. Pero aquí está precisamente el detalle: conocer todas las interacciones de forma precisa entre todas las variables. Cuando estas interacciones se vuelven muy complejas dentro del sistema y este se vuelve inestable, en lugar de intentar comprender lo que ocurre entre estas variables, podemos empezar a analizar las posibles salidas o resultados de este. De este análisis podemos ver que otros patrones empiezan a emerger: distribuciones de probabilidad.


Distribuciones de probabilidad: un vistazo a la teoría de la probabilidad.

La teoría de la probabilidad es una rama dentro de las matemáticas que estudia los eventos aleatorios y estocásticos. Si bien la teoría clásica de la probabilidad se reduce a hacer conteos de casos favorables y compararlos contra todos los posibles escenarios, cuando se propone un conjunto de axiomas basados en la teoría de conjuntos y la teoría de la medida por parte de Andréi Kolmogórov es que la teoría de la probabilidad adquiere rigor matemático y así se puede extender su estudio más allá de los marcos clásicos de esta. Argumentos en el contexto de la probabilidad utilizados en diversas áreas como la física, economía, biología entre otras cobran fuerza gracias a esta aportación. A partir de aquí es que surge la teoría moderna de la probabilidad. Algunos de los conceptos y resultados más importantes de esta teoría moderna son:

  • Variables aleatorias y funciones de distribución.
  • Leyes de los grandes números.
  • Teorema del límite central.
  • Procesos estocásticos.


Conexión entre los sistemas caóticos y la probabilidad.

Como platicamos anteriormente, estudiando las salidas o resultados de sistemas dinámicos inestables podemos ver que hay patrones que emergen de estos. Curiosamente estos se comportan como variables aleatorias y funciones de distribución de la teoría de la probabilidad. Esto se debe a algunos resultados importantes como son las leyes de los grandes números y el teorema del límite central entre otros. Recordando que la teoría de la probabilidad adquiere su rigurosidad a partir de los axiomas de Kolmogorov que tienen origen en la teoría de conjuntos y la teoría de la medida.


Entonces: ¿el azar existe?

Si bien podemos concluir que el universo es gobernado por leyes de las cuales algunas conocemos y otras no (de aquí podemos abrir otro tema para otra ocasión: Lo que sabemos, lo que no sabemos, y lo que no sabemos que no sabemos), y esto tiene implícito la omnipresencia del determinismo. Podemos concluir que el azar no tiene lugar en el universo. Sin embargo, recordemos que la teoría de la probabilidad es una construcción humana, cuya rigurosidad y patrones pueden ser conectados con otras áreas, y como ya vimos, particularmente pueden ser conectados con el caos matemático para cambiar el enfoque de estudio de los fenómenos regidos por el caos. Pasando de conocer las leyes que los gobiernan para entender las salidas y resultados de estos, a conectar dichos patrones con las distribuciones de probabilidad que tienen toda una teoría matemática que las respalda, así como un área que las explota como es la estadística.


Explotando el azar

Sabiendo que el azar está directamente conectado con el desconocimiento de resultados y ocurrencias. Y precisamente por esta razón es que podemos explotar la teoría de la probabilidad, entonces podemos pasar a construir un objeto muy importante dentro de la ciencia de la computación: los generadores de números aleatorios.

Estos generadores son objetos muy útiles para dotar de nuestros procesos con la esencia del caos y así traer la complejidad del mundo a nuestros análisis, modelos, simulaciones y demás. Sin embargo, cabe mencionar que para obtener generadores de números aleatorios que en verdad tengan lo que buscamos, es importante notar que no debe haber un patrón sencillo en estos. ¿Entonces cómo podemos recurrir a construir un buen generador de números aleatorios?. La respuesta se encuentra en el mismo caos. Por ejemplo, usar las curvas que recorren los péndulos dobles, o la paridad en los dígitos decimales de π, entre otros.

Simulando el azar en nuestros procesos, podemos aprovechar una de las características más importantes de este, la cual es: la imparcialidad. Con esta, eliminamos sesgos de nuestras muestras (característica fundamental para entrenar con imparcialidad a nuestros modelos de aprendizaje máquina), contribuyendo incluso al mismo entrenamiento que ocurre en los modelos de aprendizaje máquina y aprendizaje profundo por medio de la optimización de las funciones de costo. Otra simulación muy importante a mencionar es la simulación de MonteCarlo, la cuál nos permite obtener muestras aleatorias que representan lo que podemos modelar, así como pueden ser usadas para diferentes cálculos computacionales pesados que de forma clásica podrían ser desde muy complejos, hasta imposibles.


Conclusión

El azar es un constructo humano que si bien no existe en el universo de forma natural debido a la naturaleza compleja de este, como concepto humano nos ayuda a comprender y estudiar lo que sucede reduciendo la complejidad que surge de forma natural. Así que en efecto, el azar existe, porque la humanidad lo construyó y un día se dió cuenta que le ayudaba a comprender mejor el complejo universo en el que vivimos.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

¿Existe el Azar?

by

¿Existe el Azar?

Lorelei Ambriz

Technician

Una breve e informal introducción a la teoría del caos matemático y la teoría de la probabilidad matemática.

Para poder responder a la pregunta sobre la existencia del azar, primero abordaremos otro concepto con el cual posiblemente ya estemos parcialmente familiarizados. Dicho concepto es el caos matemático, o también conocido coloquialmente como el efecto mariposa. Así como algunos conceptos relacionados a este: sistemas dinámicos y determinismo.


¿Qué es el caos matemático?

En resumen, la teoría del caos, o caos matemático (para no perder de vista las matemáticas) tiene como centro de estudio, los sistemas dinámicos que aparentan tener un comportamiento aleatorio, sin embargo estos son gobernados por patrones y determinismo.


¿Qué es un sistema dinámico?

Un sistema dinámico es un conjunto de fenómenos deterministas que interactúan uno con otro dentro de este conjunto en función de una colección de parámetros (usualmente el parámetro más usado es el tiempo).

Un ejemplo sencillo de sistema dinámico es un péndulo simple. Para detallar un poco más, mencionemos los componentes de este sistema. Un péndulo simple consiste en un tubo/varilla que en uno de los extremos sostiene un peso mientras que del otro, estará sostenido de forma que pueda columpiarse. Los componentes de este sistema son: la longitud de la varilla, el peso que carga, la fuerza gravitatoria y la altura inicial a la que hará su primera oscilación. El resultado de la ejecución de este sistema es una medición del tiempo.

Un ejemplo mucho más sofisticado es el planeta Tierra. Entre sus componentes más notorios están: árboles, agua, aire, radiación recibida por el sol, la geografía del planeta, etc. Uno de los resultados apreciables en este sistema como resultado de estos componentes es el clima de la Tierra.


¿Qué es el determinismo?

Decimos que un modelo es determinista cuando existe una ley o regla que siempre va a cumplir dicho modelo asociado a un fenómeno particular. O en otras palabras, está determinado por dichas leyes y las condiciones que le rodean. Por dar un ejemplo, como si se tratase de la descripción de la maquinaria en un reloj con péndulo. En esta maquinaria hay todo un sistema dinámico que cambia con respecto al tiempo. Poseé un conjunto de engranajes, manecillas y un péndulo, que organizados de forma específica, nos dará como resultado un dispositivo con el que medir el tiempo a lo largo de un día.

Para comprender y/o descubrir las leyes o reglas que gobiernan estos sistemas, los matemáticos, en resumen, recurrimos a la búsqueda de patrones con un razonamiento lógico deductivo así como algunas veces es necesaria la experimentación e incluso el método científico.


Y ahora, ¿Qué sigue?

Habiendo hablado un poco sobre sistemas dinámicos, determinismo y caos matemático introduciremos el siguiente concepto: estabilidad de sistemas dinámicos. ¿Cómo podemos considerar la estabilidad?. Sin entrar en el rigor matemático pero con algo de matemáticas, un sistema es estable cuando tenemos una curva ‘f’ definida por una condición inicial ‘x0’ en este sistema y trazamos una “tubería” alrededor de esta curva para que quede contenida en esta (vecindad de convergencia). Y entonces para cualquier condición inicial ‘t0’ cercana a ‘x0’, que nos define una curva ‘g’ ocurrirá uno de los siguientes casos:

  • Si g → f (tiende o cada vez se acerca más a f) entonces el sistema es asintóticamente estable.
  • Si g permanece dentro de la tubería en todo momento, entonces el sistema es estable.
  • Si a partir de un momento, g sale de la tubería y de cualquier tubería con centro en f, entonces el sistema es inestable.


Observación: si ‘g’ saliera 1 vez (o incluso n veces), entonces hacemos una tubería con centro en f que contenga a toda la curva g. Por eso se dice que sale de todas las tuberías posibles, porque entonces ‘g’ se vuelve completamente diferente a ‘f’ a partir de algún momento.

Ahora usando ejemplos con pares idénticos de péndulos para tener una mayor visibilidad de los casos anteriores:

  • Levanta el par de péndulos, y al soltarlos de forma simultánea, estos oscilarán con la misma frecuencia y se detendrán casi al mismo tiempo. Esto es estabilidad asintótica.
  • Levanta el par de péndulos, pero instalados sobre una “máquina de movimiento perpetuo”. Al soltarlos estos oscilarán con la misma frecuencia hasta que se detenga la máquina.
  • Ahora considera un par de péndulos dobles, y levanta dicho par a una misma posición. Al soltar los péndulos, después de unos segundos cada péndulo tendrá su trayectoria completamente diferente al otro. Esto es inestabilidad. De hecho, en este caso en particular, las trayectorias parecieran ser aleatorias. Sin embargo siguen cumpliendo las leyes que rigen a los péndulos.

Cabe recordar que aunque creamos ponemos a la misma altura los péndulos, en el mundo físico hay una diferencia mínima entre estas alturas. Para los sistemas estables, la estabilidad parece menospreciar dicha diferencia. En cambio, el sistema inestable es altamente sensible a estos cambios y esta pequeña diferencia inicial termina siendo una enorme diferencia al poco tiempo.


¿Dónde más podemos ver el caos matemático?

La respuesta es relativamente fácil: en casi todos los lugares a donde miremos. Desde las trayectorias y posición donde caen las hojas de un árbol al desprenderse de sus ramas, las acciones de las acciones en la bolsa, hasta incluso los procesos biológicos de los seres vivos y sin olvidar un ejemplo muy importante: el clima de la Tierra. Una persona podría reflexionar que todo el universo está gobernado por caos matemático, determinismo absoluto. Simplemente las relaciones que ocurren entre los componentes del universo pueden ser desde relativamente simples, a altamente complejas.


Ahora con todo lo planteado: ¿Existe el azar?

La respuesta pareciera ser que no. Sin embargo, notemos un detalle importante sobre lo que conocemos del azar: podemos tener la seguridad que un resultado o salida obtenido de un evento aleatorio es desconocido, ya que si lo supiéramos de antemano, entonces el evento no sería aleatorio. En este punto pareciera que podemos ver el caos matemático como azar, sin embargo este es determinista y eso nos implica que conociendo todos los componentes que definen esta curva (leyes, condiciones iniciales e interacciones entre todas las variables), podemos conocer de antemano todas las salidas. Pero aquí está precisamente el detalle: conocer todas las interacciones de forma precisa entre todas las variables. Cuando estas interacciones se vuelven muy complejas dentro del sistema y este se vuelve inestable, en lugar de intentar comprender lo que ocurre entre estas variables, podemos empezar a analizar las posibles salidas o resultados de este. De este análisis podemos ver que otros patrones empiezan a emerger: distribuciones de probabilidad.


Distribuciones de probabilidad: un vistazo a la teoría de la probabilidad.

La teoría de la probabilidad es una rama dentro de las matemáticas que estudia los eventos aleatorios y estocásticos. Si bien la teoría clásica de la probabilidad se reduce a hacer conteos de casos favorables y compararlos contra todos los posibles escenarios, cuando se propone un conjunto de axiomas basados en la teoría de conjuntos y la teoría de la medida por parte de Andréi Kolmogórov es que la teoría de la probabilidad adquiere rigor matemático y así se puede extender su estudio más allá de los marcos clásicos de esta. Argumentos en el contexto de la probabilidad utilizados en diversas áreas como la física, economía, biología entre otras cobran fuerza gracias a esta aportación. A partir de aquí es que surge la teoría moderna de la probabilidad. Algunos de los conceptos y resultados más importantes de esta teoría moderna son:

  • Variables aleatorias y funciones de distribución.
  • Leyes de los grandes números.
  • Teorema del límite central.
  • Procesos estocásticos.


Conexión entre los sistemas caóticos y la probabilidad.

Como platicamos anteriormente, estudiando las salidas o resultados de sistemas dinámicos inestables podemos ver que hay patrones que emergen de estos. Curiosamente estos se comportan como variables aleatorias y funciones de distribución de la teoría de la probabilidad. Esto se debe a algunos resultados importantes como son las leyes de los grandes números y el teorema del límite central entre otros. Recordando que la teoría de la probabilidad adquiere su rigurosidad a partir de los axiomas de Kolmogorov que tienen origen en la teoría de conjuntos y la teoría de la medida.


Entonces: ¿el azar existe?

Si bien podemos concluir que el universo es gobernado por leyes de las cuales algunas conocemos y otras no (de aquí podemos abrir otro tema para otra ocasión: Lo que sabemos, lo que no sabemos, y lo que no sabemos que no sabemos), y esto tiene implícito la omnipresencia del determinismo. Podemos concluir que el azar no tiene lugar en el universo. Sin embargo, recordemos que la teoría de la probabilidad es una construcción humana, cuya rigurosidad y patrones pueden ser conectados con otras áreas, y como ya vimos, particularmente pueden ser conectados con el caos matemático para cambiar el enfoque de estudio de los fenómenos regidos por el caos. Pasando de conocer las leyes que los gobiernan para entender las salidas y resultados de estos, a conectar dichos patrones con las distribuciones de probabilidad que tienen toda una teoría matemática que las respalda, así como un área que las explota como es la estadística.


Explotando el azar

Sabiendo que el azar está directamente conectado con el desconocimiento de resultados y ocurrencias. Y precisamente por esta razón es que podemos explotar la teoría de la probabilidad, entonces podemos pasar a construir un objeto muy importante dentro de la ciencia de la computación: los generadores de números aleatorios.

Estos generadores son objetos muy útiles para dotar de nuestros procesos con la esencia del caos y así traer la complejidad del mundo a nuestros análisis, modelos, simulaciones y demás. Sin embargo, cabe mencionar que para obtener generadores de números aleatorios que en verdad tengan lo que buscamos, es importante notar que no debe haber un patrón sencillo en estos. ¿Entonces cómo podemos recurrir a construir un buen generador de números aleatorios?. La respuesta se encuentra en el mismo caos. Por ejemplo, usar las curvas que recorren los péndulos dobles, o la paridad en los dígitos decimales de π, entre otros.

Simulando el azar en nuestros procesos, podemos aprovechar una de las características más importantes de este, la cual es: la imparcialidad. Con esta, eliminamos sesgos de nuestras muestras (característica fundamental para entrenar con imparcialidad a nuestros modelos de aprendizaje máquina), contribuyendo incluso al mismo entrenamiento que ocurre en los modelos de aprendizaje máquina y aprendizaje profundo por medio de la optimización de las funciones de costo. Otra simulación muy importante a mencionar es la simulación de MonteCarlo, la cuál nos permite obtener muestras aleatorias que representan lo que podemos modelar, así como pueden ser usadas para diferentes cálculos computacionales pesados que de forma clásica podrían ser desde muy complejos, hasta imposibles.


Conclusión

El azar es un constructo humano que si bien no existe en el universo de forma natural debido a la naturaleza compleja de este, como concepto humano nos ayuda a comprender y estudiar lo que sucede reduciendo la complejidad que surge de forma natural. Así que en efecto, el azar existe, porque la humanidad lo construyó y un día se dió cuenta que le ayudaba a comprender mejor el complejo universo en el que vivimos.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Mi experiencia en el mundo de Big Data – Parte I

by

Mi experiencia en el mundo de Big Data - Parte I

David Emmanuel Reyes Núñez

Senior Data Engineer

Hace casi dos años (septiembre 2019), no sabía absolutamente nada de tecnologías Big Data, hoy sé que, aunque ya conozco y he interactuado con algunas de ellas, me falta mucho camino por recorrer y muchas cosas por aprender. Todo empieza confiando en ti y a veces necesitas el impulso de alguien que confíe en ti.

 Me ha gustado tanto este tipo de tecnologías que incluso en este par de años, he podido tomar un par de diplomados y concluir recientemente una Maestría en Análisis y Visualización de Datos.

En esta ocasión quiero compartir una de las experiencias que he tenido con estas tecnologías, la cual se trata de realizar ingestas de archivos hacia Google BigQuery  y Google Cloud Storage, utilizando Google Drive como repositorio fuente.

¿Qué necesitamos?

En este primer articulo haremos uso de Google Drive API y Python 2.6 o superior.

Necesitamos también tener proyecto de Google Cloud Platform con la API habilitada. Para crear un proyecto y habilitar una API, haz clic aquí

Debemos ver una pantalla similar a esta:

Seleccionamos el tipo de aplicación que necesitamos y se nos genera un archivo JSON, llamado credentials.json, que podemos descargar y ubicar en algún directorio que sea sencillo de identificar:

También necesitamos credenciales de autorización para una aplicación de escritorio. Para aprender a crear credenciales para una aplicación de escritorio, haz clic aquí.

Ejecutamos el siguiente comando en la consola para instalar las librerías que utilizaremos:

pip3 install google-api-python-client google-auth-httplib2 google-auth-oauthlib

Una vez que tenemos configurado nuestro ambiente, comenzamos a crear los módulos de nuestra aplicación.

  • Archivo de Configuración

Para nuestro primer script de Python, necesitamos un archivo que guarde nuestra configuración de rutas y elementos, podemos llamarlo config.ini, y lo llenaremos como muestra el ejemplo que sigue:

[GENERAL_CONFIG] —secciónKey_file_location= path del archive json de credencialesscopes = https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/cloud-platform (los scopes sirven para identificar las APIs que usaremos) CompressionLevel = 9ForwardX11 = yes [DRIVE_API] — en esta sección colocamos los id’s del Drive al que nos queremos conectar, se encuentra ubicado después del ultimo slash (/) de la URL:

drive_id = 1-jrMx9oDTOO9eN7ZGcU5tSZVTKtD
folder_2 = 1i70h0VBdL0Gzw9xR9FiO2gfBFxSQz

Creamos el script de Python que leera nuestro archive config.ini mediante el siguiente código de Python:

import configparser
import datetime

def readConfig():
    #Obtenemos la fecha del sistema, que nos servirá para nombrar el archivo de Log
    fileDate = datetime.datetime.today().strftime('%Y-%m-%d')

    config = configparser.ConfigParser()
    config.read('./config/Config.ini') #path donde se ubica el archivo.ini
    general_config=config['GENERAL_CONFIG'] #referencia a la seccion
    drive_api=config['DRIVE_API']
    
    readConfig.conf_key_file=general_config['key_file_location']
    readConfig.scopes=general_config['scopes']
    
    readConfig.team_drive=drive_api['team_drive']
    
    #generamos el nombre para el archivo de log, con la fecha de sistema
    fileLogMain='MyLogFile.log'
    sfileLogMain =fileLogMain.split('.')
    fileLogMain=sfileLogMain[0]+'_'+fileDate+'.'+sfileLogMain[1]
  • Archivo de parámetros

Aquí es donde comenzamos a hablar de GCP.  Si queremos descargar archivos específicos de nuestro drive, tenemos que crear un archivo en donde le indiquemos el nombre, la extensión, el proyecto GCP de destino, el bucket de GS donde lo subiremos y el nombre de la tabla que creará en bigQuery.

Creamos un archivo parameters.csv con la siguiente estructura:

Nombre_Archivo|Proyecto_GCP|Bucket_GCP|DataSet_BQ|Tabla_BQ|Path_GS|Status

Archivo1.csv|mi_proyecto|mi_bucket|raw_data|mi_tabla_bq|path/gs|1
Archivo2.csv|mi_proyecto|mi_bucket2|raw_data|mi_tabla_bq|path2/gs|0

La última columna, indica el status para saber si se descargará o no el archivo (1=Activo, 0=Inactivo)

Nota: Debemos contar con permisos y credenciales para los proyectos a los que queramos subir el archivo, este tema lo iremos abordando en siguientes entregas. Ahora solo nos limitaremos a la parte de descargar un archivo desde Google Drive hacia nuestro disco local.

El script de Python para leer y descargar los archivos es el siguiente:

#Librerias para lectura del archivo, autenticación de servicios y lectura de archivos csv
from modules.readConfig import readConfig
from modules.auth import get_service
from modules.processDriveFiles import get_FoldersList
import logging
import csv
import os,glob

def readProperties():
    #Configuramos los niveles de logging
    logging.basicConfig(level=logging.INFO,
                        format='%(asctime)s %(name)-8s %(levelname)-8s %(message)s',
                        datefmt='%m-%d %H:%M',
                        filename=readConfig.log_file_main,
                        filemode='a')
    logging.info('Inicio...')
    #Comienza la lectura del archivo de parámetros
   For row in reader:
    with open(readConfig.params_file, 'r', encoding='utf-8') as f:
   
        reader = csv.DictReader(f, delimiter='|')
        props = {}
        api_name='drive'
        api_version='v3'
        scopes=[readConfig.scopes]
        key_file_location=readConfig.conf_key_file 


        #Validamos que el archivo que queremos esté activo para poder descargarlo y guardamos los parámetros en un arreglo.
        if row['Status']==1:
                props ={'nombre_archivo':row['Nombre_Archivo],'proyecto':row['Proyecto_GCP'],'DataSet_BQ':row['DataSet_BQ'],'Tabla':row['Tabla_BQ'],'Bucket_GCP':row['Bucket_GCP'],'Path_GS':row['Path_GS'], 'Status':row['Status'

#Funciones para autenticación y obtener el listado de folders
creds = get_service(api_name,api_version,scopes,key_file_location,
                        props) 
        get_FoldersList(creds,props)
        f.close()



#funcion get_service (ubicada en el módulo auth.py) Esta función nos servirá para seleccionar el archivo de credenciales que usaremos para autenticarnos en Google drive
def get_service(api_name, api_version, scopes, key_file_location,props):
        key_file_location='./auth/driveCredentials.json'
        
credentialsDrive = service_account.Credentials.from_service_account_file(
            key_file_location, scopes=scopes)


#funcion get_FoldersList. Una vez autenticados, nos permitirá listar los folders de nuestro Google Drive de acuerdo con los parámetros que le enviemos. Esta contenida en el script processDriveFiles.py



def get_FoldersList(creds,props):

    # Obtiene un listado de los Google Drive folders
        done = True
        logging.info('Ejecutando consulta: ')
        query = "mimeType!='application/vnd.google-apps.folder' and name='"+props.get('archivo_origen')+"' and parents!='"+readConfig.success_drive+"' and parents!='"+readConfig.failure_drive+"' and starred=False and trashed=False"
        response = creds.get('service').files().list(
                q=query,            
                fields='*',  
                orderBy='folder',
                driveId=readConfig.team_drive,                
                corpora='drive',
                includeItemsFromAllDrives=True,
                supportsAllDrives=True).execute()

        items = response.get('files', [])

        if not items:
                logging.info('No se han encontrado archivos')
        else:
                for item in items:
                #descargamos el archivo
                    file_id = item['id']
                    fh = io.FileIO(item['name'],'w')
                    
                    request = creds.get('service').files().get_media(fileId=file_id)
                    fh = io.FileIO(item['name'],'w')
                    downloader = MediaIoBaseDownload(fh, request)
                    done = False
				
       statusdw=0 
       #Se realiza la descarga
       while (done is False and int(statusdw)<100):
              file_ext=''
              status, done = downloader.next_chunk()
              logging.info('status: ')
              statusdw=(int(status.progress())*100)  
              logging.info(int(statusdw))
              logging.info('Descargando: '+item['name']+" %d%%." % int(statusdw))                      
              logging.info('Descargando: '+item['name']+" %d%%." % int(status.progress() * 100))

En esta parte, ya debemos ver nuestro archive descargado en el directorio local de la aplicación.      

Esta es la primera entrega de nuestro administrador de archivos, el objetivo de este desarrollo es llevar archivos desde Google Drive hacia Google Cloud. En la siguiente entrega continuaremos con el código de la función processDriveFiles.py y crearemos los scripts para hacer la carga de archivos hacia Google Cloud.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Mi experiencia en el mundo de Big Data – Parte I

by

Mi experiencia en el mundo de Big Data - Parte I

David Emmanuel Reyes Núñez

Senior Data Engineer

Hace casi dos años (septiembre 2019), no sabía absolutamente nada de tecnologías Big Data, hoy sé que, aunque ya conozco y he interactuado con algunas de ellas, me falta mucho camino por recorrer y muchas cosas por aprender. Todo empieza confiando en ti y a veces necesitas el impulso de alguien que confíe en ti.

 Me ha gustado tanto este tipo de tecnologías que incluso en este par de años, he podido tomar un par de diplomados y concluir recientemente una Maestría en Análisis y Visualización de Datos.

En esta ocasión quiero compartir una de las experiencias que he tenido con estas tecnologías, la cual se trata de realizar ingestas de archivos hacia Google BigQuery  y Google Cloud Storage, utilizando Google Drive como repositorio fuente.

¿Qué necesitamos?

En este primer articulo haremos uso de Google Drive API y Python 2.6 o superior.

Necesitamos también tener proyecto de Google Cloud Platform con la API habilitada. Para crear un proyecto y habilitar una API, haz clic aquí

Debemos ver una pantalla similar a esta:

Seleccionamos el tipo de aplicación que necesitamos y se nos genera un archivo JSON, llamado credentials.json, que podemos descargar y ubicar en algún directorio que sea sencillo de identificar:

También necesitamos credenciales de autorización para una aplicación de escritorio. Para aprender a crear credenciales para una aplicación de escritorio, haz clic aquí.

Ejecutamos el siguiente comando en la consola para instalar las librerías que utilizaremos:

pip3 install google-api-python-client google-auth-httplib2 google-auth-oauthlib

Una vez que tenemos configurado nuestro ambiente, comenzamos a crear los módulos de nuestra aplicación.

  • Archivo de Configuración

Para nuestro primer script de Python, necesitamos un archivo que guarde nuestra configuración de rutas y elementos, podemos llamarlo config.ini, y lo llenaremos como muestra el ejemplo que sigue:

[GENERAL_CONFIG] —secciónKey_file_location= path del archive json de credencialesscopes = https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/cloud-platform (los scopes sirven para identificar las APIs que usaremos) CompressionLevel = 9ForwardX11 = yes [DRIVE_API] — en esta sección colocamos los id’s del Drive al que nos queremos conectar, se encuentra ubicado después del ultimo slash (/) de la URL:

drive_id = 1-jrMx9oDTOO9eN7ZGcU5tSZVTKtD
folder_2 = 1i70h0VBdL0Gzw9xR9FiO2gfBFxSQz

Creamos el script de Python que leera nuestro archive config.ini mediante el siguiente código de Python:

import configparser
import datetime

def readConfig():
    #Obtenemos la fecha del sistema, que nos servirá para nombrar el archivo de Log
    fileDate = datetime.datetime.today().strftime('%Y-%m-%d')

    config = configparser.ConfigParser()
    config.read('./config/Config.ini') #path donde se ubica el archivo.ini
    general_config=config['GENERAL_CONFIG'] #referencia a la seccion
    drive_api=config['DRIVE_API']
    
    readConfig.conf_key_file=general_config['key_file_location']
    readConfig.scopes=general_config['scopes']
    
    readConfig.team_drive=drive_api['team_drive']
    
    #generamos el nombre para el archivo de log, con la fecha de sistema
    fileLogMain='MyLogFile.log'
    sfileLogMain =fileLogMain.split('.')
    fileLogMain=sfileLogMain[0]+'_'+fileDate+'.'+sfileLogMain[1]
  • Archivo de parámetros

Aquí es donde comenzamos a hablar de GCP.  Si queremos descargar archivos específicos de nuestro drive, tenemos que crear un archivo en donde le indiquemos el nombre, la extensión, el proyecto GCP de destino, el bucket de GS donde lo subiremos y el nombre de la tabla que creará en bigQuery.

Creamos un archivo parameters.csv con la siguiente estructura:

Nombre_Archivo|Proyecto_GCP|Bucket_GCP|DataSet_BQ|Tabla_BQ|Path_GS|Status

Archivo1.csv|mi_proyecto|mi_bucket|raw_data|mi_tabla_bq|path/gs|1
Archivo2.csv|mi_proyecto|mi_bucket2|raw_data|mi_tabla_bq|path2/gs|0

La última columna, indica el status para saber si se descargará o no el archivo (1=Activo, 0=Inactivo)

Nota: Debemos contar con permisos y credenciales para los proyectos a los que queramos subir el archivo, este tema lo iremos abordando en siguientes entregas. Ahora solo nos limitaremos a la parte de descargar un archivo desde Google Drive hacia nuestro disco local.

El script de Python para leer y descargar los archivos es el siguiente:

#Librerias para lectura del archivo, autenticación de servicios y lectura de archivos csv
from modules.readConfig import readConfig
from modules.auth import get_service
from modules.processDriveFiles import get_FoldersList
import logging
import csv
import os,glob

def readProperties():
    #Configuramos los niveles de logging
    logging.basicConfig(level=logging.INFO,
                        format='%(asctime)s %(name)-8s %(levelname)-8s %(message)s',
                        datefmt='%m-%d %H:%M',
                        filename=readConfig.log_file_main,
                        filemode='a')
    logging.info('Inicio...')
    #Comienza la lectura del archivo de parámetros
   For row in reader:
    with open(readConfig.params_file, 'r', encoding='utf-8') as f:
   
        reader = csv.DictReader(f, delimiter='|')
        props = {}
        api_name='drive'
        api_version='v3'
        scopes=[readConfig.scopes]
        key_file_location=readConfig.conf_key_file 


        #Validamos que el archivo que queremos esté activo para poder descargarlo y guardamos los parámetros en un arreglo.
        if row['Status']==1:
                props ={'nombre_archivo':row['Nombre_Archivo],'proyecto':row['Proyecto_GCP'],'DataSet_BQ':row['DataSet_BQ'],'Tabla':row['Tabla_BQ'],'Bucket_GCP':row['Bucket_GCP'],'Path_GS':row['Path_GS'], 'Status':row['Status'

#Funciones para autenticación y obtener el listado de folders
creds = get_service(api_name,api_version,scopes,key_file_location,
                        props) 
        get_FoldersList(creds,props)
        f.close()



#funcion get_service (ubicada en el módulo auth.py) Esta función nos servirá para seleccionar el archivo de credenciales que usaremos para autenticarnos en Google drive
def get_service(api_name, api_version, scopes, key_file_location,props):
        key_file_location='./auth/driveCredentials.json'
        
credentialsDrive = service_account.Credentials.from_service_account_file(
            key_file_location, scopes=scopes)


#funcion get_FoldersList. Una vez autenticados, nos permitirá listar los folders de nuestro Google Drive de acuerdo con los parámetros que le enviemos. Esta contenida en el script processDriveFiles.py



def get_FoldersList(creds,props):

    # Obtiene un listado de los Google Drive folders
        done = True
        logging.info('Ejecutando consulta: ')
        query = "mimeType!='application/vnd.google-apps.folder' and name='"+props.get('archivo_origen')+"' and parents!='"+readConfig.success_drive+"' and parents!='"+readConfig.failure_drive+"' and starred=False and trashed=False"
        response = creds.get('service').files().list(
                q=query,            
                fields='*',  
                orderBy='folder',
                driveId=readConfig.team_drive,                
                corpora='drive',
                includeItemsFromAllDrives=True,
                supportsAllDrives=True).execute()

        items = response.get('files', [])

        if not items:
                logging.info('No se han encontrado archivos')
        else:
                for item in items:
                #descargamos el archivo
                    file_id = item['id']
                    fh = io.FileIO(item['name'],'w')
                    
                    request = creds.get('service').files().get_media(fileId=file_id)
                    fh = io.FileIO(item['name'],'w')
                    downloader = MediaIoBaseDownload(fh, request)
                    done = False
				
       statusdw=0 
       #Se realiza la descarga
       while (done is False and int(statusdw)<100):
              file_ext=''
              status, done = downloader.next_chunk()
              logging.info('status: ')
              statusdw=(int(status.progress())*100)  
              logging.info(int(statusdw))
              logging.info('Descargando: '+item['name']+" %d%%." % int(statusdw))                      
              logging.info('Descargando: '+item['name']+" %d%%." % int(status.progress() * 100))

En esta parte, ya debemos ver nuestro archive descargado en el directorio local de la aplicación.      

Esta es la primera entrega de nuestro administrador de archivos, el objetivo de este desarrollo es llevar archivos desde Google Drive hacia Google Cloud. En la siguiente entrega continuaremos con el código de la función processDriveFiles.py y crearemos los scripts para hacer la carga de archivos hacia Google Cloud.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Serverless Microservices

by

Serverless Microservices

Francisco Linaje

AWS Solutions Architect

En esta práctica cloud veremos como construir microservicios dentro de AWS siguiendo el paradigma serverless. Este tipo de solución permite disponer de sistemas completamente administrados por AWS donde nosotros no deberemos preocuparnos por disponibilizar los recursos o administrarlos, simplemente especificaremos dentro de su configuración las políticas de ejecucion y escalado si se necesitasen, el pago por tanto es exclusivamente por uso.

Requisitos

Para poder realizar esta práctica deberemos disponer de las siguientes instalaciones que nos permitirán poder desarrollar los microservicios y operar el entorno.

  • Terraform: Desde donde crearemos y desplegaremos nuestro backend e infra.
  • Un usuario con credenciales de acceso al cli de AWS (access_key y secret_key) y permisos necesarios para operar los servicios empleados en la práctica.
  • AWS cli v2: Permitirá configurar los credenciales con aws configure, opcionalmente se pueden realizar exports del access_key y secret_key.
  • Un IDE en este caso visual-studio-code
  • Conocimiento básico en Api Rest y AWS
  • Postman

Overview

Se plantea un escenario donde diferentes usuarios mediante aplicaciones multiplataforma acceden a diferentes recursos dentro de la app consumiendo una API Rest segura desplegada en AWS, para ello deberán en primer lugar autenticarse contra el pool de cognito para obtener un token JWT que les permitirá consumir los diferentes endpoints de la API.

Autenticación y Autorización

Para poder ofrecer seguridad a la API y que sus servicios solo sean consumidos por usuarios autorizados, debemos emplear un broker que nos pueda ofrecer autenticacion y a su vez autorizacion sobre estos servicios.

En primer lugar deberemos de entender el flujo que sigue un usuario para poder ser autenticado y autorizado para consumir un microservicio. En el siguiente diagrama se pueden ver como en una serie de pasos un usuario puede consumir el endpoint.

  1. El usuario se autentica mediante sus credenciales contra el broker.
  2. Si los credenciales son correctos, el broker generara un token JWT que serviría como mecanismo de autorización al poder validar que el usuario es quien dice ser.
  3. Este token deberá emplearse en todas las llamadas a la API Rest, para ello se enviará en el header de Authorization junto a un prefijo Bearer.
  4. Si el token es validado por el broker, se le otorgará acceso al consumo del microservicio.

¿Que es JWT o Json Web Token?

Json Web Token es un estándar abierto (RFC 7519) donde se define una forma autónoma de asegurar integridad en los datos enviados gracias a que va firmada digitalmente con HMAC (firma simetrica – misma clave) o RSA(firma asimetrica – par de claves privada/publica) y asi asegurar que el peticionario es una entidad segura. Además estos tokens pueden estar encriptados adicionalmente para ocultar los reclamos a terceros. El escenario principal donde se emplea es en la autorización del peticionario.

Cada token JWT consta de tres partes separados por un “.” de la forma header.payload.signed codificados en base64 por separado.

Header: Indica el tipo de token y su firma, en el caso de RS256 incluirá el kid que identifica la clave pública del emisor del Token que se empleara para verificar la firma. Mediante el iss del payload y el kid de la clave podremos ver en el navegador https:///.well-known/jwks.json la firma publica empleada para descifrar el token.

Payload: Contiene los claims que permiten verificar los atributos de la generación del token: iss (emisor), aud (audience), exp( expiracion) y otros campos que se puedan añadir adicionalmente para enviar información.

AWS Cognito

Cognito es un servicio completamente administrado que ofrece autenticación de usuarios para aplicaciones multiplataforma, además permite el empleo de identidades federadas como Google, Amazon, Facebook, etc para su registro.

Los usuarios podrán registrarse y loguearse contra un pool de usuarios que funciona como directorio de usuarios donde serán albergados los parámetros de autenticación: email, password, número de teléfono, etc. Se ofrecen además opciones de confirmación de usuario mediante código o enlace vía email o sms. Los usuarios autenticados recibirán un token de acceso que podrán emplear para recibir autorización a los microservicios de Api Gateway. Mediante otras opciones no planteadas en este caso de uso, se podrá recibir credenciales temporales STS de AWS para acceder directamente a servicios AWS mediante la función AssumeRoleWithWebIdentity mediante los pool de identidades.

Los usuarios emplearan la interfaz web de Cognito para autenticarse y recibir un código que podrán intercambiar por un token JWT que emplearán como autorización en los microservicios desplegados en Api Gateway.

Empezaremos creando nuestro pool de usuarios.

  • Asignaremos un nombre al pool.
  • Añadiremos el atributo de acceso y verificación, en este caso email.
  • Definiremos como se realiza la verificación: via enlace. Además si se hará por defecto via SNS “COGNITO_DEFAULT” o via SES “DEVELOPER”.
  • La recuperación de la cuenta se hará vía el email verificado, siendo la prioridad 1, como maxima prioridad en caso de añadir futuros métodos opcionales.
resource "aws_cognito_user_pool" "user_pool" {
        name = var.cognito.user_pool_name
        auto_verified_attributes = ["email"]
        username_attributes = ["email"]

        verification_message_template {
            email_subject_by_link = "APP Notification - Account Verification"
            email_message_by_link = "Please click the link to verify your email address: {##VERIFY EMAIL##}\n<br><br>\n"
            default_email_option = "CONFIRM_WITH_LINK"
        }

        email_configuration {
                email_sending_account = "COGNITO_DEFAULT"
        }

        account_recovery_setting {
            recovery_mechanism {
            name = "verified_email"
            priority =  1
            }
        }
    }

Por otro lado, activaremos la interfaz propia de AWS a modo de pruebas para poder realizar el proceso de autenticado contra cognito sin tener que realizar un desarrollo del frontend propio.

  • Indicamos que recibiremos un code para poder intercambiarlo por un token JWT, teniendo como scope el email.
  • El proveedor de identidad sera por default Cognito.
  • Indicaremos una url callback de prueba desde donde nos indicarán el code dentro de la url de la forma “?code=”.
resource "aws_cognito_user_pool_client" "client" {
  name = var.cognito.app_client_name
  user_pool_id = aws_cognito_user_pool.user_pool.id
  supported_identity_providers = ["COGNITO"]
  callback_urls = var.cognito.callback_urls
  allowed_oauth_flows_user_pool_client = var.cognito.user_pool_client
  allowed_oauth_flows = ["code"]
  allowed_oauth_scopes = ["openid","email"]
}

resource "aws_cognito_user_pool_domain" "main" {
  domain       = var.cognito.domain_name
  user_pool_id = aws_cognito_user_pool.user_pool.id
}

Autorización de los microservicios

En Api Gateway configuraremos un autorizador que recibirá el token JWT y comprobará la firma del token, como el emisor y audiencia añadidos en los propios scopes. El proceso de comprobación es automático permitiendo el acceso directo al servicio si este es válido o denegando mediante un unauthorized la request.

resource "aws_apigatewayv2_authorizer" "jwtAuth" {
  api_id           = aws_apigatewayv2_api.api.id
  authorizer_type  = "JWT"
  identity_sources = ["$request.header.Authorization"]
  name             = var.api.jwt_authorizer_name

  jwt_configuration {
    audience = [aws_cognito_user_pool_client.client.id]
    issuer   = "https://${aws_cognito_user_pool.user_pool.endpoint}"
  }
}

Obtención del token JWT

En primer lugar, deberemos abrir la interfaz proporcionada por Cognito para realizar los procesos de sign-up, sign-in. La podremos encontrar dentro de la consola de AWS, en el servicio de Cognito, dentro de la configuración del cliente de aplicación «Lanzar interfaz de usuario alojada».

    1. Procederemos a registrar un usuario

    2. Nos pedira que confirmemos el usuario a través del enlace enviado a nuestra cuenta de correo introducida.

    3. El correo recibido tendrá la siguiente forma:

    4. Accedemos al enlace de VERIFY EMAIL

    5. Finalmente tendremos ya nuestro usuario confirmado en nuestro pool de usuarios de Cognito.

    6. Procedemos a logearnos en la interfaz de AWs empleada anteriormente y si los credenciales son correctos nos devolverá a la url de callback configurada cuando hemos creado el pool de usuarios con Terraform junto a un code que emplearemos posteriormente para obtener el token.

  1. Por último, para poder obtener el token debemos realizar una llamada al endpoint de Cognito /oauth2/token con los siguientes atributos en el body.
  • Metodo POST
  • Body
    • Aplicacion x-www-form-urlencoded.
    • Grant_type: authorization_code.
    • Client_id: tu id de la aplicación de Cognito.
    • Redirect_uri: url callback.
    • Code: código obtenido en la url de callback después de “?code=”

Obtendremos como respuesta el identity token (id_token) que contiene toda la informacion personal del usuario y es el que generalmente se empleará para la autorización y el access_token empleado principalmente para llamar a servicios externos sin incluir informacion personal del usuario. Dependiendo del caso de uso, si realmente la información aportada por el identity token no es necesaria, es recomendable emplear el access_token. Por ultimo el refresh token, se emplea principalmente para obtener un identity o access tokens nuevos.

Microservicios

Los microservicios seran desplegados en Api Gateway y tendrán como backend Lambda integrada como proxy y DynamoDB como bbdd. Todos estos servicios funcionan de forma completamente administrada siguiendo los objetivos serverless de esta práctica.

Vamos a definir brevemente estos servicios y ver cual es su papel dentro de la arquitectura.


AWS Api Gateway v2

Mediante Api Gateway podremos desarrollar APIs de una forma sencilla, segura y escalable, ademas de ofrecernos la integración con Lambda para poder operar sin aprovisionamiento. Solo funciona con HTTPs

Dispone de integración proxy para exponer por completo el request como input al backend. En el caso concreto del workshop se empleará Lambda Proxy Integration para poder consumir los parámetros desde el handler de la función vía el evento, para ello deberemos definir en la etapa de implementación POST como tipo, independientemente de que definamos el metodo HTTP del endpoint como GET.

Api Gateway es compatible con CloudFront como de CDN de la API, además es posible incorporar WAF como servicio de mitigación de ataques DDoS.

AWS actualmente dispone de dos versiones de Api Gateway, nosotros desplegaremos la última version, v2.

¿Que diferencias podemos encontrar? Los principales cambios introducidos con la version 2, se basan en:

  • Reducción de costes: 70%, 3.5$ vs 1$ por millón de peticiones.
  • Reducción de la latencia sobre el 50%.
  • Soporte a referencias cruzadas CORS.
  • JWT Authorizers a traves de OIDC y OAuth 2.0.
  • Disponible ruta y stages predeterminadas.
  • Integrado con SAM y CloudFormation.

Para poder crear nuestra Api deberemos crear los siguientes recursos

  • Api: indicando el nombre y su protocolo.
  • Un grupo de registros de Cloudwatch para la Api.
  • Un stage de implementación donde indicaremos el nombre de la implementacion y los parametros de los logs.
resource "aws_apigatewayv2_api" "api" {
  name          = var.api.api_name
  protocol_type = "HTTP"
}

resource "aws_cloudwatch_log_group" "api_gw" {
  name = "/aws/api_gw/${aws_apigatewayv2_api.api.name}"
  retention_in_days = 30
}

resource "aws_apigatewayv2_stage" "stage" {
  api_id = aws_apigatewayv2_api.api.id

  name        = var.api.stage_name
  auto_deploy = true


  access_log_settings {
    destination_arn = aws_cloudwatch_log_group.api_gw.arn

    format = jsonencode({
      requestId               = "$context.requestId"
      sourceIp                = "$context.identity.sourceIp"
      requestTime             = "$context.requestTime"
      protocol                = "$context.protocol"
      httpMethod              = "$context.httpMethod"
      resourcePath            = "$context.resourcePath"
      routeKey                = "$context.routeKey"
      status                  = "$context.status"
      responseLength          = "$context.responseLength"
      integrationErrorMessage = "$context.integrationErrorMessage"
    }
    )
  }
}

Una vez creada la Api, crearemos los dos endpoints que emplearemos en este workshop: GET,POST

Para ambos indicaremos:

  • Tipo de autorización: JWT
  • Tipo de integración AWS_PROXY, para recibir integramente en la funcion lambda la request
  • Metodo de integración sera POST aun cuando el método del endpoint se declare como GET, ya que Lambda solo se activa a traves de peticiones POST.
  • Id del autorizador creado jwtAuth que tendrá como audience el id de la aplicación Cognito creada y su endpoint como issuer.
  • Se creará además un permiso de ejecución de la función Lambda especificada para su ejecución por parte de ApiGateway

 

GET

#### GET
resource "aws_apigatewayv2_integration" "get_item_app_integration" {
  api_id           = aws_apigatewayv2_api.api.id
  integration_type = "AWS_PROXY"
  description               = "Lambda GET example"
  integration_method        = "POST"
  integration_uri           = aws_lambda_function.get_item_app.invoke_arn
}

resource "aws_apigatewayv2_route" "get_item_app_route" {
  api_id = aws_apigatewayv2_api.api.id

  route_key = "GET /user"
  target    = "integrations/${aws_apigatewayv2_integration.get_item_app_integration.id}"
  authorization_type = "JWT"
  authorizer_id = aws_apigatewayv2_authorizer.jwtAuth.id
}

resource "aws_lambda_permission" "get_item_app_execution" {
  statement_id  = "AllowExecutionFromAPIGateway"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.get_item_app.function_name
  principal     = "apigateway.amazonaws.com"
  source_arn = "${aws_apigatewayv2_api.api.execution_arn}/*/*"
}

POST

resource "aws_apigatewayv2_integration" "create_item_app_integration" {
  api_id           = aws_apigatewayv2_api.api.id
  integration_type = "AWS_PROXY"
  description               = "Lambda example"
  integration_method        = "POST"
  integration_uri           = aws_lambda_function.create_item_app.invoke_arn
}

resource "aws_apigatewayv2_route" "create_item_app_route" {
  api_id = aws_apigatewayv2_api.api.id

  route_key = "POST /user"
  target    = "integrations/${aws_apigatewayv2_integration.create_item_app_integration.id}"
  authorization_type = "JWT"
  authorizer_id = aws_apigatewayv2_authorizer.jwtAuth.id
}

resource "aws_lambda_permission" "create_item_app_execution" {
  statement_id  = "AllowExecutionFromAPIGateway"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.create_item_app.function_name
  principal     = "apigateway.amazonaws.com"
  source_arn = "${aws_apigatewayv2_api.api.execution_arn}/*/*"
}

AWS Lambda

Para el desarrollo de la lógica de nuestros microservicios emplearemos AWS Lambda, servicio de computación completamente administrado con escalado automático. Donde se definen unos recursos de memoria y CPU para realizar la ejecución de cada función. Soporta de forma nativa lenguajes como Java, NodeJS, Python, etc. Las funciones son albergadas en un paquete de implementación del tipo zip alojadas en un bucket de S3 interno o creado por nosotros.

 

En primer lugar, crearemos el rol de ejecución, donde además definiremos que acciones se pueden ejecutar dentro de estas y sobre que servicios, en nuestro caso simplemente permitiremos acciones CRUD sobre la tabla DynamoDB especifica que crearemos posteriormente.

  • Crearemos el rol de Lambda y daremos permisos al servicio de Lambda para asumirlo
  • Crearemos dos políticas básicas que serán asignadas a este rol: ejecución (permiso para cargar registros en CloudWatch) y una segunda política custom donde estarán definidas las acciones que podrán realizarse sobre la tabla de DynamoDb empleada para el workshop.
resource "aws_iam_role" "lambda_exec_dev" {
  name = "serverless_lambda_dev"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Sid    = ""
      Principal = {
        Service = "lambda.amazonaws.com"
      }
    }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_policy_attachment_dev" {
  role       = aws_iam_role.lambda_exec_dev.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

resource "aws_iam_role_policy_attachment" "lambda_dynamodb_policy_attachment_dev" {
  role       = aws_iam_role.lambda_exec_dev.name
  policy_arn = aws_iam_policy.lambda_dynamodb_policy_dev.arn
}

resource "aws_iam_policy" "lambda_dynamodb_policy_dev" {
  name        = "lambda_dynamodb_policy_dev"
  description = "Lambda DynamoDB access"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "dynamodb:Query",
          "dynamodb:GetItem",
          "dynamodb:PutItem",
          "dynamodb:UpdateItem",
          "dynamodb:BatchWriteItem",
          "dynamodb:BatchGetItem",
        ]
        Effect   = "Allow"
        Resource = [aws_dynamodb_table.app_table.arn]
      },
    ]
  })
  depends_on = [aws_dynamodb_table.app_table]
}

Las funciones irán recogidas en un zip con el codigo Python que será subido a un bucket interno que crearemos expresamente para albergarlas. En cada función indicaremos su handler, runtime, rol de ejecución y el bucket/objeto donde poder encontrar el paquete de funciones.

data "archive_file" "lambda_functions_package" {
  type = "zip"

  source_dir  = "${path.module}/scripts/"
  output_path = "${path.module}/scripts/crud_lambdas.zip"
}

resource "aws_s3_bucket_object" "lambda_functions_package_object" {
  bucket = aws_s3_bucket.internal_dev.bucket
  key    = "crud_lambdas.zip"
  source = data.archive_file.lambda_functions_package.output_path
  etag = filemd5(data.archive_file.lambda_functions_package.output_path)
}

resource "aws_s3_bucket" "internal_dev" {
  bucket = var.bucket_name
  acl    = "private"
}

Para su creacion simplemente indicaremos el nombre de la función Lambda, rol de ejecución, runtime, la función de ejecucíon, el bucket y el zip donde estan alojadas.

  • La función get_item_app nos devolvera el usuario buscado por id.
  • La función create_item_app permitira guardar el usuario en bbdd.
resource "aws_lambda_function" "get_item_app" {
  function_name = "get_user"
  handler       = "get_user.lambda_handler"
  runtime       = "python3.6"

  s3_bucket = aws_s3_bucket.internal_dev.bucket
  s3_key    = aws_s3_bucket_object.lambda_functions_package_object.key
  source_code_hash = data.archive_file.lambda_functions_package.output_base64sha256
  role = aws_iam_role.lambda_exec_dev.arn
}

resource "aws_lambda_function" "create_item_app" {
  function_name = "create_user"
  handler       = "create_user.lambda_handler"
  runtime       = "python3.6"

  s3_bucket = aws_s3_bucket.internal_dev.bucket
  s3_key    = aws_s3_bucket_object.lambda_functions_package_object.key
  source_code_hash = data.archive_file.lambda_functions_package.output_base64sha256
  role = aws_iam_role.lambda_exec_dev.arn
}

Estas funciones Python emplearán la librería boto3 para poder realizar de una forma sencilla y rápida el conector contra la tabla de DynamoDB, estarán alojadas bajo el directorio de /scrips.

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('AppDummy')

A partir de este conector mediante table.get_item() o table.create_item() podremos realizar nuestras operaciones GET y POST respectivamente. Si la acción se ejecuta correctamente lanzaremos un codigo 200 y devolveremos el objeto añadido/obtenido.

  • En la funcion create_user obtendremos los atributos del body de la request que se encontrarán en el propio evento al ser una función integrada como AWS_PROXY.
item = json.loads(event["body"])
user = item["User"]
...
table = dynamodb.Table('AppDummy')
    response = table.put_item(
        Item=user
    )
...
  • En la función get_user encontraremos el atributo de búsqueda UserId dentro del evento en “queryStringParameters”.
id = str(event["queryStringParameters"]['UserId'])
...
response = table.get_item(
        Key={
            'UserId': id
        }
    )
...

AWS DynamoDB

Por último, crearemos una tabla básica para albergar los atributos de nuestros usuarios, tendrá simplemente como PK el id de usuario en string para soportar alfanuméricos.

resource "aws_dynamodb_table" "app_table" {
  name           = "AppDummy"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "UserId"

  attribute {
    name = "UserId"
    type = "S"
  }
}

Despliegue

Mediante Terraform desplegaremos nuestra infraestructura, primero deberemos lanzar un init que descargará los plugins y inicializará nuestro directorio de trabajo con los archivos de configuración de AWS, para posteriormente ejecutar un plan, si el despliegue de recursos planificado por el plan concuerda con lo que buscamos finalmente ejecutaremos un apply para desplegar toda nuestra infra y realizar las pruebas.

En esta práctica, nuestro estado permanecera en local, no configuraremos AWS como backend para los estados de Terraform

terraform init

terraform plan -var-file="env/dev.tfvars"

terraform apply -var-file="env/dev.tfvars"

Pruebas

Una vez desplegado nuestro proyecto, comprobaremos el correcto funcionamiento de los microservicios que hemos programado. Además en ambos casos, deberemos añadir el campo authorization en el header de la peticion HTTP con el prefijo Bearer y el access_token obtenido anteriormente para poder ser autorizados a consumir el microservicio.

POST /user

En primer lugar, probaremos la peticion HTTP POST /user, debería añadir el usuario a la tabla de DynamoDB creada y enviando como respuesta un codigo 200 y el usuario añadido a la tabla.

GET /user

De la misma forma, consumiremos el microservicio que a partir del UserId nos devolverá la información del usuario, recordando que al ser una petición GET la información relativa a la consulta irá en el Query Params (propia url)

Conclusión

En esta práctica hemos podido aprender a como desarrollar una API Rest segura y completamente administrada dentro del entorno de AWS, sirviendonos de la última versión de Api Gateway que facilita la integración nativa con autorizadores de JWT.

La integración de Cognito con Api Gateway nos torga la capa de seguridad y administración de los usuarios. Respectivamente con Lambda y DynamoDB disponemos de la capa de lógica/persistencia de nuestra API. La integración nativa de todos estos servicios nos facilita el desarrollo de estas aplicaciones al disminuir la carga de trabajo dedicada tanto al desarrollo puro, como a la integracion de los distintos servicios involucrados y su administración, además gracias a Terraform disponemos de toda la infraestructura como código facilitando su futura evolución y disponibilización en otros entornos de una forma mucho más rápida y comprensible.

En futuras entradas veremos como desarrollar otros escenarios típicos que podemos encontrar en nuestro día a día dentro de AWS, con el fin de tener unas primeras herramientas para poder solventar futuros escenarios que se nos planteen.

Espero que la práctica haya sido de vuestro agrado e interés, os espero en futuras entregas!

Enlaces de interés

Navegación

Introducción

Requisitos

Overview

Autenticación y Autorización

Microservicios

Despliegue

Pruebas

Conclusión

Enlaces de interés

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

Francisco Linaje

AWS Solutions Architect

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

© 2025 Bluetab Solutions Group, SL. All rights reserved.