SAP-C02

Deep Dive

Todas las guías
Practicar ahora
D2 · Diseño de nuevas soluciones

Microservicios y contenedores: ECS, EKS y API Gateway

El SAP-C02 evalúa la capacidad de diseñar arquitecturas de microservicios a escala empresarial. ECS, EKS, Fargate y API Gateway son los pilares de las aplicaciones cloud-native en AWS.

Icon-Architecture/48/Arch_Amazon-Elastic-Container-Service_48

Principios de microservicios en AWS

Desacoplamiento

Cada servicio tiene su propia base de datos y se comunica via APIs o mensajería. Sin dependencias directas de esquemas.

Escalado independiente

Cada microservicio escala según su propia demanda. El servicio de pagos puede tener más instancias que el de reportes.

Tolerancia a fallos

El fallo de un servicio no cascadea al resto. Patterns: Circuit Breaker, Bulkhead, Timeout.

CI/CD independiente

Cada equipo puede desplegar su servicio sin coordinación. Pipelines separados por microservicio.

Icon-Architecture/48/Arch_Amazon-Elastic-Container-Service_48

Amazon ECS — Elastic Container Service

ECS es el orquestador de contenedores nativo de AWS. Define cargas de trabajo como Tasks (contenedores individuales) y Services (grupos de Tasks con escalado y registro de servicio).

Conceptos clave de ECS

Task DefinitionBlueprint del contenedor: imagen Docker, CPU/memoria, variables de entorno, puertos, IAM role (Task Role), volúmenes.
TaskInstancia en ejecución de una Task Definition. Puede ser standalone o parte de un Service.
ServiceGarantiza que N tareas estén corriendo. Integra con ALB/NLB. Soporta Rolling Updates y Blue/Green deploy.
ClusterAgrupación lógica de tareas e instancias. Con EC2 launch type: tú gestionas las instancias. Con Fargate: AWS gestiona.
Task RoleIAM Role para permisos del contenedor (acceder a S3, DynamoDB, etc.). Diferente del Instance Role del EC2.

ECS Launch Types

EC2 Launch Type

  • Tú provisiones y gestionas instancias EC2
  • ECS Cluster Capacity Provider + ASG para escalado automático de instancias
  • Control total: tipos de instancia, AMI, storage local
  • Más barato a gran escala con Reserved/Spot instances
  • Overhead operacional: parchado de OS, AMI updates

Fargate Launch Type

  • AWS gestiona toda la infraestructura subyacente
  • Sin instancias EC2 que gestionar
  • Paga por vCPU/memoria de la Task (más caro por unidad)
  • Ideal para cargas variables o equipos sin experiencia en infra
  • Fargate Spot para cargas tolerantes a interrupciones
Icon-Architecture/48/Arch_Amazon-Elastic-Kubernetes-Service_48

Amazon EKS — Kubernetes gestionado

EKS es Kubernetes gestionado en AWS. AWS gestiona el control plane (kube-apiserver, etcd, scheduler). Tú gestionas los worker nodes (EC2 o Fargate). Compatibilidad nativa con el ecosistema Kubernetes estándar.

Node Groups

Grupos de EC2 instances (Managed o Self-Managed). Managed Node Groups usan ASG y parchado automático.

Fargate Profiles

Pods corren en Fargate. AWS gestiona la infraestructura. Sin worker nodes EC2.

EKS Anywhere

Ejecuta EKS en on-premises (VMware, bare metal). Mismo plano de control para nube y on-premises.

EKS Distro

Distribución Kubernetes open-source que usa EKS. Para instalar en cualquier infraestructura.

IRSA

IAM Roles for Service Accounts. Asigna IAM roles a pods específicos (mínimo privilegio a nivel de pod).

EKS Add-ons

CoreDNS, kube-proxy, VPC CNI, EBS CSI driver gestionados por AWS con updates automáticos.

Icon-Architecture/48/Arch_AWS-Fargate_48

AWS Fargate — serverless containers

Características de Fargate

  • Sin gestión de EC2: sin parchado de OS, sin AMI management
  • Modelo de precios: por vCPU y GB de memoria reservados por segundo
  • Cada Task tiene su propia ENI (mayor aislamiento de red vs EC2)
  • Fargate Spot: hasta 70% descuento para cargas tolerantes a interrupción
  • Escala a 0 — sin instancias idle cuando no hay trabajo
  • Storage efímero de Tasks: hasta 200GB (no persiste al stop de la task)
  • Compatible con EFS para storage persistente compartido entre tasks

Networking de Fargate

awsvpc modeÚnico modo de red soportado. Cada Task tiene su propia ENI con IP privada en la VPC.
Security GroupsSe aplican directamente a la ENI de la Task (nivel de task, no de instancia).
Service ConnectService discovery y routing entre microservicios ECS sin App Mesh. Reemplaza Cloud Map + App Mesh para casos simples.
NAT GatewayTasks en subnets privadas necesitan NAT Gateway para acceder a internet (pull de imágenes, llamadas a APIs externas).

Amazon API Gateway — gestión de APIs

TipoProtocoloDespliegueMejor para
REST APIHTTP/HTTPSEdge / Regional / PrivateAPIs REST con transformaciones, caching, autenticación compleja
HTTP APIHTTP/HTTPSRegional únicamenteAPIs simples, bajo costo (70% más barato que REST), menor latencia
WebSocket APIWebSocketRegionalChat, notificaciones en tiempo real, conexiones persistentes bidireccionales

Autenticación en API Gateway

    IAM AuthSigV4 signing. Para apps dentro de AWS con IAM roles.
    Cognito AuthorizerJWT tokens de Cognito User Pools. Para apps con usuarios propios.
    Lambda AuthorizerLambda custom que valida tokens propios o externos. Máxima flexibilidad.
    API Keys + Usage PlansThrottling y cuotas por cliente. Para APIs públicas con monetización.

Throttling y protección

    Account Limit10,000 req/s por región por defecto (ajustable).
    Stage ThrottleLímites por stage (prod vs dev). Rate + Burst configurables.
    Usage PlansThrottle por API Key: Rate, Burst y Quota (diaria/semanal/mensual).
    WAF IntegrationAWS WAF para protección contra SQLi, XSS y rate-based rules.
Icon-Architecture/48/Arch_AWS-App-Mesh_48

Service Mesh con AWS App Mesh

App Mesh es el service mesh de AWS. Inyecta un sidecar proxy (Envoy) en cada microservicio para gestionar el tráfico entre servicios sin modificar el código de la aplicación.

Observabilidad: traces y métricas de tráfico E-W sin código

Traffic shifting: canary/blue-green entre versiones

Circuit breaking y retries automáticos

mTLS entre microservicios sin modificar código

Icon-Architecture/48/Arch_Amazon-Elastic-Container-Service_48

ECS vs EKS — árbol de decisión

CriterioECSEKS
¿Ya usan Kubernetes?No es la opción naturalSí — compatibilidad nativa con k8s
¿Portabilidad multi-cloud?Limitado a AWSSí — mismo YAML funciona en GKE/AKS
¿Overhead operacional tolerable?Bajo — API nativa AWSMayor — k8s tiene curva de aprendizaje
¿Integración profunda con AWS?Mejor — nativo con todos los serviciosBuena — via plugins (CSI, CNI, etc.)
¿Control granular de scheduling?LimitadoCompleto — taints, tolerations, affinity
¿Costo del control plane?Gratis$0.10/h por cluster (~$73/mes)
¿Cargas de trabajo a gran escala?Funciona bienMejor para orquestación compleja
Icon-Architecture/48/Arch_Amazon-Elastic-Container-Service_48

Trampas frecuentes del examen

Trampa: "Fargate elimina la necesidad de gestionar clusters ECS/EKS"

Realidad: Fargate elimina la gestión de instancias EC2 (worker nodes), pero el cluster ECS o el control plane EKS siguen existiendo. Solo cambia quién gestiona la infraestructura de compute.

Trampa: "API Gateway HTTP API tiene todas las funciones de REST API"

Realidad: HTTP API es más barato pero tiene menos funciones: sin caching, sin request/response transformations, sin usage plans, sin private integrations a VPC Links complejos.

Trampa: "ECS Task Role y Instance Role son lo mismo"

Realidad: Son diferentes. Instance Role aplica al EC2 que corre las Tasks. Task Role aplica específicamente a los contenedores en esa Task Definition. Siempre usar Task Role para seguir el principio de mínimo privilegio.

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Una empresa tiene microservicios desplegados en ECS Fargate. El servicio de pagos necesita acceder a DynamoDB y Secrets Manager. El equipo de seguridad quiere que SOLO el servicio de pagos tenga esos permisos, no los otros microservicios del mismo cluster. ¿Cómo lograr esto correctamente?

Inicia sesión para llevar tu progreso.