AWS Container Platform Architecture — Overview
Containers are the standard deployment unit for microservices on AWS. The platform spans image management (ECR), orchestration (ECS/EKS), compute (Fargate/EC2), networking (ALB/NLB/Service Connect), and observability (Container Insights/X-Ray). This architecture is heavily tested on DOP-C02 (deployment and operations) and SAP-C02 (architectural decisions).
Image scanning
Lifecycle policies
Cross-region replication
AWS-native
Task Definitions
Services
Kubernetes
Pods / Deployments
Helm / Operators
Serverless
No nodes
Full control
GPU/Spot
Service Connect / Cloud Map
VPC Lattice (cross-account)
App Mesh (service mesh)
X-Ray (distributed tracing)
FireLens (log routing)
Prometheus + Grafana (EKS)
Task/Pod IAM roles
Secrets Manager injection
GuardDuty (EKS runtime)
Rolling update
Canary (weighted TG)
ArgoCD / Flux (EKS)
ECS vs EKS — Decision Guide
| Factor | ECS | EKS |
|---|---|---|
| Complexity | Simpler — AWS-native, less operational overhead | More complex — full Kubernetes with ecosystem tooling |
| Portability | AWS-only (proprietary API) | Portable — run same manifests on any K8s (on-prem, GKE, AKS) |
| Ecosystem | AWS integrations (CodeDeploy, Service Connect) | Rich K8s ecosystem (Helm, Istio, ArgoCD, Prometheus, OPA) |
| Scaling | ECS Service Auto Scaling (simple) | HPA + Karpenter/Cluster Autoscaler (more flexible) |
| Networking | awsvpc mode (ENI per task), Service Connect | VPC-CNI (pod IPs from VPC), Ingress controllers, Service mesh |
| Cost | No control plane fee | $0.10/hr per cluster ($73/month) + node costs |
| Choose when | AWS-only shop, want simplicity, small-medium team | Multi-cloud/hybrid, K8s expertise, need ecosystem tools, regulatory portability |
Compute — Fargate vs EC2
| Factor | Fargate | EC2 |
|---|---|---|
| Management | No nodes — fully serverless, AWS manages infrastructure | You manage nodes — patching, AMIs, capacity |
| Scaling | Scales per-task instantly (no node provisioning) | Requires node scaling (ASG or Karpenter) — takes 1-2 min |
| Cost model | Pay per vCPU/GB per second (no idle node cost) | Pay per instance-hour (can use Spot/RI for 50-70% savings) |
| GPU support | Not supported | Full GPU instance support (P4, G5, Inf2) |
| Storage | Ephemeral (20GB default, up to 200GB) + EFS | Full EBS, instance store, EFS, FSx |
| Best for | Variable workloads, small-medium tasks, no-ops teams | Predictable high-volume, GPU/ML, DaemonSets, privileged containers |
Cost Decision Rule of Thumb
- Fargate cheaper when: Utilization is <50% (bursty workloads, dev/test, batch jobs)
- EC2 cheaper when: Utilization is >50% consistently (use Reserved Instances or Savings Plans + Spot for non-critical)
- Mixed strategy: Fargate for baseline + EC2 Spot capacity providers for spikes
Networking Patterns
Ingress (North-South)
- ALB: Layer 7 — path/host routing, gRPC, WebSocket, authentication integration. Best for HTTP/HTTPS microservices.
- NLB: Layer 4 — ultra-low latency, static IPs, TCP/UDP. Best for non-HTTP protocols, high throughput.
- API Gateway: For serverless-first architectures integrating with containers via VPC Link → NLB → ECS/EKS.
Service Discovery (East-West)
| Option | How | Best For |
|---|---|---|
| ECS Service Connect | Envoy sidecar auto-injected, namespace-based DNS | ECS service-to-service with traffic management |
| Cloud Map | DNS-based or API-based service registry | Simple DNS discovery without service mesh overhead |
| VPC Lattice | Managed L7 networking with IAM auth, cross-account | Cross-VPC/cross-account service communication with Zero Trust |
| Kubernetes Service/Ingress | Native K8s DNS (CoreDNS) + Ingress controllers | EKS-native service discovery within cluster |
Auto-Scaling
ECS Scaling
- Service Auto Scaling: Target tracking (CPU/Memory utilization), step scaling, or scheduled scaling on desired task count
- Capacity Providers: ECS manages EC2 ASG capacity automatically — scales nodes when tasks need capacity
- Fargate: No node scaling needed — each task gets its own compute instantly
EKS Scaling
- Horizontal Pod Autoscaler (HPA): Scales pod replicas based on CPU/memory/custom metrics
- Karpenter: Provisions optimal EC2 nodes in seconds based on pending pod requirements (replaces Cluster Autoscaler)
- KEDA: Event-driven scaling (scale on SQS queue depth, Kafka lag, custom metrics)
- Fargate on EKS: Pods run serverless — no node scaling, instant per-pod provisioning
Deployment Strategies
| Strategy | ECS | EKS |
|---|---|---|
| Rolling | Default — replace tasks gradually (minHealthy/maxPercent) | Default K8s Deployment strategy (maxSurge/maxUnavailable) |
| Blue/Green | CodeDeploy — new task set + ALB target group switch | ArgoCD Rollouts or Flagger with Ingress/Service mesh |
| Canary | CodeDeploy Canary (% traffic to new for X minutes) | Flagger/ArgoCD Rollouts with progressive traffic shifting |
| GitOps | Not native (use CodePipeline) | ArgoCD / Flux — Git as source of truth, auto-sync |
Security
| Layer | ECS | EKS |
|---|---|---|
| Image security | ECR image scanning (Inspector), lifecycle policies, immutable tags, signing with Notation | |
| IAM | Task Role (per-task IAM credentials via credential provider) | IAM Roles for Service Accounts (IRSA) or Pod Identity — per-pod credentials |
| Secrets | Secrets Manager / Parameter Store → injected as env vars or mounted | Secrets Store CSI Driver → mounts AWS Secrets as K8s volumes |
| Network policy | Security Groups per task (awsvpc mode) | K8s Network Policies (Calico) + Security Groups for Pods |
| Runtime security | GuardDuty ECS Runtime Monitoring | GuardDuty EKS Runtime Monitoring + EKS audit log monitoring |
Observability Stack
- Container Insights: CPU, memory, network, disk metrics per task/pod + cluster-level dashboards (CloudWatch)
- X-Ray: Distributed tracing across services — inject X-Ray daemon as sidecar or use ADOT (OpenTelemetry)
- FireLens: ECS log router (Fluent Bit sidecar) — route logs to CloudWatch, S3, OpenSearch, Datadog, Splunk
- Prometheus + Grafana: Native for EKS — Amazon Managed Prometheus (AMP) + Amazon Managed Grafana (AMG)
- EKS audit logs: Control plane API audit logs → CloudWatch Logs (detect unauthorized access attempts)
Exam Tips by Certification
| Exam | Focus Areas |
|---|---|
| DOP-C02 | ECS Blue/Green with CodeDeploy, Fargate vs EC2 decision, capacity providers, auto-scaling configuration, FireLens log routing, image scanning in CI/CD pipeline |
| SAP-C02 | ECS vs EKS selection criteria, Fargate cost optimization, multi-account container deployment, Service Connect vs VPC Lattice, migration from on-prem K8s to EKS |
AWS Certification Exam Practice Questions
Question 1:
A company runs 50 microservices on EKS. Their cluster nodes are often under-utilized (30% average CPU) because the Cluster Autoscaler provisions nodes too conservatively. They want faster scaling with better bin-packing. What should they use?
- Increase HPA target utilization from 50% to 80%
- Replace Cluster Autoscaler with Karpenter
- Switch all workloads to Fargate
- Use larger EC2 instance types for better packing
Show Answer
Answer: B – Karpenter provisions nodes in seconds (vs minutes for Cluster Autoscaler), selects optimal instance types based on pending pod requirements, and consolidates under-utilized nodes automatically. It provides better bin-packing by choosing right-sized instances and removes nodes when pods can be consolidated elsewhere.
Question 2:
An ECS service needs to connect to other ECS services by name (e.g., http://payment-service:8080) with automatic load balancing, health checking, and traffic metrics — without managing an ALB for each internal service. Which feature provides this?
- Cloud Map DNS-based discovery
- ECS Service Connect
- VPC Lattice
- Application Load Balancer with multiple target groups
Show Answer
Answer: B – ECS Service Connect provides namespace-based DNS discovery with an auto-injected Envoy sidecar that handles load balancing, health checking, retries, and traffic metrics between ECS services. It’s simpler than managing per-service ALBs and provides built-in observability. Cloud Map is DNS-only without the traffic management features.
Question 3:
An EKS pod needs to access an S3 bucket and DynamoDB table. The security team requires that ONLY this specific pod gets these permissions — not other pods on the same node. What is the recommended approach?
- Attach the permissions to the node’s EC2 instance profile
- Use IAM Roles for Service Accounts (IRSA) or EKS Pod Identity
- Store access keys as K8s secrets and mount in the pod
- Use a VPC endpoint policy to restrict access to this pod’s security group
Show Answer
Answer: B – IRSA (or the newer EKS Pod Identity) associates an IAM role with a specific Kubernetes service account. Only pods using that service account get those credentials. Other pods on the same node don’t have access. Instance profiles grant permissions to ALL pods on a node (violates least privilege). Access keys are long-term credentials (anti-pattern).
Question 4:
A company wants zero-downtime deployments for their ECS Fargate service with the ability to instantly roll back if health checks fail. The deployment should create a new task set, validate it, then switch traffic. Which configuration achieves this?
- ECS rolling update with minimumHealthyPercent=100, maximumPercent=200
- CodeDeploy Blue/Green deployment with ECS, ALB listener rules, and CloudWatch alarm-based rollback
- Manual task count adjustment — double tasks, then drain old
- ECS service with multiple task definitions running simultaneously
Show Answer
Answer: B – CodeDeploy Blue/Green creates a new task set (green), registers it with a test ALB listener for validation, then switches the production listener from old (blue) to new (green). If CloudWatch alarms fire during the switch window, CodeDeploy instantly reroutes traffic back to blue. The old task set is drained after a configurable wait period.
Question 5:
A startup runs a variable workload on ECS — 2 tasks during business hours and 0 tasks at night. They want minimum cost with no node management overhead. On weekdays, tasks need to scale up to 20 within seconds during marketing campaigns. Which configuration fits?
- EC2 launch type with Reserved Instances and an ASG scheduled action
- Fargate launch type with ECS Service Auto Scaling (target tracking on CPU)
- EC2 Spot instances with capacity provider managed scaling
- Fargate Spot for all tasks to minimize cost
Show Answer
Answer: B – Fargate charges per-second with no idle cost (0 tasks at night = $0). It scales to 20 tasks instantly (no node provisioning delay). Target tracking auto-scaling adjusts task count based on CPU. No node management overhead. Fargate Spot could reduce costs further but risks interruptions during campaigns. For variable, scale-to-zero workloads, Fargate on-demand is optimal.
Related Posts
- AWS EKS vs ECS – Decision Guide
- AWS ALB vs NLB vs GWLB
- AWS CI/CD Pipeline Architecture
- AWS Event-Driven Serverless Architecture
- AWS Zero Trust Architecture
References
- AWS Containers Blog
- EKS Best Practices Guide
- ECS Service Connect — AWS Blog
- Karpenter — Node Autoscaling for Kubernetes
- ECS Deployment Circuit Breaker — AWS Blog
📖 Related: Launch Template vs Launch Configuration
Frequently Asked Questions
Is Fargate always more expensive than EC2?
No. Fargate is cheaper for variable, bursty workloads with <50% average utilization because you pay nothing when tasks aren’t running. EC2 becomes cheaper at >50% sustained utilization, especially with Reserved Instances or Savings Plans. Most production workloads benefit from a mix: Fargate for base + EC2 Spot for peaks.
ECS vs EKS for a new project — which should I pick?
If your team has no Kubernetes experience and you’re AWS-only, choose ECS — less operational overhead, tighter AWS integration, no control plane cost. If you need Kubernetes portability, have K8s expertise, or want ecosystem tools (Helm, ArgoCD, Istio, OPA), choose EKS. Both support Fargate.
Can I run sidecars on Fargate?
Yes. ECS Fargate supports multiple containers per task definition (native sidecars with lifecycle dependencies since 2023). EKS Fargate also supports sidecar containers in pods. Common sidecars: Envoy (Service Connect), X-Ray daemon, Fluent Bit (logs), ADOT (OpenTelemetry).