Notas sobre el examen AWS Solutions Architect Professional (Español)

Puse la mira en la certificación Solutions Architect Professional hace un tiempo, pero por varias razones no pude encontrar tiempo para sentarme a estudiar sino hasta principios de este año. El 6 de abril finalmente rendí el examen y lo aprobé con un puntaje de 859. Este es mi recuento de cómo me preparé para el mismo, cómo se sintió el examen, y un montón de notas que fui tomando sobre pequeños detalles técnicos que pueden hacer la diferencia en una pregunta.

Si bien tenía algo de experiencia como arquitecto freelance e instructor autorizado de AWS, el último año me encontró trabajando mucho con código y con GCP, y apenas tocando AWS, así que sabía que necesitaba un curso completo que me ayudara a recordar lo básico (si es que se me había olvidado algo) y también elevar mi nivel en cosas avanzadas. Elegí el curso AWS Certified Solutions Architect - Professional de Adrian Cantrill (en inglés) para eso, y fue excelente, aunque bastante largo.

Me tomó más de un mes y medio terminar el curso de Adrian, pero luego de eso me sentía bastante bien, con sus excelentes lecciones y demos. Sin embargo, sabía que algo me debía faltar, en mi memoria si no en el curso de Adrian, así que me metí a AWS SkillBuilder y encontré el curso Exam Readiness: AWS Certified Solutions Architect – Professional (disponible en inglés y en español). Dice 4 horas, pero creo que deberías dedicarle al menos 6, porque si bien el curso no te enseña nada nuevo, te ayuda mucho a reflexionar sobre qué te está faltando e identificar tus puntos débiles, y eso es lo que va a guiar tus próximos pasos.

Mis puntos débiles no estaban concentrados en una sola área, ya que esos ya los había identificado antes y los había cubierto volviendo a mirar las lecciones de Adrian tantas veces como fuera necesario (creo que miré las de Direct Connect 4 o 5 veces). En vez de no saber un servicio o un tipo de solución, mis puntos débiles estaban en todos lados, no en aspectos generales sino en pequeños detalles que eran importantes.

Algunos detalles no tan pequeños:
Si estás conectando Direct Connect a una VPC sin una VPN, deberías usar un VIF público o privado? Y si estás usando site-to-site VPN? Respuesta: Privado cuando vas a la VPC de forma directa, público cuando se usa VPN porque Site-to-Site VPN es un servicio público (es decir, no está dentro de una VPC, al igual que S3 por ejemplo).
Es Kinesis Firehose capaz de streamear datos en tiempo real (real time)? Respuesta: No, tiene una latencia de 60 segundos, y se considera near-real time, NO real time (tiempo real).

Algunos de los detalles mucho más pequeños:
En ALB, podés asociar múltiples certificados SSL a un mismo listener? Si es así, cómo hace el listener para elegir el certificado correcto: Respuesta: Sí, y el listener automáticamente elige el certificado correcto utilizando SNI.
Los datos en un Kinesis Data Stream están ordenados? Respuesta: Sí dentro del shard, no entre varios shards.
En SQS con un retention period de 7 días, si un mensaje se mueve a la DLQ 5 días después de ser encolado, cuándo será borrado? Respuesta: En 2 días, ya que el retention period chequea el enqueue timestamp, el cual no se modifica cuando un mensaje se mueve a la DLQ.

Así que sabía que me faltaban cosas, pero no sabía para qué preguntas necesitaba buscar respuestas. Intenté leer las preguntas frecuentes (FAQs), pero son MUY LARGAS y llenas de UN MONTÓN de información que probablemente no es relevante para el examen (aunque al nivel professional deberías asumir que todo es relevante). Después de como media hora de leer las preguntas frecuentes y aburrirme mucho, busqué exámenes de práctica, para poder cometer mis propios errores y aprender de esa forma. Encontré AWS Certified Solutions Architect Professional Practice Exams 2022 en TutorialsDojo (en inglés), y los compré.

Como breve nota, los exámenes de práctica de TutorialsDojo no son excelentes, pero son lo suficientemente buenos. La mayoría de las respuestas son correctas y las explicaciones son bastante buenas. Unas pocas son un poco más cuestionables, y encontré una o tres que eran totalmente ridículas o directamente imposibles desde el punto de vista técnico. Aun así, una o tres de 375 (4 exámenes de práctica más 1 examen final) es bastante bueno. Tan solo tené en cuenta que, ante la duda, deberías buscar la documentación y tratar de encontrar la respuesta correcta por tu cuenta. Si alguien conoce mejores exámenes de práctica, coméntenmelo y los agrego a las recomendaciones.

A esta altura hacer exámenes de práctica es por lejos lo mejor que podés hacer, en mi opinión. Cometer tus propios errores (TutorialsDojo te dice qué preguntas respondiste bien o mal, cuál es la respuesta correcta y por qué) realmente te ayuda a recordar esos pequeños detalles que hacen la diferencia. Además, podés hacer medio examen, o 10 preguntas, cuando tengas tiempo. Recomiendo hacer al menos uno o dos exámenes completos con tiempo, pero no necesitás tener sesiones de estudio de 3 horas o nada, si sólo tenés 30 minutos es mejor responder 5 o 10 preguntas que no hacer nada. También, escribí todo, para que puedas releer tus notas después.

Otro tema muy importante de los exámenes de práctica es que podés practicar la gestión del tiempo. Tenés 180 minutos para responder 75 preguntas, lo cual son 2 minutos y 24 segundos por pregunta. Si rendís el examen en inglés y no es tu lengua madre, podés pedir una extensión de 30 minutos al momento de registrarte para el examen. Con esa extensión son 210 minutos, 2 minutos 48 segundos por pregunta. Con o sin extensión no parece mucho tiempo, y eso es porque no es mucho tiempo. Las preguntas son muy largas, mucho más largas que en el examen de SA Associate, y la respuesta correcta a veces depende de una palabra o dos. Te vas a encontrar leyendo respuestas de 4 o 5 líneas que parecen exactamente idénticas, hasta que encontrás la diferencia: VPC pública o privada, por ejemplo. Otras veces la que parece ser la mejor respuesta tiene un detalle que hace que no sea factible. Por ejemplo, una respuesta podría describir desplegar la aplicación en una subred privada y agregar un interface VPC endpoint para acceder a DynamoDB, mientras que otra propone desplegar la aplicación en una subred pública y acceder a DynamoDB a través de internet. Debería ser obvio a esta altura que es posible acceder a DynamoDB a través de la internet o de una VPC endpoint, y que acceder a través de una VPC endpoint es mucho más preferible (por costos, seguridad, latencia, etc), así que podrías verte tentado a elegir la primera opción. Sin embargo, si prestás atención vas a notar que un interface VPC endpoint no puede ser utilizado para acceder a DynamoDB, sólo se puede utilizar un gateway VPC endpoint, así que si bien enviar el tráfico a través de la red interna de AWS sería la solución ideal, entre las dos soluciones presentadas la segunda es la única que es técnicamente posible, por lo tanto es la respuesta correcta. Sí, ambas cosas importan: saber la diferencia entre un interface VPC endpoint y un gateway VPC endpoint, y leer cuidadosamente. Entonces, el tiempo es poco, pero leé todas las opciones con cuidado, descartá lo que puedas, y elegí entre lo que quede.

Un detalle final acerca de los tiempos: Luego de responder las primeras 10 preguntas, te deberían quedar más de 156 minutos (182 con la extensión de tiempo). Si estás muy cerca de ese número (incluso si estás un poquito por debajo), estás bastante bien, ya que toma una o cinco preguntas agarrar ritmo. Si tenés mucho menos que eso, vas a tener que apresurarte un poco o no te va a alcanzar el tiempo. El siguiente punto a tener en cuenta puede ser al empezar la pregunta 21 (es decir habiendo respondido 20 preguntas), que debería encontrarte con 132 minutos o más (154 con la extensión), o al inicio de la pregunta 26, que significa que completaste un tercio del examen y te deberían quedar 120 minutos (140 con la extensión) o más en el reloj. La pregunta 31 son 108 minutos (126 con la extensión), la pregunta 39 es la mitad del examen y 90 minutos (105 con la extensión), la pregunta 51 son dos tercios y 60 minutos (70 con la extensión), la 61 son 36 minutos (42 con la extensión) y la 71 son 12 minutos (14 con la extensión). Obviamente vas a querer mantener un buffer por si al final del examen se agruparon 2 o 3 preguntas muy largas, además vas a querer tiempo extra para revisar las preguntas que hayas marcado para revisión. A veces la mejor estrategia es rápidamente descartar algunas opciones y, si quedan dos opciones posibles, simplemente elegir una y aceptar ese 50% de probabilidades de acertarle, y marcar la pregunta para revisión por si tenés el tiempo de revisar tu elección y mejorar ese 50% de probabilidades. Tratá de memorizar esos hitos de tiempo, o al menos los que te parezcan importantes, para que no desperdicies preciados minutos tratando de calcular si tenés unos minutos de sobra.

En cuanto a recursos que utilicé para preparar el examen, eso fue todo. El excelente curso de Adrian (80 USD), el curso Exam Readiness de AWS (gratis) y los no-tan-excelentes-pero-igualmente-buenos exámenes de práctica de TutorialsDojo (15 USD), lo cual suma 95 USD, además de los 300 USD que cuesta el examen. Tomé algunas notas, las cuales leí de vez en cuando mientras estudiaba y un par de veces el día antes del examen, y busqué en Google todo en lo que me equivoqué en los exámenes de práctica. Creo que eso es todo lo que tengo para aportarles, pero si tienen alguna pregunta, siéntanse libre de comentar o de escribirme un mensaje, los voy a ayudar en todo lo que pueda.

Recuerden estudiar los pequeños detalles, recuerden prestarle atención al tiempo, y más que nada recuerden que pueden lograrlo!

Como nota final, estas son las notas que fui tomando. NO están completas, saber todo esto NO es suficiente para aprobar el examen, pero si no sabés al menos el 90% de esto, te va a costar un poco. Estas son simplemente las áreas en las que me faltaba conocimiento (por eso no anoté nada sobre servicios importantes como EC2). Mi recomendación es que tomes tus propias notas, para ayudarte con tus puntos débiles. Además, la sección de EBS tiene UN MONTÓN de números, que no resultaron ser tan relevantes. De todos modos, tené en cuenta los casos de uso para cada tipo de volumen.

EBS:

• GP2:
• 1 IOPS = 1 IO (16 KB) en 1 segundo.
• Max IO credits = 5.4 millones. Empieza completo. Se llena al ritmo de Baseline Performance. Por encima del mínimo de 100 IO credits, 3 IO credits por segundo por GB de volume size.
• Burst hasta 3000 IOPS o el ritmo de llenado
• Volúmenes de más de 1000 GB tienen baseline performance más alta que 3000 IOPS y no usan credits.
• GP3:
• 3000 IOPS & 125 MiB/s standard (sin importar tamaño)
• Va hasta 16000 IOPS o 1000 MiB/s
• Performance no escala con tamaño, se escala por separado. Es aprox 20% más barato que GP2
• Provisioned IOPS
• Latencia y jitter consistentemente bajas.
• 64000 IOPS, 1000 MB/s (256000 IOPS & 4000 MB/s para Block Express)
• 4 GB a 16 TB (64 TB para Block Express)
• IO1: 50 IOPS/GB max. IO2: 500 IOPS/GB max.
• IOPS se pueden ajustar independientemente del tamaño
• Limitaciones reales para la performance entre EBS y EC2:
• - Performance por instancia: IO1: 260000 IOPS & 7500 MB/s, IO2: 160000 IOPS & 4750 MB/s, IO2 Block Express: 260000 IOPS & 7500 MB/s
• - Limitaciones del tipo y tamaño de la instancia EC2
• Casos de uso: Pequeños volúmenes con muy alta performance, performance extrema, cargas de trabajo sensibles a la latencia.
• HDD
• st1: más barato que SSD, muy malo para random access. Max 500 IOPS, pero 1 MB por IO. Max 500 MB/s. 40 MB/s/TB base, 250 MB/s/TB burst. Tamaño 125 GB a 16 TB. Caso de uso: acceso secuencial, big data, data warehouses, procesamiento de logs.
• sc1: aun más barato, pero frío, diseñado para cargas de trabajo infrecuentes. Max 250 IOPS pero 1 MB por IO. Max 250 MB/s. 12 MB/s/TB base, 80 MB/s/TB burst. Tamaño 125 GB a 16 TB.
• Instance Store volumes
• Dispositivos de almacenamiento en bloques (como EBS) pero local para la instancia. Físicamente conectado al EC2 host. Las instancias en ese host lo pueden acceder.
• Incluido en el precio (para tipos de instancia que lo tienen), usarlo o desperdiciarlo.
• Asociado al lanzar la instancia.
• Almacenamiento efímero. Si la instancia se mueve a otro host, los datos en el instance volume se pierden.
• El tamaño depende del tipo y tamaño de la instancia.
• EC2 instance type D3 = 4.6 GB/s throughput
• EC2 instance type I3 = 16 GB/s sequential throughput
• Cómo elegir entre EBS y Instance Store:
• Persistencia, resiliencia, backups o aislamiento del ciclo de vida de la instancia: elegir EBS
• Costo para EBS: ST1 o SC1 (ambos son hard disks)
• Throughput o streaming: ST1
• Boot volume: NO ST1 o SC1
• Hasta 16000 IOPS: GP2/3
• Hasta 64000 IOPS: IO2
• Hasta 256000 IOPS: IO2 Block Express
• Hasta 260000 IOPS: RAID0 + EBS (IO1/2-BE/GP2/3) (esta es la máxima performance para una instancia EC2)
• More than 260000 IOPS: Instance Store (pero no es persistente)
• Soporta encriptación, pero NO habilitado por defecto.

EC2:

• Placement groups: Cluster: mismo rack, más performance de network, una AZ, soporta instance type, para alta velocidad y baja latencia. Spread: siempre racks distintos, 7 instancias por AZ, para instancias críticas. Partition: Max 7 particiones, cada una puede tener más de 1 instancia, genial para apps conscientes de la topología (topology-aware) como HDFS, HBase y Cassandra

ELB:

• GWLB: L3 LB para ingress/egress security scans, para pasar el tráfico a través de 3rd party appliances escalables, usando el protocolo GENEVE. Usa GWLB Endpoint, el cual puede ser agregado a una RT como el próximo salto. Los paquetes no se alteran.
• ALB:
• - Puede tener múltiples certificados SSL asociados a un secure listener y automáticamente elige el certificado óptimo usando SNI.

DynamoDB:

• Local Secondary Indexes (LSI): Sólo se pueden crear al crear la tabla. Usan la misma PK pero una SK diferente. Además de las keys, se puede proyectar ninguno, algunos o todos los atributos. Comparte capacidad con la tabla. Son sparse: sólo los items con valores en la PK y SK son proyectados. Usa strong consistency.
• Global Secondary Indexes (GSI): Puede ser creado en cualquier momento. PK y SK diferentes. Allocations de RCU y WCU propias. Además de keys, puede proyectar ninguno, algunos o todos los atributos. Son sparse: sólo los items con valores en PK y SK son proyectados. Son eventually consistent, la replicación entre la tabla base y el GSI es async.
• En LSIs y GSIs se pueden hacer queries a atributos no proyectados, pero es caro.
• Streams: Un Kinesis Stream con 24-h rolling window con cambios de items en una tabla, ordenados por tiempo. Habilitado por tabla. Graba INSERTS, UPDATES y DELETES. Diferentes tipos de vista: KEYS_ONLY, NEW_IMAGE, OLD_IMAGE y NEW_AND_OLD_IMAGE.

Athena:

• Servicio serverless de queries interactivas. Gratis, sólo se paga por los datos consumidos. Traducción table-like schema-on-read. Los datos originales nunca se cambian, se mantienen en S3. El esquema traduce los datos a algo parecido a relacional cuando lee. También se pueden hacer queries de logs de AWS, logs de web servers o Glue Data Catalogs. Puede usar Athena Federated Queries para usar una Lambda para transformar los datos antes de consultar.

Kinesis

• Data stream: Sub-1-segundo, procesamiento custom por registro, elección de framework de procesamiento del stream. Multi-shard. 1 shard = 1 MB ingestión y 2 MB consumo. El orden se garantiza dentro del shard, pero no entre shards. Rolling window de 24h (hasta 7d pagando más $$$). Múltiples consumidores.
• Firehose: Conecta a un data stream o ingesta de múltiples orígenes. Cero admin (automáticamente escalable, serverless y resiliente), >60 segundos latencia, Entrega datos a herramientas de analítica existentes: HTTP como splunk, ElasticSearch y OpenSearch, S3 y Redshift (a través de un bucket de S3 intermedio). El orden está garantizado. Soporta transformación de los datos on the fly. Se cobra por datos en el stream.
• Differencia entre SQS y Kinesis data streams: SQS tiene 1 production group y 1 consumer group, y una vez que un mensaje es consumido se borra. Típicamente se usa para desacoplar comunicación asíncrona. Kinesis está diseñado para ingestión de datos a escala enorme y múltiples consumidores dentro de la rolling window. Está diseñado para ingestión de datos, analítica, monitoreo, app clicks y streaming.
• Kinesis Data Analytics: procesamiento en tiempo real de datos usando SQL. Ingesta de Data streams o Firehose o S3, procesa y envía a Data streams, Lambda o Firehose. Se posiciona entre 2 streams y te permite usar SQL para modificar los datos.

Elastic MapReduce (EMR):

• Implementación gestionada de Hadoop, Spark, HBase, Presto, Flink, Hive y Pig.
• Procesamiento en paralelo de escala enorme. Dos fases: Map y Reduce. Map: Los datos se separan en ‘splits’, cada uno asignado a un mapper. Realiza operaciones custom en escala. Reduce: Recombina los datos en resultados.
• Se pueden crear clusters para long-term usage o ad-hoc (transient) usage.
• Funciona en una AZ en una VPC (NO HA) usando EC2 para compute. Escala automáticamente y puede usar spot, instance fleet, reserved y on-demand.
• Carga data de S3 y genera salidas a S3.
• Usa Hadoop File System (HDFS). Los datos se almacenan en múltiples data nodes y se replican entre nodos para fault tolerance.
• Tipos de nodos:
• - Master (al menos 1): Gestiona el cluster y la salud, distribuye las cargas de trabajo y controla acceso a HDFS y acceso SSH al cluster. No usar spot instances.
• - Core (0 o más): Son los data nodes para HDFS, ejecutan task trackers y pueden ejecutar tareas de map y reduce. HDFS funciona en instance store. No usar spot instances.
• - Task nodes (0 o más): Sólo ejecutan tasks, no ejecutan HDFS o task trackers. Ideal para instancias spot.
• EMRFS es un file system para EMR, respaldado por S3 (regionally resilient), persiste más allá de la vida del cluster y es resiliente a fallos de los core nodes. Es más lento que HDFS (S3 vs Instance Storage)

Redshift:

• Petabyte-scale data warehouse. OLAP (basado en columnas, no OLTP: filas/transacciones). Diseñado para agregar datos de BDs OLTP. NO diseñado para real-time ingestion, sino para batch ingestion.
• Provisioned (server-based). Single-AZ (no HA).
• Leader note: Query input, planning y aggregation. Las aplicaciones interactúan con el leader node usando ODBC o JDBC.
• Compute node: ejecuta queries de datos. Tienen particiones con los datos, replicadas a 1 nodo adicional.
• Snapshots automáticos a S3 cada 8h o 5GB con 1d (por defecto) a 35d retention, más snapshots manuales, hacen a los datos resilientes al fallo de una AZ. Puede ser configurado para ser copiado a otra región.
• DMS puede migrar a Redshift y Firehose puede streamear a Redshift.
• Redshift Spectrum: Queries directas a datos en S3. Federated query: Queries directas a datos en otras BDs.
• Para queries ad-hoc usar Athena.
• Puede copiar snapshots encriptados a otra región configurando un snapshot copy grant para la master key en la otra región.

Batch:

• Te permite preocuparte por definir batch jobs, se ocupa del compute.
• Job: script, ejecutable o docker container. La cosa a ejecutar.
• Job definition: Metadata para un job, incluyendo permisos, configuración de recursos, mount points, etc.
• Job queue: Los jobs son agregados a colas, donde esperan a que haya capacidad de compute. La capacidad viene de 1 o más compute environments.
• Compute environment: compute gestionado o no, configurable con instance type/size, cantidad de vCPU, precio de spot, o usando un entorno existente con ECS (sólo con ECS).
• Managed compute environment: Batch gestiona la capacidad, vos elegís on-demand o spot, instance size/type, max spot price. Se ejecuta en una VPC, se puede ejecutar en una VPC privada pero tenés que proveer gateways.
• Unmanaged compute environment: Vos creas todo y gestionás todo fuera de Batch (con ECS).
• Los jobs pueden venir de llamadas a la API de Lambda, integraciones con Step Functions o targets de EventBridge (por ejemplo de S3).
• Cuando se termina, puede almacenar los datos y metadatos en S3 y DynamoDB, puede continuar la ejecución de Step Functions, o enviar un post a Batch Event Stream.
• Diferencias con Lambda: Lambda tiene un límite de ejecución de 15 minutos, 10 GB de límite de espacio de disco (desde 2022/03/24, probablemente todavía no haya impactado en el examen, el límite anterior era 512 MB) y tiempo de ejecución limitado. Batch usa docker (así que cualquier runtime) y no tiene límites de recursos.

ElastiCache

• Redis: estructuras de datos avanzadas, persistente, multi-az, read replicas, puede escalar hacia arriba pero no hacia afuera (y no puede escalar hacia abajo), backups y restores. Highly available (multi-az)
• Memcached: simple K/V, no persistente, puede escalar hacia arriba y hacia afuera (múltiples nodos), multi-thread, no backup/restore. NO highly available

EFS y FSx

• FSx for Windows: ENIs inyectados en VPCs. Windows FS nativo, necesita estar conectado con Directory Service o self-managed AD, Single o Multi-AZ, on-demand y scheduled backups, accesible usando VPC, VPN, peering, direct connect. Encriptación at rest (KMS) y in transit. Keywords: VSS, SMB, DFS
• FSx for Lustre: ENIs inyectados en VPCs. HPC para Linux (POSIX). Usado para ML, big data o financial. 100s GB/s. tipos de despliegue: Scratch (short term, no replication) y Persistent (longer term, HA en una AZ, self-healing). Disponible por VPN o direct connect. Los datos son cargados lazy de S3 y puede sincronizar de vuelta a S3. < 1 ms latencia.
• EFS: NFSv4 FS para Linux. Mount targets en VPC. Modos General purpose y Max I/O. Modos Bursting y Provisioned throughput (aparte del tamaño). Standard y IA storage classes.
• Es imposible actualizar el deployment type (single-AZ o multi-AZ) de un file system FSx for Windows después de que fue creado. Para migrar a multi-AZ se debe crear un nuevo FS y usar DataSync para replicar los datos.

QuickSight:

• Herramienta BA/BI para visualizaciones y análisis ad-hoc.
• Soporta discovery y integration con AWS o fuentes de datos externas
• Usado para dashboards o visualización.

SQS:

• Visibility timeout: Por defecto es 30s, puede ser entre 0s y 12h. Se configura en la queue o por mensaje.
• Extended client library: para mensajes por encima del SQS max (256 KB). Permite payloads más grandes (hasta 2 GB) almacenadas en S3. SendMessage sube los datos a S3 automáticamente y almacena el link en el mensaje. ReceiveMessage carga el payload de S3 automáticamente. DeleteMessage también borra el payload de S3. El examen a menudo menciona Java.
• Delay queues: Postponer la entrega del mensaje (sólo en Standard queues). Configurar DelaySeconds y los mensajes van a ser agregados inmediatamente a la cola pero sólo van a ser visibles luego del delay. Min (por defecto) es 0s, max es 15m.
• Dead-letter queues: Cada vez que un mensaje es recibido (o expira el visibility timeout) en una queue, ReceiveCount se increments. Cuando ReceiveCount > maxReceiveCount el mensaje es movido a la dead-letter queue. Enqueue timestamp no se modifica (por lo tanto el Retention period es tiempo en la cola + tiempo en la DL queue).
• FIFO queue: Límite 3000 mensajes por segundo.

Amazon MQ:

• Open-source message broker basado en Apache ActiveMQ. JMS API con protocolos como AMQP, MQTT, OpenWire y STOMP. Provee queues y topics.
• Se ejecuta en una VPC con single instance o HA pair (active/standby)
• Comparación con SNS y SQS: SNS y SQS usan AWS APIs, son servicios públicos, highly scalable, AWS integrated. Amazon MQ está basado en ActiveMQ y usa protocolos JMS, AMQP, MQTT, OpenWire y STOMP. Fijarse en los protocolos en el examen. Además, SNS y SQS para apps nuevas, Amazon MQ para migraciones con pocos o ningún cambio a las apps.

Lambda:

• FaaS, corta ejecución (por defecto 3s, max 15m)
• Function = código + código de alrededor y configuración. Usa un runtime (Python, Ruby, Java, Go y C#), y se carga y ejecuta en un runtime environment. El environment tiene una allocation de memory directa (128MB a 10240 MB), de CPU y instance storage indirectos (por defecto 512 MB, max 10 GB (a partir del 2022/03/24, probablemente no haya impactado en el examen todavía, antes era fijo 512 MB)).
• Docker es un anti-patrón para lambda, lambda container images es algo diferente y es posible.
• Lambda container images: Incluye Lambda Runtime API (para ejecutarse) y Runtime Interface Emulator (para tests locales) en la imagen del container. La imagen se construye y se sube a ECR, luego opera normalmente.
• Usado para serverless apps, file processing (S3 events), DB triggers (DynamoDB), serverless cron (EventBridge), realtime stream data processing (Kinesis).
• Por defecto Lambda se ejecuta en el public space y no puede acceder a servicios dentro de una VPC. También se puede ejecutar dentro de una VPC (necesita permisos de EC2 Network). Técnicamente Lambda se ejecuta en una VPC separada (de servicios compartidos) y se crea un ENI en tu VPC por función (NO por invocación) y usa un NLB, con 90s para initial setup y sin delay adicional en las invocaciones.
• Lambda usa un Execution role (IAM role) el cual otorga permisos.
• También una resource policy puede controlar quién puede invocar la lambda.
• Lambda escribe logs a CW Logs, publica métricas a CW y puede usar X-Ray. Necesita permisos para esto, en el Execution role.
• La invocación puede ser Sync, Async y Event Source Mapping:
• - Sync: El CLI/API invoca y espera por la response. Lo mismo se utiliza a través de API Gateway. El cliente maneja errores o retries.
• - Async: Típicamente cuando los servicios de AWS invocan Lambdas, como S3. Lambda maneja los retries (configurable 0-2 veces). Debe ser idempotente!! Los eventos pueden ser enviados a una DLQ y distintos destinos (SQS, SNS, Lambda y EventBridge).
• - Event Source Mapping: Kinesis data streams envía batches de eventos a Lambdas usando Event Source Mapping. Lambda necesita permisos para acceder a la fuente (los cuales son usados en su lugar por Event Source Mapping). Puede usar DLQ para eventos fallidos.
• Una función tiene versiones inmutables (con su propio ARN llamado qualified, el unqualified ARN apunta a $latest), el cual incluye código + config (incluyendo env vars). $latest apunta a la última versión, y aliases como Dev, Stage, Prod pueden ser creados y actualizados. Una versión se crea cuando una Lambda es publicada, pero puede ser desplegada sin ser publicada. También podés crear aliases que apunten un % del tráfico a un alias y otro % del tráfico a otro alias.
• El contexto incluye runtime + variables creadas antes del handler + /tmp. El contexto puede ser reutilizado, pero no podemos controlar eso, tenemos que asumir siempre un nuevo contexto.
• Cold start: Provisionar hardware, instalar environment, descargar código, ejecutar el código antes del handler. Se puede pre-calentar usando Provisioned concurrency. NO se te cobra por el tiempo de cold-start (ni siquiera por el código antes del handler).
• Execution process: Init (cold start) (de ser necesario), Invoke (ejecuta el function Handler), Shutdown (destruir el environment).
• Layers: Compartir y reutilizar código externalizando librerías, las cuales son compartidas entre funciones. También permite nuevos runtimes no soportados, como Rust. El zip de despliegue sólo contiene código específico (es más pequeño). Se pueden utilizar layers de AWS o escribir propias.
• Lambda + ALB: ALB invoca Lambda sincrónicamente (automáticamente traduce requests HTTP(s) a Lambda event).
• Multi-value headers: (Cuando se usa ALB + Lambda) Agrupa valores de query strings por key, por ejemplo http://a.io?&search=a&search=b es pasado como multiValueQueryStringParameters:{"search": ["a","b"]}. Si no se usan Multi-value headers, sólo el último valor es enviado, por ejemplo "queryStringParameters": {"search":"b"}

API GW:

• Highly available, scalable, maneja auth (directlamente con Cognito o con un Lambda authorizer), throttling, caching, CORS, transformations, OpenAPI spec, direct integration.
• Se puede conectar a servicios en AWS o on-prem
• Soporta HTTP, REST y WebSocket
• Endpoint types: Edge-optimized: Enrutado al punto CloudFront POP más cercano, Regional: Clientes en la misma región, Private: Endpoint accesible sólo dentro de una VPC via interface endpoint
• APIs son desplegadas como stages, cada stage tiene un deployment. Stages pueden ser environments (dev, prod) o versiones (v1, v2). Cada stage tiene su propia config. NO son inmutables, pueden ser modificadas y se puede hacer roll back. Las stages pueden ser habilitadas para canary deployments.
• 2 fases: Request: Authorize, validate y transform. Response: transform, prepare y return. Request es llamada method request y es convertida a integration request, el cual es pasado a el backend. Response es llamado integration response, el cual es convertido a method response y es retornado al cliente.
• Tipos de integration: Mock: Para testing, no backend. HTTP: Configurar translation para method->integration request y integration->method response en el API GW. HTTP Proxy: Pasar la request sin modificaciones, retornar al cliente sin modificaciones (backend necesita usar un formato soportado). AWS: Expone AWS service actions. AWS_PROXY(Lambda): Low admin overhead Lambda endpoint.
• Mapping templates: Usado para AWS y HTTP (non-PROXY) integrations. Modificar o renombrar parámetros, cuerpo o headers de la request/response. Usa Velocity Template Language (VTL). Puede transformar request REST a una SOAP API.
• API GW tiene un timeout de 29s (no se puede incrementar)
• Errores: 4XX: Client error, invalid request del lado del cliente. 5XX: Server error, valid request, problema del backend. 400: Bad request, genérico. 403: Access denied, authorizer denies o WAF filtered. 429: API GW throttled la request. 502: Bad GW, bad output retornada por el backend. 503: Service unavailable, backend offline?. 504: Integration failure/timeout, se alcanzó el limite de 29s.
• Cache: TTL 0s a 3600s (por defecto 300s), 500 MB a 237 GB, puede ser encriptado. Definido por stage. Request sólo va al backend si hay un cache miss.
• Payload limit: 10 MB

CloudFront:

• Private behaviors: Un behavior puede ser convertido en private si usa un Trusted Signer (key creada por root user). Requiere una signed URL (acceso a 1 object) o signed cookie (acceso a todo el origin).
• Origin Access Identity: Configurar un identity al CloudFront behavior y sólo permitir esa identity en el origin (por ejemplo S3 bucket).

Storage Gateway

• File Gateway: Acceder a S3/Glacier a través de protocolos NFS y SMB. Sólo los datos más recientes son almacenados (cacheados) on prem. NO es acceso de baja latencia porque desde on prem necesita traer los datos desde S3.
• Tape Gateway: Acceder a S3/Glacier a través de iSCSI VLT. Principalmente usado para archiving. Respaldado por Glacier, así que no se puede consumir en real time.
• Stored-Volume Gateway: volumen montado por iSCSI almacenado on prem y respaldado async a S3 como EBS snapshots. 16 TB por volumen, max 32 volumenes por gateway = max 512 TB. es baja latencia, ya que todos los datos se almacenan on prem, S3 sólo es usado como backup de EBS snapshots del volumen.
• Cached-Volume Gateway: Volumen montado por iSCSI almacenado en S3 y cacheado on prem. 32 TB por volumen, max 32 volumenes por gateway = 1024 TB. Los datos son almacenados en S3, NO on-prem. On-prem sólo tiene un cache de los datos, así que baja latencia sólo para los datos cacheados, no para todos los datos.

6R:

• Retain: Se queda on prem, no hay migración por ahora, rever en el futuro.
• Re-host: Lift and shift sin cambios
• Refactor: Diseñar una app nueva cloud native. Mucho trabajo
• Re-platform: Lift and shift con algunas modificaciones
• Replace: Comprar una solución nativa (no construir una)
• Retire: La solución ya no se necesita, no se reemplaza con algo más.

Proceso de migración:

• Plan: Discovery: Asegurarse de que sabemos realmente lo que está ocurriendo, identificar dependencias, revisar todos los corners y hacer las preguntas: Assessment y profiling, requerimientos de datos y clasificación, priorización, dependencias de lógica de negocios e infraestructura. Design: Plan de migración detallado, estimación de esfuerzo, seguridad y análisis de riesgos. AWS Application Discovery Service, AWS Database Migration Service.
• Build: Transform: Topología de red, migrar, desplegar, validar. Transition: Pilot testing, transición a soporte, release management, cutover y decomisión.
• Run: Operate: Staff training, monitoreo, incident management, provisioning. Optimize: Monitoring-driven optimization, continuous integration y continuous deployment, well-architected framework.

S3:

• S3 Object Lock (requiere versioning):
• - Legal Hold: Encender o apagar. Las versiones de objetos no pueden ser borradas o modificadas mientras está encendido, pero se puede apagar.
• - Retention Compliance: Configurar una duración, las versiones de objetos no pueden ser borradas o modificadas por la duración. No puede ser deshabilitado, ni siquiera por el root.
• - Retention Governance: Configurar una duración, las versiones de objetos no pueden ser borradas o modificadas por la duración. Permisos especiales permiten modificar la policy.

Macie:

• Servicio de seguridad y privacidad de datos. Identifica datos que deberían ser privados.
• Seleccionar S3 buckets, crear discovery job, configurar managed o custom data identifiers, publicar policy findings y sensitive data findings a EventBridge o Security Hub.

Interface y Gateway endpoints

• Interface endpoints: ENI con private IP para tráfico a servicios con PrivateLink

• Gateway endpoints: Target para una route en la RT, sólo usado para S3 o DynamoDB

• NACL: Límite de 20 reglas, puede ser incrementado a 40

DX:

• Public VIF: Usado para servicios públicos de AWS (incluyendo VPN)
• Private VIF: Usado para recursos dentro de una VPC

Schema Conversion Tool (SCT):

• Necesitás configurar el data extraction agent primero en tu server on-premises.

Database Migration System (DMS):

• Puede migrar directamente a Amazon Redshift.

RDS:

• cross-region read replicas
• multi-master: Todos los master nodes necesitan estar en la misma región, y no se pueden habilitar cross-region read replicas.
• Max tamaño: 64 TB

Step Functions:

• No soporta Mechanical Turk de forma directa, en ese caso usar SWF.

CloudSearch:

• Provee funcionalidades de búsqueda, por ejemplo para documentos almacenados en S3.

AWS Config:

• Puede agregar datos de múltiples cuentas de AWS usando un Aggregator
• Sólo puede realizar acciones dentro de la misma cuenta.

Lo más importante a recordar:

• Podés lograrlo!!!

---

Thanks for reading!

If you're interested in building on AWS, check out my newsletter: Simple AWS.

It's free, runs every Monday, and tackles one use case at a time, with all the best practices you need.

If you want to know more about me, visit my website, www.guilleojeda.com