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

By Laurynas Brazys · 15 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.

Elegir entre ECS y EKS, y entre EC2 y Fargate

La primera decisión arquitectónica para cualquier carga de trabajo de contenedores en AWS es elegir el orquestador y el modo de cómputo. Amazon ECS es un orquestador propietario de AWS con una estrecha integración con IAM, ALB/NLB, CloudWatch, Service Discovery y redes VPC. No tiene tarifa de plano de control y es el camino más rápido a producción para equipos que no necesitan herramientas específicas de Kubernetes. Las tareas son unidades de uno o más contenedores que comparten un ciclo de vida; los servicios son conjuntos de tareas de larga duración gestionados por un programador. Amazon EKS ejecuta Kubernetes conforme a la versión upstream a una tarifa plana de $0.10/hora por clúster, y es la elección correcta cuando las cargas de trabajo deben permanecer portátiles, usar la API de Kubernetes o aprovechar el ecosistema de la CNCF (Helm, CRDs, Operators). El plano de control —servidor API, etcd, controlador de administrador, programador— es parcheado, respaldado y hecho de alta disponibilidad en tres AZs por AWS.

Ambos orquestadores aceptan dos modos de cómputo. 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 gestionados significa que usted es dueño de las instancias, con la flexibilidad y la carga operativa que eso implica.

Fargate es la opción predeterminada correcta siempre que un escenario enfatice “sin servidor”, “menor sobrecarga operativa” o “sin infraestructura que gestionar”, 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. Elija grupos de nodos gestionados o tipo de lanzamiento EC2 cuando necesite GPU, DaemonSets que requieran acceso al host, AMIs personalizadas, contenedores de Windows Server con GMSA, eficiencia de bin-packing en subsegundos 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 el parcheo de AMI, el drenaje de nodos y la configuración del escalador automático del clúster, todo lo cual Fargate elimina.

Definiciones de tareas, ubicación y proveedores de capacidad

Una definición de tarea canónica de ECS Fargate captura lo esencial: tamaño de CPU/memoria, un rol de ejecución para extraer imágenes y escribir registros, modo de red awsvpc y cableado de 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 deciden cómo se distribuyen las tareas entre las instancias. Se componen en orden:

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

Los proveedores de capacidad desacoplan los servicios de los Auto Scaling Groups sin procesar. FARGATE y FARGATE_SPOT son proveedores gestionados; los proveedores personalizados envuelven un ASG y habilitan el escalado gestionado 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 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 abusado de Fargate: sin servidor se aplica a la capa de host, nunca al recuento deseado de su servicio. Usted sigue siendo el propietario del autoescalado a nivel de servicio.

Para ECS, utilice Application Auto Scaling. El seguimiento de objetivos es el valor predeterminado idiomático porque crea automáticamente las alarmas de CloudWatch de escalado horizontal y vertical y respeta los tiempos de espera. Las métricas sensibles 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 y el escalado programado siguen estando disponibles para curvas de respuesta no lineales o ventanas de tráfico conocidas.

Para EKS en nodos EC2, la dimensión del pod es manejada por el Horizontal Pod Autoscaler (HPA), que ajusta el número de réplicas en función de la CPU, la memoria o métricas personalizadas. HPA por sí solo no puede añadir nodos; aumentará felizmente las réplicas más allá de la capacidad del clúster, momento en el que los nuevos pods entrarán en Pending con eventos FailedScheduling. Por eso, HPA en EC2 siempre debe combinarse con el Kubernetes Cluster Autoscaler o Karpenter. Olvidar esta combinación es un error de diseño frecuente: HPA informa “escalado a 20 réplicas” mientras la mitad de ellas están atascadas en pendiente. Una configuración mínima de Cluster Autoscaler descubre grupos de nodos a través de etiquetas 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 opción correcta para cargas de trabajo con picos de actividad y recuentos de pods impredecibles.

Perfiles de Fargate y sus límites de características

Un perfil de Fargate en EKS es un selector —espacio de nombres más etiquetas de pod opcionales— que le indica a EKS que programe los pods coincidentes 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 la superficie completa de características de Kubernetes:

• Los DaemonSets no se ejecutan. Sin un nodo en el que ejecutar el demonio, los recolectores de logs como los DaemonSets de fluentd deben ser reemplazados por sidecars o el enrutador de logs Fluent Bit incorporado.
• Los contenedores privilegiados, HostPort y HostNetwork no están disponibles.
• El almacenamiento persistente está limitado a EFS a través del controlador CSI. EBS no es compatible porque los volúmenes de EBS requieren la conexión 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 init privilegiados no funcionan.

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

Ingress: ALB vs NLB a través del controlador de balanceador de carga de AWS

El controlador de balanceador de carga de AWS es un controlador de Kubernetes que traduce objetos Ingress y Service en ALBs y NLBs reales. Para microservicios HTTP/HTTPS con enrutamiento basado en ruta o host, cree un único Ingress de clase alb. Un ALB que sirve a muchos servicios (a través de alb.ingress.kubernetes.io/group.name) es dramáticamente más barato que un ALB por servicio y es el patrón canónico 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 }}}

Utilice un NLB (Servicio de tipo LoadBalancer con service.beta.kubernetes.io/aws-load-balancer-type: external y tipo de destino nlb-ip) para TCP, UDP, paso a través de TLS, requisitos de IP estática o rendimiento extremo de Capa 4. Poner gRPC-over-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 UDP. Intentar servir tráfico de juegos UDP a través de un ALB es una falta de coincidencia 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 otorgar permisos de la API de AWS a pods individuales. Adjuntar el perfil de instancia del nodo para dar acceso a S3 a los pods es incorrecto porque cada pod en el nodo hereda esos permisos, rompiendo el principio de privilegio mínimo. IRSA funciona federando el proveedor de OIDC del clúster con IAM: cree el proveedor de OIDC una vez, luego cree un rol de IAM cuya política de confianza confíe 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 de OIDC u omitir la anotación recurre silenciosamente al rol del nodo, una sutil regresión de seguridad que es fácil pasar por alto en la revisión.

El plugin VPC CNI complementa esto asignando a cada pod una ENI/dirección IP en la subred de la VPC. Los pods pueden entonces comunicarse directamente con RDS, ElastiCache o puntos de conexión de VPC utilizando grupos de seguridad, y CloudTrail ve la IP real del pod para 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 controlador EBS CSI en EKS, o EBS adjunto a la tarea en ECS) proporciona volúmenes de bloque ReadWriteOnce para cargas de trabajo con estado de un solo pod, como una base de datos Postgres primaria. 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 “altamente disponible, tolerante 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 de trabajo” 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 50 GB de almacenamiento compartido o duradero entre reinicios de tareas o entre tareas, el almacenamiento efímero es incorrecto porque se destruye al detener la tarea y nunca se comparte. Fargate no es compatible con EBS. Si una carga de trabajo de Fargate necesita almacenamiento persistente o compartido, EFS es esencialmente la única opción compatible.

Para ECS, monte EFS directamente en la definición de la tarea; los puntos de acceso aplican UID/GID de POSIX y directorio raíz por tarea, proporcionando una multi-tenencia segura en un solo sistema de archivos, y la autorización de IAM abarca 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, conecte 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 controlador CSI de EFS y la StorageClass; los pods se inician pero los PersistentVolumeClaims permanecen Pending para siempre. Por el contrario, elegir nodos EC2 únicamente para adjuntar EBS cuando el requisito es almacenamiento compartido de múltiples escritores también es incorrecto; EBS io2 adjunto a un nodo no se puede compartir entre AZs.

Escaneo y ciclo de vida de imágenes 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 subir (o bajo demanda) sin costo. El escaneo mejorado integra Amazon Inspector, monitorea continuamente CVEs tanto del sistema operativo como de paquetes de lenguaje, e informa los hallazgos a Security Hub. Para “escanear CVEs, escanear nuevas imágenes al crearlas, con la menor cantidad de cambios en las cargas de trabajo”, la acción correcta es habilitar el escaneo al subir a nivel de repositorio, sin necesidad de cambios en el pipeline porque el evento de subida activa el escaneo:

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

CI/CD luego llama a describe-image-scan-findings y falla las compilaciones en recuentos CRITICAL o HIGH. Omitir el escaneo significa que CVEs de Log4j, OpenSSL o glibc sin parchear se ejecutan en producción; el costo de mitigación de no escanear empequeñece el costo casi nulo de habilitarlo.

Las políticas de ciclo de vida limitan el costo de almacenamiento y aplican la higiene de las 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 trasladar una pila de Kubernetes + MongoDB autohospedada a AWS bajo las restricciones “no cambiar el código de la aplicación” y “mínima sobrecarga operativa”, dos decisiones se alinean. Primero, la capa de cómputo se mueve a EKS porque la compatibilidad de la API de Kubernetes significa que los manifiestos y los gráficos de Helm se portan sin cambios; use perfiles de Fargate para los servicios sin estado para eliminar la propiedad de los nodos.

En segundo lugar, MongoDB en sí mismo no debe reubicarse en EC2 autoadministrado o StatefulSets; eso reintroduce las copias de seguridad, el sharding, la conmutación por error y la aplicación de parches como cargas operativas. Use Amazon DocumentDB (con compatibilidad con MongoDB), que habla el protocolo de conexión de MongoDB 3.6/4.0/5.0 para que los controladores y las cadenas de conexión existentes funcionen con cambios mínimos.

La advertencia de compatibilidad es importante. DocumentDB emula la superficie de la API de MongoDB, pero no es MongoDB. Ciertos operadores de agregación, tipos de índice específicos, semántica de flujos de cambios y 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 cada operación es compatible. Elegir DynamoDB en su lugar forzaría una reescritura del modelo de datos; elegir RDS rompería el modelo de documentos por completo. Ambos violan la restricción de “no cambiar el código”.

Opciones híbridas: ECS Anywhere y EKS Anywhere

ECS Anywhere registra servidores locales (o máquinas virtuales de otras nubes) como instancias externas en un clúster de ECS. El plano de control permanece en AWS; el Agente SSM y el Agente ECS en la instancia externa se conectan salientes. Una canalización de implementación, una definición de tarea y un conjunto de roles de IAM cubren tanto las cargas de trabajo en la nube como las locales.

EKS Anywhere instala una distribución de Kubernetes conforme en su hardware (típicamente vSphere o bare metal), opcionalmente con visibilidad de EKS Connector en la consola de AWS. Elija ECS Anywhere para un híbrido ligero basado en definiciones de tareas; 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 orquestación consistente: el valor fundamental es que los equipos evitan mantener dos sistemas de CI/CD o dos modelos mentales.

Visibilidad de múltiples clústeres con EKS Connector

Las organizaciones con frecuencia operan una combinación de clústeres de EKS, Kubernetes autoadministrado en EC2 y clústeres locales. El Amazon EKS Connector registra cualquier clúster de Kubernetes conforme en la consola de EKS, lo que proporciona un único panel de vidrio para nodos, cargas de trabajo y metadatos del clúster. Es esencialmente un agente ligero más un canal SSM, la respuesta de baja sobrecarga para una “vista central de todos los clústeres”. Construir una visibilidad equivalente con Rancher, Anthos autohospedados o una federación personalizada de Prometheus/Grafana es factible, pero mucho más costoso operativamente y no se integra con IAM o el acceso basado en la consola.

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

Uniendo los patrones

Para una carga de trabajo de comercio electrónico con un front-end con balanceo de carga, una capa intermedia en contenedores y un almacén relacional donde el criterio es “la menor intervención manual posible”, la pila canónica es ALB → ECS en Fargate → Aurora Serverless v2. Cada capa elimina la propiedad a nivel de instancia: el ALB está completamente administrado, Fargate elimina los hosts y Aurora Serverless v2 escala en ACU sin dimensionamiento de instancias.

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

Para la migración lift-and-shift de Kubernetes + MongoDB, la respuesta converge en EKS + DocumentDB: la API de Kubernetes conserva los métodos de implementación, DocumentDB conserva la compatibilidad con los controladores y los perfiles de Fargate conservan las operaciones mínimas, siempre que el uso de las características de Kubernetes y la superficie de comandos de MongoDB de la carga de trabajo se encuentren dentro de los límites admitidos descritos anteriormente.

← Cómputo · Todos los dominios · Arquitecturas Serverless y Basadas en Eventos →

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

Explorar Amazon →