All guides
Practice now
D2 · Design for New Solutions

Microservices and containers: ECS, and API Gateway

The SAP-C02 evaluates your ability to design enterprise-scale microservices architectures. ECS, EKS, Fargate and API Gateway are the pillars of cloud-native applications on AWS.

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

Microservices principles on AWS

Decoupling

Each service has its own database and communicates via APIs or messaging. No direct schema dependencies.

Independent scaling

Each microservice scales according to its own demand. The payments service can have more instances than the reporting one.

Fault tolerance

A service failure doesn't cascade to the rest. Patterns: Circuit Breaker, Bulkhead, Timeout.

Independent CI/CD

Each team can deploy its service without coordination. Separate pipelines per microservice.

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

Amazon ECS — Elastic Container Service

is AWS's native container orchestrator. It defines workloads as Tasks (individual containers) and Services (groups of Tasks with scaling and service discovery).

Key ECS concepts

Task DefinitionContainer blueprint: Docker image, CPU/memory, environment variables, ports, IAM role (Task Role), volumes.
TaskA running instance of a Task Definition. Can be standalone or part of a Service.
ServiceEnsures N tasks are running. Integrates with ALB/NLB. Supports Rolling Updates and Blue/Green deploy.
ClusterLogical grouping of tasks and instances. With EC2 launch type: you manage the instances. With Fargate: AWS manages them.
Task RoleIAM Role for container permissions (accessing S3, , etc.). Different from the EC2 Instance Role.

ECS Launch Types

EC2 Launch Type

  • • You provision and manage EC2 instances
  • • ECS Cluster Capacity Provider + ASG for automatic instance scaling
  • • Full control: instance types, AMI, local storage
  • • Cheaper at scale with Reserved/Spot instances
  • • Operational overhead: OS patching, AMI updates

Fargate Launch Type

  • • AWS manages the entire underlying infrastructure
  • • No EC2 instances to manage
  • • Pay per vCPU/memory reserved by the Task (more expensive per unit)
  • • Ideal for variable workloads or teams without infra experience
  • • Fargate Spot for interruption-tolerant workloads
Icon-Architecture/48/Arch_Amazon-Elastic-Kubernetes-Service_48

Amazon EKS — managed Kubernetes

EKS is managed Kubernetes on AWS. AWS manages the control plane (kube-apiserver, etcd, scheduler). You manage the worker nodes (EC2 or Fargate). Native compatibility with the standard Kubernetes ecosystem.

Node Groups

Groups of EC2 instances (Managed or Self-Managed). Managed Node Groups use an ASG and automatic patching.

Fargate Profiles

Pods run on Fargate. AWS manages the infrastructure. No EC2 worker nodes.

EKS Anywhere

Runs EKS on-premises (VMware, bare metal). Same control plane for cloud and on-premises.

EKS Distro

Open-source Kubernetes distribution that powers EKS. For installing on any infrastructure.

IRSA

IAM Roles for Service Accounts. Assigns IAM roles to specific pods (least privilege at the pod level).

EKS Add-ons

CoreDNS, kube-proxy, VPC CNI, EBS CSI driver managed by AWS with automatic updates.

Icon-Architecture/48/Arch_AWS-Fargate_48

— serverless containers

Fargate features

  • No EC2 management: no OS patching, no AMI management
  • Pricing model: per vCPU and GB of memory reserved per second
  • Each Task has its own ENI (greater network isolation vs EC2)
  • Fargate Spot: up to 70% discount for interruption-tolerant workloads
  • Scales to 0 — no idle instances when there's no work
  • Ephemeral Task storage: up to 200GB (doesn't persist after the task stops)
  • Compatible with EFS for persistent storage shared across tasks

Fargate networking

awsvpc modeThe only supported network mode. Each Task has its own ENI with a private IP in the VPC.
Security GroupsApplied directly to the Task's ENI (task level, not instance level).
Service ConnectService discovery, routing and TLS between ECS microservices with a managed proxy. The recommended replacement for App Mesh on ECS.
NAT GatewayTasks in private subnets need a to reach the internet (image pulls, calls to external APIs).

Amazon — API management

TypeProtocolDeploymentBest for
REST APIHTTP/HTTPSEdge / Regional / PrivateREST APIs with transformations, caching, complex authentication
HTTP APIHTTP/HTTPSRegional onlySimple APIs, lower cost (70% cheaper than REST), lower latency
WebSocket APIWebSocketRegionalChat, real-time notifications, persistent bidirectional connections

Authentication in API Gateway

    IAM AuthSigV4 signing. For apps within AWS with IAM roles.
    Cognito AuthorizerJWT tokens from Cognito User Pools. For apps with their own users.
    Lambda AuthorizerCustom Lambda that validates its own or external tokens. Maximum flexibility.
    API Keys + Usage PlansThrottling and quotas per client. For public APIs with monetization.

Throttling and protection

    Account Limit10,000 req/s per region by default (adjustable).
    Stage ThrottleLimits per stage (prod vs dev). Configurable Rate + Burst.
    Usage PlansThrottle per API Key: Rate, Burst and Quota (daily/weekly/monthly).
    WAF Integration for protection against SQLi, XSS and rate-based rules.
Icon-Architecture/48/Arch_AWS-App-Mesh_48

Service mesh: ECS Service Connect and VPC Lattice (formerly App Mesh)

AWS App Mesh is discontinued on September 30, 2026. On ECS its replacement is Service Connect, which adds an AWS-managed proxy to each task with no sidecars to operate; for EKS, or to connect services across VPCs and accounts, use Amazon VPC Lattice. Both manage service-to-service traffic without modifying the code.

Observability: E-W traffic metrics in CloudWatch without code

Traffic shifting: blue/green and canary (ECS or Lattice weighted routing)

Automatic retries and outlier detection

Security: TLS with Service Connect and IAM auth policies with Lattice

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

ECS vs EKS — decision tree

CriterionECSEKS
Already using Kubernetes?Not the natural fitYes — native k8s compatibility
Multi-cloud portability?Limited to AWSYes — same YAML works on GKE/AKS
Operational overhead tolerable?Low — native AWS APIHigher — k8s has a learning curve
Deep AWS integration?Better — native across all servicesGood — via plugins (CSI, CNI, etc.)
Granular scheduling control?LimitedFull — taints, tolerations, affinity
Control plane cost?Free$0.10/h per cluster (~$73/month)
Large-scale workloads?Works wellBetter for complex orchestration
Icon-Architecture/48/Arch_Amazon-Elastic-Container-Service_48

Common exam traps

Trap: "Fargate removes the need to manage ECS/EKS clusters"

Reality: Fargate removes the need to manage EC2 instances (worker nodes), but the ECS cluster or the EKS control plane still exist. Only who manages the compute infrastructure changes.

Trap: "API Gateway HTTP API has all the features of REST API"

Reality: HTTP API is cheaper but has fewer features: no caching, no request/response transformations, no usage plans, no private integrations to complex VPC Links.

Trap: "ECS Task Role and Instance Role are the same thing"

Reality: They're different. Instance Role applies to the EC2 running the Tasks. Task Role applies specifically to the containers in that Task Definition. Always use Task Role to follow the principle of least privilege.

Did you get this topic?

Test what you just learned

A company has microservices deployed on ECS Fargate. The payments service needs to access DynamoDB and Secrets Manager. The security team wants ONLY the payments service to have those permissions, not the other microservices in the same cluster. How should this be achieved correctly?

Ready to test "Microservices and Containers: ECS, EKS and API Gateway"?

Put what you learned to the test with original SAP-C02 exam questions.

Start SAP-C02 mock exam

Unlimited mock exams with the Pro plan

Log in to track your progress.