Amazon DOP-C02: Contenedores y Operaciones sin Servidor — Guía de estudio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Forma parte de la AWS DevOps Engineer Professional DOP-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Descripción general

Los contenedores y la tecnología sin servidor (serverless) cambian la forma en que opera, escala y lanza aplicaciones en AWS. Esta sección conecta las primitivas operativas de Amazon ECS, AWS Fargate, Amazon EKS, Amazon ECR, AWS Lambda y Amazon API Gateway para que pueda diseñar implementaciones seguras, aplicar la gobernanza de imágenes, ajustar la concurrencia y tomar decisiones consistentes entre la capacidad basada en EC2 y Fargate. Se centra en los modelos de programación de tareas y pods, las comprobaciones de estado y los controles de implementación, el desvío de tráfico, la distribución de imágenes entre cuentas y las características de rendimiento como el almacenamiento en caché de API y la concurrencia aprovisionada de Lambda.

Amazon ECS y AWS Fargate

Las definiciones de tareas de ECS declaran uno o más contenedores y toda la configuración de tiempo de ejecución que necesita el programador (scheduler). Los elementos clave incluyen reservas y límites de CPU/memoria, portMappings, variables de entorno y secretos (de AWS Secrets Manager o Systems Manager Parameter Store), parámetros de Linux y ulimits, logConfiguration (awslogs, firelens, etc.), tamaño de ephemeralStorage (para Fargate, de 20 a 200 GB) y volúmenes (incluido EFS). Utilice el rol de ejecución de tareas (task execution role) para la extracción de imágenes y los controladores de logs; utilice el rol de tarea (task role) para el acceso de la aplicación a la API de AWS. El healthCheck del contenedor define el comando, el intervalo, el tiempo de espera (timeout), los reintentos y el startPeriod. En combinación con dependsOn (condition=HEALTHY), las comprobaciones de estado fuerzan el orden de inicio de los sidecars.

Los servicios de ECS mantienen el recuento de tareas deseado y, opcionalmente, registran las tareas en un ALB/NLB. La deploymentConfiguration del servicio controla las actualizaciones continuas (rolling updates) con minimumHealthyPercent y maximumPercent. El disyuntor de implementaciones (deployment circuit breaker) (enabled/rollback) puede revertir automáticamente los despliegues fallidos cuando las tareas no superan las comprobaciones de estado. El autoescalado de servicios se integra con Application Auto Scaling para el seguimiento de objetivos basado en CPU/memoria o en RequestCountPerTarget del ALB. El descubrimiento de servicios (AWS Cloud Map) y ECS Service Connect simplifican el tráfico de servicio a servicio.

Tipos de clúster y capacidad:

El tipo de lanzamiento EC2 ejecuta tareas en instancias EC2 autoadministradas. Utilice grupos de Auto Scaling, restricciones/estrategias de ubicación (placement constraints/strategies) y cualquier networkMode (bridge/host/awsvpc). Se admiten tareas de tipo daemon y AMIs especializadas (p. ej., Bottlerocket).
El tipo de lanzamiento Fargate es computación sin servidor para contenedores. Utiliza únicamente redes de tipo awsvpc, lo que proporciona a cada tarea su propia ENI y grupo de seguridad. No hay tareas de tipo daemon; se depende de sidecars o integraciones nativas del servicio (p. ej., FireLens). Las versiones de la plataforma (platform versions) condicionan las características (consulte las notas de la versión para ver la compatibilidad con EFS, ephemeral storage y exec). Fargate Spot reduce el costo para tareas interrumpibles. Elija CPU/memoria en pares compatibles (p. ej., de 0.25 vCPU/0.5–2 GB a 16 vCPU/120 GB). Cuando se ejecuta en subredes privadas, agregue puntos de conexión de interfaz de VPC para ECR (api y dkr), CloudWatch Logs y un punto de conexión de puerta de enlace de S3 para extraer imágenes y enviar logs sin un NAT.

Fargate y EFS: defina un volumen EFS en la definición de la tarea y móntelo con TLS; prefiera los puntos de acceso de EFS para aplicar el mínimo privilegio y la identidad. Esto satisface necesidades con estado (stateful) como configuraciones compartidas, pesos de modelos o archivos intermedios sin tener que integrarlos en las imágenes.

Comprobaciones de estado de contenedores, actualizaciones continuas y azul/verde:

Las comprobaciones de estado se realizan en múltiples capas: contenedor (basadas en CMD), tarea de ECS (estados agregados de los contenedores) y estado del destino del balanceador de carga (HTTP/TCP). Alinee los intervalos y umbrales para que ECS pueda reemplazar elegantemente las tareas en mal estado antes de que el ALB anule el registro de los destinos.
Las actualizaciones continuas (rolling updates) son el método predeterminado de ECS. Ajuste minHealthy/maxPercent para controlar el aumento de tareas (surge) y la seguridad de la capacidad.
La implementación azul/verde utiliza CodeDeploy con ECS (tipo de deploymentController:

undefined

). CodeDeploy gestiona dos grupos de destino detrás del ALB, desvía el tráfico de prueba al conjunto verde (AfterAllowTestTraffic), ejecuta comprobaciones automatizadas (por ejemplo, a través de Lambda) y luego desvía el tráfico de producción. Vincule las alarmas de CloudWatch para revertir la implementación (rollback) en caso de picos de errores 5XX, latencia o métricas personalizadas. Este patrón aísla los fallos y proporciona reversiones rápidas con un tiempo de inactividad casi nulo.

Gobernanza de imágenes con ECR:

Escaneo: habilite el escaneo al subir (scan-on-push) y adopte el escaneo mejorado de Amazon Inspector para una cobertura continua de CVE y SBOMs. Condicione las implementaciones según la gravedad de la vulnerabilidad mediante comprobaciones en el pipeline.
Las políticas de ciclo de vida (lifecycle policies) hacen expirar las etiquetas de imagen antiguas por recuento/antigüedad y prefijo de etiqueta. Combine esto con la inmutabilidad de etiquetas para bloquear sobrescrituras accidentales.
Cifrado: utilice el cifrado gestionado por ECR o una clave de KMS gestionada por el cliente con la política de clave adecuada.
Entre cuentas (cross-account): adjunte políticas de recursos al repositorio para otorgar permisos de extracción/subida (pull/push) desde otras cuentas o roles de CI. Utilice las reglas de replicación de ECR para copiar imágenes entre regiones/cuentas para mejorar la localidad y reducir el radio de impacto (blast-radius). PrivateLink (puntos de conexión de VPC) permite la extracción de imágenes sin necesidad de internet.

Modelos de cómputo de Amazon EKS

EKS separa el plano de control administrado de tus opciones para el plano de datos:

Los grupos de nodos administrados (MNGs) aprovisionan y gestionan el ciclo de vida de los nodos de trabajo EC2. Se integran con plantillas de lanzamiento (launch templates) para la elección de AMI (Amazon Linux 2, Bottlerocket), tipos de instancia y parámetros de arranque (bootstrap). Los MNGs gestionan actualizaciones continuas (rolling updates) con capacidad de sobrecarga (surge capacity) y acordonamiento/drenaje (cordon/drain) automatizado para una interrupción mínima. Usa taints/tolerations de nodo para dirigir cargas de trabajo específicas. Combínalos con el Cluster Autoscaler (o Karpenter) para dimensionar correctamente la capacidad de los nodos en función de los pods pendientes.

Los nodos autogestionados dan control total sobre el arranque y el sistema operativo, pero añaden sobrecarga operativa; normalmente se reservan para kernels especiales o hardware de nicho.

EKS on Fargate ejecuta pods sin necesidad de gestionar nodos. Los perfiles de Fargate (Fargate profiles) mapean namespaces/etiquetas a Fargate. Cada pod obtiene su propia ENI (awsvpc), lo que simplifica el aislamiento de red. Las limitaciones incluyen la no compatibilidad con DaemonSets, redes/volúmenes del host (host networking/volumes) y restricciones en cargas de trabajo privilegiadas. Los agentes de observabilidad (p. ej., Fluent Bit) deben ejecutarse como sidecars o utilizar la recolección de logs administrada. Este modelo es ideal para cargas de trabajo con picos de tráfico, de bajo consumo de recursos (small-footprint) o multi-tenant que se benefician del aislamiento por pod y de un modelo económico de pago por pod.

Add-ons operativos:

VPC CNI, CoreDNS y kube-proxy son add-ons administrados; fija las versiones compatibles con la versión del clúster y actualízalas de forma deliberada.
IAM Roles for Service Accounts (IRSA) impone el acceso de mínimo privilegio a AWS por pod y reemplaza el uso compartido de credenciales del rol del nodo.
El balanceo de carga a través del AWS Load Balancer Controller soporta ALB/NLB para Services e Ingress; asegúrate de tener las reglas de IAM y de los grupos de seguridad adecuadas, especialmente al mezclar MNG y Fargate.
Almacenamiento persistente a través de drivers CSI (EBS para almacenamiento en bloque por pod, EFS para POSIX compartido). Para Fargate, EFS es la opción típica para el estado compartido.

Operaciones y concurrencia de AWS Lambda

Empaquetado y configuración:

Los paquetes de despliegue pueden ser archivos ZIP (con un runtime de lenguaje) o imágenes de contenedor de hasta 10 GB. El formato ZIP es más ligero para código pequeño; las imágenes unifican las herramientas con compilaciones basadas en contenedores.
Las capas (Layers) encapsulan bibliotecas compartidas entre funciones; mantenlas mínimas y versionadas. Una función puede incluir hasta cinco capas.
Las versiones son instantáneas inmutables; los alias son punteros estables a versiones y pueden tener pesos para el desvío de tráfico.
El almacenamiento efímero (Ephemeral storage) tiene un valor predeterminado de 512 MB y puede aumentarse a 10,240 MB para compilaciones, archivos temporales o cachés de inferencia de ML. Elige x86_64 o arm64 para optimizar la relación costo/rendimiento. Usa variables de entorno para la configuración e intégralas con Secrets Manager o Parameter Store.

Desvío de tráfico y seguridad:

Usa CodeDeploy para despliegues canary/lineales con reversión (rollback) automatizada basada en alarmas de CloudWatch (p. ej., errores 5XX, latencia o métricas de aplicación personalizadas). Alternativamente, establece los pesos del alias directamente para un enrutamiento A/B simple.
Usa el registro estructurado (structured logging) en CloudWatch Logs y crea filtros de métricas para derivar métricas dimensionadas por operación/versión/código sin cambiar la instrumentación de métricas. Habilita X-Ray para el rastreo de latencia de extremo a extremo.

Controles de concurrencia:

La concurrencia no reservada (Unreserved concurrency) utiliza el pool regional de la cuenta. Los picos de tráfico pueden dejar sin recursos a otras funciones.
La concurrencia reservada (Reserved concurrency) limita la concurrencia máxima de una función y le garantiza esa capacidad tomándola del pool regional; esto proporciona aislamiento de otros servicios ruidosos (noisy neighbors).
La concurrencia aprovisionada (Provisioned concurrency) mantiene los entornos de ejecución inicializados para una versión/alias, eliminando virtualmente los arranques en frío (cold starts) y estabilizando la latencia. Escala la concurrencia aprovisionada con Application Auto Scaling según la hora del día o métricas.
El estrangulamiento (throttling) ocurre cuando una función alcanza su límite de concurrencia; las llamadas síncronas reciben errores 429, mientras que las invocaciones asíncronas se reintentan con un retroceso exponencial (exponential backoff) y pueden terminar en una cola de mensajes fallidos (dead-letter queue) después de los intentos configurados. Para fuentes basadas en sondeo (poll-based) como SQS, Lambda aumenta la concurrencia con la profundidad de la cola; asegúrate de que la concurrencia reservada/aprovisionada y la capacidad de los servicios posteriores (downstream) coincidan con el máximo de mensajes en tránsito para evitar el crecimiento del backlog.

Diseño de API Gateway y Acceso entre Cuentas a ECR

API REST de API Gateway frente a API HTTP:

Las API REST proporcionan el conjunto de características más completo: mapeo de solicitud/respuesta (VTL), planes de uso y claves de API, autorizadores, WAF y caché a nivel de etapa. Elija las API REST cuando necesite transformaciones avanzadas, claves de API con cuotas o integraciones maduras del ecosistema.
Las API HTTP tienen menor latencia y costo, con un enrutamiento más simple hacia backends de Lambda y HTTP (incluidas integraciones privadas con ALB/NLB). Soportan autorizadores JWT e IAM, pero carecen de muchas características de las API REST, incluido el caché a nivel de etapa y las transformaciones VTL. Elija las API HTTP para un proxy directo con una sobrecarga mínima.

Etapas y limitación de velocidad (throttling):

Las etapas vinculan un despliegue específico a una ruta de URL. Configure variables de etapa, registros y limitación de velocidad en la etapa. Aplique planes de uso (REST) para hacer cumplir límites de velocidad y cuotas por clave de API. La configuración de la limitación de velocidad incluye tasa y ráfaga; se combinan con los límites a nivel de cuenta, así que asegúrese de que el tráfico agregado no exceda las cuotas regionales. Habilite los registros de acceso con JSON estructurado e integre WAF para inspeccionar y bloquear solicitudes maliciosas.

Almacenamiento en caché (solo API REST):

El caché a nivel de etapa reduce la carga del backend y la latencia; establezca TTL por método, habilite el cifrado y considere los parámetros/encabezados de la clave de caché para la correctitud. Invalide las cachés después de los despliegues que cambian las estructuras o el comportamiento de la respuesta.

Conectividad privada:

Elija el tipo de punto de conexión (endpoint): optimizado en el borde (REST, global a través de CloudFront), regional o privado (puntos de conexión de VPC). Las integraciones privadas con VPC Link se conectan a backends de NLB/ALB en VPC sin exposición pública.

Acceso entre cuentas a ECR:

Use políticas de recursos del repositorio para otorgar permisos de extracción/subida (pull/push) a entidades principales (principals) en otras cuentas (roles de CI/CD o de tiempo de ejecución). Si usa una clave de KMS administrada por el cliente, extienda la política de la clave correspondientemente. Para la distribución entre múltiples cuentas, defina reglas de replicación de ECR para apuntar a las cuentas/Regiones de destino y valide la integridad de la imagen con la inmutabilidad de etiquetas y la fijación de digest (digest pinning) en los despliegues.

Escenario de un Problema Práctico

Spotify está modernizando una pila de microservicios de listas de reproducción para reducir la variación de latencia durante los lanzamientos en horas pico y para reforzar su cadena de suministro de imágenes a través de múltiples cuentas de AWS.

Estandarizar la construcción y gobernanza de imágenes

Implemente repositorios de ECR con escaneo al subir (scan-on-push) y escaneo mejorado de Amazon Inspector. Añada inmutabilidad de etiquetas y políticas de ciclo de vida para retener las últimas N versiones por rama y podar las antiguas. Configure la replicación entre Regiones/cuentas desde la cuenta de construcción hacia las cuentas de producción y de preparación (staging). Por qué: Inspector asegura una cobertura continua de CVE, la inmutabilidad previene el secuestro de etiquetas y la replicación localiza las extracciones (pulls) para reducir la latencia del despliegue y el radio de impacto.

Servir APIs sin estado en ECS con Fargate

Defina definiciones de tareas de ECS con awslogs y FireLens para registros y métricas estructurados. Habilite la verificación de estado (healthCheck) del contenedor y alinee las verificaciones de estado del grupo de destino del ALB. Monte un volumen de EFS para configuración compartida de solo lectura a través de un punto de acceso. Ejecute servicios en Fargate con una estrategia de proveedor de capacidad que mezcle Fargate y Fargate Spot para eficiencia de costos. Por qué: Fargate elimina la gestión de nodos y aísla las tareas por ENI; EFS evita integrar configuraciones en las imágenes y soporta reversiones (rollbacks) atómicas de la configuración.

Despliegues seguros con azul/verde y pruebas automatizadas

Cambie los servicios de ECS a un controlador de despliegue de CodeDeploy. Configure dos grupos de destino en el ALB. Use un cambio canario (canary shift) con AfterAllowTestTraffic para invocar un ejecutor de pruebas Lambda que ejercita los puntos de conexión (endpoints) críticos en 5 minutos. Asocie alarmas de CloudWatch sobre errores 5XX y latencia p90 para desencadenar una reversión (rollback). Por qué: El despliegue azul/verde de CodeDeploy aísla el riesgo, el gancho de prueba (test hook) valida el entorno verde antes de la transición completa y las alarmas proporcionan una reversión (rollback) automatizada y objetiva.

Operaciones sensibles a la latencia en Lambda con arranques en frío estabilizados

Para una API auxiliar de tokenización, empaquete la función como un ZIP con dependencias mínimas. Cree una versión/alias y habilite la concurrencia aprovisionada dimensionada para el pico. Controle la concurrencia aprovisionada a través de Application Auto Scaling con una programación diaria que siga las ventanas de lanzamiento. Use un despliegue canario de CodeDeploy (10%/15 minutos) para el desvío de tráfico basado en alias, vinculado a alarmas de CloudWatch. Por qué: La concurrencia aprovisionada elimina los arranques en frío durante los picos; los despliegues canarios sobre alias permiten una exposición gradual con una reversión (rollback) rápida.

Exponer APIs externas a través de API Gateway y proteger los backends privados

Ponga API Gateway al frente de Lambda y del ALB de ECS. Use API HTTP para el proxy de Lambda para minimizar costo/latencia. Use API REST para la ruta del ALB de ECS que necesita mapeo de solicitud/respuesta y caché de etapa para los puntos de conexión (endpoints) de lectura intensiva. Aplique ACLs web de WAF y limitación de velocidad (throttling) de etapa; habilite los registros de acceso estructurados. Por qué: Hacer coincidir los tipos de API con las necesidades optimiza el costo y las capacidades; el almacenamiento en caché reduce la carga; WAF y la limitación de velocidad añaden protección durante los picos de eventos.

Extracciones (pulls) entre cuentas en tiempo de ejecución sin internet

En las VPC de tiempo de ejecución, añada puntos de conexión (endpoints) de interfaz para ECR (api, dkr) y CloudWatch Logs, y un punto de conexión (endpoint) de puerta de enlace de S3. Asocie políticas de recursos del repositorio de ECR para permitir que los roles de ejecución de tareas de la cuenta de producción realicen extracciones (pulls). Use una clave de KMS administrada por el cliente con una política de clave entre cuentas para el cifrado de imágenes en reposo. Por qué: Las extracciones (pulls) de imágenes privadas evitan los costos de NAT y los riesgos de egreso; las políticas explícitas de recursos/claves aplican el principio de mínimo privilegio para el acceso entre cuentas.

Este diseño reduce el trabajo operativo repetitivo (sin nodos que gestionar), proporciona una latencia determinista a través de la concurrencia aprovisionada y despliegues alineados con la salud del ALB, y garantiza la procedencia de la imagen de extremo a extremo con el escaneo, la replicación y la inmutabilidad de ECR.

← Seguridad · Todos los dominios · Alta Disponibilidad →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →