Amazon SAA-C03: Contenedores y orquestación — Guía de estudio

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Forma parte de la AWS SAA-C03 — Guía de estudio completa. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Cómo Elegir Entre ECS y EKS, y Entre EC2 y Fargate

La primera decisión de arquitectura para cualquier carga de trabajo de contenedores en AWS es elegir el orquestador y el modo de computación. Amazon ECS es un orquestador propietario de AWS con una estrecha integración con IAM, ALB/NLB, CloudWatch, Service Discovery y las redes de VPC. No tiene costo por el plano de control y es la ruta más rápida a producción para equipos que no necesitan herramientas específicas de Kubernetes. Las tasks (tareas) son unidades de uno o más contenedores que comparten un ciclo de vida; los services (servicios) son conjuntos de tareas administradas de larga duración, gestionados por un planificador (scheduler). Amazon EKS ejecuta Kubernetes conforme a la versión upstream por una tarifa plana de $0.10/hora por clúster, y es la elección correcta cuando las cargas de trabajo deben permanecer portables, usar la API de Kubernetes o aprovechar el ecosistema de la CNCF (Helm, CRDs, Operators). El plano de control —servidor de API, etcd, controller manager, scheduler— es parcheado, respaldado y puesto en alta disponibilidad por AWS a través de tres Zonas de Disponibilidad (AZs).

Ambos orquestadores aceptan dos modos de computación. AWS Fargate ejecuta cada tarea o pod en microVMs Firecracker aisladas; no hay AMIs que parchear, ni proveedores de capacidad de Auto Scaling Group que ajustar, ni decisiones de bin-packing, ni hosts accesibles por SSH. Se paga por vCPU-segundo y GB-segundo de la tarea. El tipo de lanzamiento EC2 / grupos de nodos administrados significa que tú eres el propietario de las instancias, con la flexibilidad y la carga operativa que ello implica.

Fargate es la opción correcta por defecto siempre que un escenario enfatice “sin servidor” (serverless), “mínima sobrecarga operativa” o “sin infraestructura que administrar”, siempre que la carga de trabajo se ajuste a sus limitaciones: máximo 16 vCPU / 120 GB de memoria por tarea, sin GPU, sin contenedores privilegiados, sin DaemonSets, sin HostPort/HostNetwork, sin personalización a nivel de host de Windows. Elige grupos de nodos administrados o el tipo de lanzamiento EC2 cuando necesites GPUs, DaemonSets que requieran acceso al host, AMIs personalizadas, contenedores de Windows Server con GMSA, eficiencia de bin-packing de sub-segundo o una optimización de costos agresiva basada en Spot.

La trampa clásica es elegir nodos EC2 porque “parecen” más baratos. Para cargas de trabajo con picos o de baja utilización, Fargate suele ser más barato una vez que se tiene en cuenta la capacidad inactiva más el tiempo de ingeniería para parchear AMIs, drenar nodos y configurar el cluster autoscaler, todo lo cual Fargate elimina.

Definiciones de Tarea, Ubicación y Proveedores de Capacidad

Una definición de tarea canónica de ECS Fargate captura lo esencial: dimensionamiento de CPU/memoria, un rol de ejecución para descargar imágenes y escribir logs, modo de red awsvpc y la conexión con CloudWatch Logs:

family: checkout-service
requiresCompatibilities: [FARGATE]
networkMode: awsvpc
cpu: "1024"
memory: "2048"
executionRoleArn: arn:aws:iam::111122223333:role/ecsTaskExecutionRole
containerDefinitions:
  - name: checkout
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/checkout:1.4.2
    portMappings: [{ containerPort: 8080 }]
    logConfiguration:
      logDriver: awslogs
      options:
        awslogs-group: /ecs/checkout
        awslogs-region: us-east-1

En ECS con EC2, las estrategias de ubicación de tareas (task placement strategies) deciden cómo se distribuyen las tareas entre las instancias. Se componen en orden:

Las restricciones de ubicación (placement constraints) como distinctInstance o memberOf, utilizando el lenguaje de consulta del clúster, restringen aún más los candidatos.

Los proveedores de capacidad (capacity providers) desacoplan los servicios de los Auto Scaling Groups. FARGATE y FARGATE_SPOT son proveedores administrados; los proveedores personalizados envuelven un ASG y habilitan el escalado administrado (managed scaling) para que ECS ajuste el recuento deseado del ASG en función del número de tareas aprovisionadas. Una estrategia de proveedor de capacidad divide las tareas por peso y base; por ejemplo, garantizando dos tareas Fargate bajo demanda (on-demand) y dividiendo el resto 1:4 con Fargate Spot para cargas de trabajo tolerantes a interrupciones:

capacityProviderStrategy:
  - capacityProvider: FARGATE
    base: 2
    weight: 1
  - capacityProvider: FARGATE_SPOT
    weight: 4

Autoescalado: Pods, Tareas y Nodos

Fargate elimina la gestión de nodos, pero no escala automáticamente el número de tareas o pods. Esta distinción es el concepto erróneo más común sobre Fargate: serverless se aplica a la capa del host, nunca al recuento deseado de tu servicio. Tú sigues siendo responsable del autoescalado a nivel de servicio.

Para ECS, utiliza Application Auto Scaling. El seguimiento de objetivos (target tracking) es la opción idiomática por defecto porque crea las alarmas de CloudWatch para escalar hacia afuera (scale-out) y hacia adentro (scale-in) automáticamente y respeta los periodos de enfriamiento (cooldowns). Métricas sensatas son ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization y ALBRequestCountPerTarget:

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 --max-capacity 30

aws application-autoscaling put-scaling-policy \
  --policy-name cpu-target-50 \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
    '{"TargetValue":50.0,"PredefinedMetricSpecification":{"PredefinedMetricType":"ECSServiceAverageCPUUtilization"}}'

El escalado por pasos (step scaling) y el escalado programado (scheduled scaling) siguen disponibles para curvas de respuesta no lineales o ventanas de tráfico conocidas.

Para EKS en nodos EC2, la dimensión de los pods es manejada por el Horizontal Pod Autoscaler (HPA), que ajusta el número de réplicas basándose en CPU, memoria o métricas personalizadas. El HPA por sí solo no puede añadir nodos; aumentará las réplicas más allá de la capacidad del clúster sin problemas, momento en el cual los nuevos pods entrarán en estado Pending con eventos de FailedScheduling. Es por eso que el HPA en EC2 siempre debe ir acompañado del Kubernetes Cluster Autoscaler o de Karpenter. Olvidar esta combinación es un error de diseño frecuente: el HPA informa “escalado a 20 réplicas” mientras la mitad de ellas están atascadas en estado pendiente (pending). Una configuración mínima del Cluster Autoscaler descubre los grupos de nodos a través de las etiquetas del ASG:

- --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/prod-eks
- --balance-similar-node-groups
- --skip-nodes-with-system-pods=false

En los perfiles de Fargate este problema desaparece: cada pod se convierte en su propia microVM, por lo que la dimensión de escalado de nodos se elimina por completo. Esta es precisamente la razón por la que Fargate es la elección correcta para cargas de trabajo con ráfagas de tráfico y recuentos de pods impredecibles.

Perfiles de Fargate y sus Límites de Características

Un perfil de Fargate en EKS es un selector —un espacio de nombres más etiquetas de pod opcionales— que instruye a EKS para que programe los pods que coincidan en Fargate en lugar de en un nodo:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata: { name: microservices, region: us-east-1 }
fargateProfiles:
  - name: fp-app
    selectors:
      - namespace: app
        labels: { compute: fargate }

La advertencia crítica es que EKS en Fargate no es compatible con todo el conjunto de características de Kubernetes:

• Los DaemonSets no se ejecutan. Al no haber un nodo sobre el cual actuar como daemon, los recopiladores de logs como los DaemonSets de fluentd deben ser reemplazados por sidecars o por el enrutador de logs integrado Fluent Bit.
• Los contenedores privilegiados, HostPort y HostNetwork no están disponibles.
• El almacenamiento persistente está limitado a EFS a través del driver CSI. EBS no es compatible porque los volúmenes de EBS requieren ser adjuntados a una instancia EC2 específica.
• Las cargas de trabajo de GPU no son compatibles.
• Los servicios NodePort y las mallas de servicios que dependen de contenedores de inicialización privilegiados no funcionan.

Asumir la paridad de características lleva a migraciones fallidas de StatefulSets que necesitan EBS, controladores de ingress que usan hostPort o cargas de trabajo de inferencia con GPU.

Ingress: ALB vs NLB a través del AWS Load Balancer Controller

El AWS Load Balancer Controller es un controlador de Kubernetes que traduce los objetos Ingress y Service en ALBs y NLBs reales. Para microservicios HTTP/HTTPS con enrutamiento basado en ruta o en host, crea un único Ingress de clase alb. Un ALB al frente de muchos servicios (a través de alb.ingress.kubernetes.io/group.name) es drásticamente más barato que un ALB por servicio y es el patrón canónico y rentable:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: shop
spec:
  rules:
  - http:
      paths:
      - path: /customers
        pathType: Prefix
        backend: { service: { name: customers, port: { number: 80 }}}
      - path: /orders
        pathType: Prefix
        backend: { service: { name: orders, port: { number: 80 }}}

Usa un NLB (un Service de tipo LoadBalancer con service.beta.kubernetes.io/aws-load-balancer-type: external y tipo de destino nlb-ip) para TCP, UDP, paso directo de TLS (TLS pass-through), requisitos de IP estática o rendimiento extremo de Capa 4. Poner gRPC sobre HTTP/2 o un proxy de base de datos TCP simple detrás de un ALB está bien solo para gRPC (ALB es compatible con HTTP/2 y gRPC); ALB no puede terminar TCP arbitrario ni ningún UDP. Intentar servir tráfico de juegos UDP a través de un ALB es un desajuste de protocolo que debe detectarse en la fase de diseño.

IAM a Nivel de Pod con IRSA

IAM Roles for Service Accounts (IRSA) es el mecanismo correcto para conceder permisos de la API de AWS a pods individuales. Adjuntar el perfil de instancia del nodo para dar a los pods acceso a S3 es incorrecto porque cada pod en el nodo hereda esos permisos, rompiendo el principio de privilegio mínimo. IRSA funciona federando el proveedor OIDC del clúster con IAM: crea el proveedor OIDC una vez, luego crea un rol de IAM cuya política de confianza confía en ese proveedor para un sujeto namespace:serviceaccount específico.

eksctl utils associate-iam-oidc-provider --cluster prod --approve

eksctl create iamserviceaccount \
  --cluster prod --namespace payments --name orders-sa \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess \
  --approve

La cuenta de servicio se anota con eks.amazonaws.com/role-arn: arn:aws:iam::...:role/orders-role, y los pods que la montan reciben credenciales STS de corta duración a través de un token proyectado. Omitir la asociación del proveedor OIDC o la anotación recurre silenciosamente al rol del nodo — una regresión de seguridad sutil que es fácil pasar por alto en una revisión.

El plugin VPC CNI complementa esto asignando a cada pod una dirección ENI/IP enrutable en la subred de la VPC. Los pods pueden entonces hablar directamente con RDS, ElastiCache o endpoints de VPC usando grupos de seguridad, y CloudTrail ve la IP real del pod para la auditoría.

Almacenamiento Persistente y Efímero

La elección del almacenamiento depende del modo de acceso, la durabilidad y el tipo de lanzamiento.

EBS (a través del driver CSI de EBS en EKS, o EBS adjunto a la tarea en ECS) proporciona volúmenes de bloque ReadWriteOnce para cargas de trabajo con estado (stateful) de un solo pod, como un primario de Postgres. EFS proporciona almacenamiento NFS ReadWriteMany que es regional, multi-AZ y montable por muchos pods simultáneamente — la elección correcta siempre que el requisito mencione “alta disponibilidad, tolerancia a fallos, compartido entre múltiples contenedores” o artefactos de ML compartidos. FSx for Lustre maneja HPC de alto rendimiento; FSx for NetApp ONTAP y FSx for Windows File Server manejan NFS/SMB empresarial.

Las tareas de Fargate reciben 20 GB de almacenamiento efímero por defecto, configurable hasta 200 GB a través de ephemeralStorage.sizeInGiB en la plataforma 1.4.0+. Asumir que Fargate siempre tiene “mucho espacio temporal” es una trampa: un contenedor de un proveedor que escribe 50 GB de archivos intermedios puede caber en el almacenamiento efímero expandido, pero si el requisito es de 50 GB de almacenamiento compartido o duradero entre reinicios de tareas o entre tareas, el almacenamiento efímero es incorrecto porque se destruye cuando la tarea se detiene y nunca se comparte. Fargate no es compatible con EBS. Si una carga de trabajo en Fargate necesita almacenamiento persistente o compartido, EFS es esencialmente la única opción compatible.

Para ECS, monta EFS directamente en la definición de la tarea; los puntos de acceso imponen UID/GID de POSIX y un directorio raíz por tarea, proporcionando un multi-tenancy seguro en un único sistema de archivos, y la autorización de IAM limita el alcance a elasticfilesystem:ClientMount:

"volumes": [{
  "name": "scratch",
  "efsVolumeConfiguration": {
    "fileSystemId": "fs-0abc123",
    "transitEncryption": "ENABLED",
    "authorizationConfig": {
      "accessPointId": "fsap-0def456",
      "iam": "ENABLED"
    }
  }
}],
"containerDefinitions": [{
  "name": "app",
  "mountPoints": [{
    "sourceVolume": "scratch",
    "containerPath": "/data"
  }]
}]

Para EKS, conecta EFS a través de una StorageClass:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: efs-sc }
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-0123456789abcdef0
  directoryPerms: "700"

Una trampa recurrente: seleccionar Fargate para una carga de trabajo con estado y olvidar instalar el driver CSI de EFS y la StorageClass — los pods se inician pero los PersistentVolumeClaims se quedan en Pending para siempre. A la inversa, elegir nodos EC2 únicamente para adjuntar EBS cuando el requisito es almacenamiento compartido con múltiples escritores también es incorrecto; EBS io2 adjuntado a un nodo no se puede compartir entre Zonas de Disponibilidad.

Escaneo de Imágenes y Ciclo de Vida de ECR

Amazon ECR ofrece dos modos de escaneo. El escaneo básico utiliza la base de datos de código abierto Clair y se ejecuta al hacer push (o bajo demanda) sin coste alguno. El escaneo mejorado se integra con Amazon Inspector, monitoriza continuamente las CVE tanto del SO como de los paquetes de lenguaje, y reporta los hallazgos en Security Hub. Para “escanear en busca de CVE, escanear nuevas imágenes en su creación, con los mínimos cambios en las cargas de trabajo”, la acción correcta es habilitar el escaneo al hacer push (scan on push) a nivel de repositorio — no se requiere ningún cambio en el pipeline porque el evento de push desencadena el escaneo:

aws ecr put-image-scanning-configuration \
  --repository-name payments-api \
  --image-scanning-configuration scanOnPush=true

El CI/CD luego llama a describe-image-scan-findings y hace fallar las compilaciones si hay un recuento de CRITICAL o HIGH. Omitir el escaneo significa que CVEs sin parches de Log4j, OpenSSL o glibc se ejecutan en producción; el coste de mitigación de no escanear eclipsa el coste casi nulo de habilitarlo.

Las políticas de ciclo de vida limitan el coste de almacenamiento y aplican una higiene de etiquetas:

{
  "rules": [{
    "rulePriority": 1,
    "selection": {
      "tagStatus": "untagged",
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 14
    },
    "action": { "type": "expire" }
  }]
}

Migración de cargas de trabajo de Kubernetes + MongoDB

Al hacer un lift-and-shift de un stack autohospedado de Kubernetes + MongoDB a AWS bajo las restricciones “no cambiar el código de la aplicación” y “mínima carga operativa”, dos decisiones se alinean. Primero, la capa de computación se traslada a EKS porque la compatibilidad con la API de Kubernetes significa que los manifiestos y los Helm charts se pueden portar sin cambios; utilice perfiles de Fargate para los servicios sin estado para eliminar la gestión de nodos.

En segundo lugar, MongoDB en sí no debería ser realojado en EC2 autogestionados o StatefulSets; eso reintroduce las copias de seguridad, el sharding, la conmutación por error y la aplicación de parches como cargas operativas. Utilice Amazon DocumentDB (con compatibilidad con MongoDB), que habla el protocolo de conexión de MongoDB 3.6/4.0/5.0, por lo que los drivers y las cadenas de conexión existentes funcionan con cambios mínimos.

La advertencia sobre la compatibilidad es importante. DocumentDB emula la superficie de la API de MongoDB, pero no es MongoDB. Ciertos operadores de agregación, tipos de índices específicos, la semántica de los change streams y las características introducidas en versiones más recientes de MongoDB pueden fallar. El paso correcto previo a la migración es ejecutar la herramienta de compatibilidad de DocumentDB (compat.py) contra la aplicación para confirmar que todas las operaciones son compatibles. Elegir DynamoDB en su lugar forzaría una reescritura del modelo de datos; elegir RDS rompería el modelo de documentos por completo. Ambas opciones violan la restricción de “no cambiar el código”.

Opciones híbridas: ECS Anywhere y EKS Anywhere

ECS Anywhere registra servidores on-premise (o VMs de otras nubes) como instancias externas en un clúster de ECS. El plano de control permanece en AWS; el SSM Agent y el ECS Agent en la instancia externa se conectan de salida. Un único pipeline de despliegue, una única definición de tarea y un único conjunto de roles de IAM cubren tanto las cargas de trabajo en la nube como las on-premise.

EKS Anywhere instala una distribución de Kubernetes compatible en su hardware (típicamente vSphere o bare metal), opcionalmente con visibilidad del EKS Connector en la consola de AWS. Elija ECS Anywhere para un enfoque híbrido ligero y basado en definiciones de tarea; elija EKS Anywhere cuando las restricciones regulatorias o de latencia requieran Kubernetes localmente con las mismas herramientas que EKS en la nube. Ambos mantienen la consistencia en la orquestación: el valor fundamental es que los equipos evitan mantener dos sistemas de CI/CD o dos modelos mentales.

Visibilidad multiclúster con el EKS Connector

Las organizaciones suelen operar una mezcla de clústeres de EKS, Kubernetes autogestionado en EC2 y clústeres on-premise. El Amazon EKS Connector registra cualquier clúster de Kubernetes compatible en la consola de EKS, proporcionando un panel único para nodos, cargas de trabajo y metadatos del clúster. Es esencialmente un agente ligero más un canal de SSM: la respuesta de baja sobrecarga para tener una “vista central de todos los clústeres”. Construir una visibilidad equivalente con Rancher autohospedado, Anthos o una federación personalizada de Prometheus/Grafana es factible, pero mucho más costoso operacionalmente y no se integra con IAM ni con el acceso basado en la consola.

EKS Connector es estrictamente una capa de visibilidad; no gestiona ni actualiza el clúster remoto, lo que es exactamente lo que implica una “vista central con la mínima sobrecarga”.

Combinando los patrones

Para una carga de trabajo de comercio electrónico con un front-end con balanceo de carga, una capa intermedia contenedorizada y un almacén relacional, donde el criterio es “la menor intervención manual posible”, el stack canónico es ALB → ECS en Fargate → Aurora Serverless v2. Cada capa elimina la propiedad a nivel de instancia: el ALB es totalmente gestionado, Fargate elimina los hosts y Aurora Serverless v2 escala en ACUs sin necesidad de dimensionar instancias.

Para una plataforma de microservicios donde el equipo “no puede gestionar infraestructura adicional”, la combinación correcta es ECS o EKS con Fargate, más un servicio de datos totalmente gestionado. Seleccionar el tipo de lanzamiento EC2 o grupos de nodos autogestionados contradice la restricción, aunque la carga de trabajo técnicamente funcionaría.

Para un lift-and-shift de Kubernetes + MongoDB, la respuesta converge en EKS + DocumentDB: la API de Kubernetes preserva los métodos de despliegue, DocumentDB preserva la compatibilidad de los drivers y los perfiles de Fargate preservan una operativa mínima, siempre que el uso de características de Kubernetes y la superficie de comandos de MongoDB de la carga de trabajo se encuentren dentro de los límites de compatibilidad descritos anteriormente.

← Cómputo · Todos los dominios · Arquitecturas serverless y basadas en eventos →

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

Explorar Amazon →