Cargando...
Cargando...
Choose the right abstraction level — from zero-config magic to full orchestration control
Abstraction level is the core differentiator: App Runner > Elastic Beanstalk > ECS
| Feature | Elastic Beanstalk PaaS for apps with full EC2 access | ECS Fully managed container orchestration service | App Runner Serverless containers, zero infrastructure knowledge |
|---|---|---|---|
Abstraction Level Exam loves testing: 'Developer wants to deploy without managing infrastructure' → App Runner. 'Need full control over container orchestration' → ECS. 'Legacy app team familiar with traditional PaaS' → Elastic Beanstalk. | Medium — PaaS that manages EC2, ASG, ELB, but you still see the infra | Low-to-Medium — you define tasks, clusters, services; choose EC2 or Fargate launch type | Highest — fully abstracts all infrastructure; just bring source code or container image |
Primary Use Case Elastic Beanstalk is NOT a container-native service — it supports Docker but was designed for traditional runtimes. ECS is purpose-built for containers. App Runner is purpose-built for simple containerized web services. | Web apps and APIs in standard runtimes (Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker); teams migrating from traditional PaaS | Microservices, batch jobs, long-running containerized workloads needing fine-grained orchestration | Stateless web apps and APIs that need rapid deployment from source code or container image with auto-scaling to zero |
Infrastructure Visibility & Control Critical differentiator: If the question mentions 'SSH access', 'custom AMI', or 'instance-level configuration' → Elastic Beanstalk (not ECS, not App Runner). App Runner is a trap answer whenever infrastructure access is required. | Full visibility — you can SSH into EC2 instances, modify Auto Scaling groups, customize load balancers, use .ebextensions for deep customization | Full control — define CPU/memory at task level, choose networking mode (bridge, host, awsvpc), configure IAM task roles, placement strategies | No visibility — AWS manages all compute, networking, and scaling; you cannot access underlying instances |
Compute Options / Launch Types Elastic Beanstalk does NOT support Fargate. This is a common trap. ECS supports BOTH EC2 and Fargate. App Runner is effectively serverless but is NOT Fargate — it's a separate managed compute layer. | EC2 only (single instance or load-balanced with Auto Scaling); no native Fargate support | EC2 launch type (you manage EC2 fleet), Fargate launch type (serverless), ECS Managed Instances, or external instances (ECS Anywhere) | Fully serverless — AWS-managed compute only; no EC2 or Fargate selection needed by user |
Container Support Elastic Beanstalk multi-container Docker environments actually use ECS under the hood — a critical fact tested on SAA-C03 and DVA-C02. | Supports Docker (single container and multi-container via Docker Compose or ECS-backed multi-container platform); not the primary container tool | Native container orchestration — Task Definitions define containers, images, resource limits, environment variables, secrets, health checks | First-class container support — point to ECR image or GitHub/CodeCommit source; builds and deploys automatically |
Scaling Behavior App Runner is the ONLY one of the three that scales to zero automatically. ECS Fargate does NOT scale to zero by default. This distinction is heavily tested in cost-optimization questions. | Auto Scaling Groups on EC2 — scales EC2 instances based on metrics (CPU, network, custom CloudWatch); you configure min/max instance counts | Service Auto Scaling (Application Auto Scaling) for task count; Cluster Auto Scaling for EC2 capacity; Fargate scales tasks without managing instances | Automatic, instant scaling including scale-to-zero during inactivity; concurrency-based scaling (requests per instance); no configuration required |
Deployment Mechanism ECS Blue/Green deployments REQUIRE CodeDeploy and an ALB — this is heavily tested. Elastic Beanstalk Blue/Green is done by swapping environment URLs (CNAME swap) — a different mechanism. App Runner handles deployment automatically. | Rolling, Rolling with additional batch, Immutable, Blue/Green (via environment swap), All-at-once; managed via EB CLI, Console, or CodePipeline | Rolling update (default), Blue/Green via CodeDeploy (requires Application Load Balancer); canary and linear traffic shifting supported with CodeDeploy | Automatic deployment from ECR on image push or from source repo on commit; built-in blue/green-style traffic shifting; no manual deployment steps |
Networking & VPC Integration ECS with awsvpc mode is the most granular — each task gets its own security group. App Runner's VPC integration is for OUTBOUND connections to private resources; inbound traffic always goes through App Runner's managed load balancer. | Full VPC support — place EC2 instances in specific subnets, configure security groups, use internal or external load balancers | Full VPC support — awsvpc networking mode gives each task its own ENI and private IP; supports VPC endpoints, security groups at task level | VPC connector support available — can connect App Runner services to resources in a VPC (RDS, ElastiCache); outbound VPC access only by default |
CI/CD Integration App Runner's automatic deployment from source is unique — no CodePipeline needed. For complex pipelines with approval gates, testing stages, and multi-environment promotion → ECS or Elastic Beanstalk with CodePipeline. | Native integration with CodePipeline, CodeBuild, CodeDeploy; EB CLI for local deployment; supports S3 source bundles | Deep integration with CodePipeline + CodeDeploy for Blue/Green; ECR as image registry; CodeBuild for image builds; full CI/CD pipeline support | Built-in automatic deployment triggers from ECR image push or GitHub/CodeCommit commits; simplest CI/CD — no pipeline configuration needed |
Supported Languages / Runtimes Elastic Beanstalk's managed platform support (auto-patching of runtimes) is a differentiator for teams that want AWS to manage runtime updates. ECS and App Runner require you to manage your own base images. | Java, .NET, .NET Core, PHP, Node.js, Python, Ruby, Go, Docker, Tomcat — native platform support with managed runtime patching | Any language/runtime that can be containerized — no restrictions; you bring your own Docker image | Any language/runtime via container image (ECR); native build support for Python, Node.js, Java (Corretto) from source code |
Stateful Workloads App Runner is explicitly for STATELESS applications. Any question mentioning persistent storage, session state, or stateful workloads eliminates App Runner as an answer. | Supported — EC2 instances can use EBS volumes; suitable for some stateful patterns with careful architecture | Supported — EFS integration for shared persistent storage; EBS volumes for EC2 launch type; Fargate supports EFS mounts | NOT recommended — stateless workloads only; no persistent storage; ephemeral compute |
Pricing Model Elastic Beanstalk and ECS control planes are FREE. App Runner charges for active compute time. For cost optimization: App Runner wins for sporadic/low-traffic apps (scales to zero). For steady high-traffic: EC2-backed ECS or Elastic Beanstalk may be cheaper. | FREE service — you pay only for underlying AWS resources (EC2, ELB, ASG, RDS, S3, etc.); no additional Beanstalk charges | FREE control plane — you pay for EC2 instances (EC2 launch type) or Fargate vCPU/memory per-second pricing (Fargate launch type); ECR storage charged separately | Pay for compute (vCPU-second, memory-GB-second) while processing requests PLUS a flat provisioned concurrency charge when idle (if auto-scaling to zero is disabled); charged per active instance |
Observability & Monitoring ECS Container Insights provides the deepest observability including per-container metrics. Elastic Beanstalk Enhanced Health Monitoring is unique — it gives a color-coded health status (Green/Yellow/Red/Grey) that aggregates EC2, ELB, and app metrics. | Built-in health dashboard, CloudWatch metrics for EC2/ELB, Enhanced Health Monitoring with EB agent; access to full CloudWatch Logs | CloudWatch Container Insights (optional, additional cost); CloudWatch metrics for service/task level; AWS X-Ray integration; FireLens for log routing | Built-in CloudWatch metrics, CloudWatch Logs; AWS X-Ray tracing support; no Container Insights equivalent |
Multi-Region / High Availability None of these services are inherently multi-region. Multi-region HA always requires Route 53 routing policies (latency, failover, geolocation) combined with per-region deployments of whichever service you choose. | Single-region per environment; use Route 53 + multiple EB environments across regions for multi-region HA | Single-region per cluster; use Global Accelerator or Route 53 with multi-region ECS clusters for global HA | Single-region per service; App Runner handles AZ redundancy automatically within a region |
Security & IAM ECS Task IAM Role is the most granular — each task can have different permissions. This is a critical security concept tested heavily on SAA-C03 and DOP-C02. Elastic Beanstalk uses an EC2 instance profile shared across all processes on the instance. | Instance profile (IAM role for EC2 instances), service role for Beanstalk itself; environment-level security groups; supports Secrets Manager and Parameter Store via .ebextensions | Task IAM Role (fine-grained per-task permissions — best practice), Task Execution Role (for ECR pull and CloudWatch Logs), cluster-level IAM; Secrets Manager native integration in Task Definition | Instance role for the App Runner service; IAM-based access control; Secrets Manager and Parameter Store integration for environment variables |
Windows Container Support App Runner does NOT support Windows containers. For Windows containerized workloads → ECS (EC2 or Fargate). For .NET Framework apps → Elastic Beanstalk Windows platform or ECS Windows containers. | Supports Windows Server platforms (.NET, .NET Core on Windows); Docker on Windows supported | Full Windows container support on EC2 launch type; Fargate supports Windows containers (Fargate platform for Windows) | Linux containers only — no Windows container support |
Complexity / Learning Curve Exam scenario: 'A startup developer team with no AWS expertise wants to deploy a containerized API quickly' → App Runner. The word 'quickly' or 'minimal operational overhead' is the key signal. | Low-to-Medium — familiar PaaS model; .ebextensions can get complex; good for teams new to AWS | Medium-to-High — requires understanding of Task Definitions, Services, Clusters, networking modes, IAM roles; powerful but verbose | Very Low — minimal AWS knowledge required; ideal for developers who want to focus purely on application code |
On-Premises / Hybrid Support ECS Anywhere is the ONLY option among these three for hybrid/on-premises container orchestration. This is a high-value SAP-C02 and DOP-C02 exam topic. | Cloud only — no on-premises deployment capability | ECS Anywhere — run ECS tasks on on-premises servers, VMs, or other cloud environments using the ECS agent; register external instances to ECS cluster | Cloud only — no on-premises deployment capability |
GPU Workloads ML inference and GPU workloads → ECS on GPU EC2 instances. App Runner cannot be used for GPU workloads. | Possible by selecting GPU EC2 instance types in the environment configuration | Supported — GPU-enabled EC2 instances (P3, G4, G5 families) with GPU resource reservation in Task Definitions; ECS Managed Instances supports GPU | Not supported — no GPU instance access |
Worker / Background Job Support Elastic Beanstalk Worker Tier with SQS is a unique and frequently tested pattern. If you see 'decouple web tier from processing tier using SQS' with Elastic Beanstalk → Worker Tier is the answer. | Worker tier — dedicated environment type that processes jobs from SQS queue; automatic SQS integration with daemon process | Scheduled tasks (EventBridge + ECS Run Task), ECS Services for long-running workers, Batch-style workloads via task execution | Not designed for background workers — HTTP/HTTPS request-driven only; no native queue processing |
Summary
Choose App Runner when developers need the fastest path to production with zero infrastructure knowledge — ideal for stateless web APIs and microservices. Choose ECS when you need full container orchestration control, complex networking, hybrid deployments (ECS Anywhere), GPU support, or fine-grained IAM at the task level. Choose Elastic Beanstalk when your team is migrating traditional web applications to AWS, needs the familiar PaaS model with access to underlying EC2 instances, or requires the native Worker Tier + SQS integration for background job processing.
🎯 Decision Tree
If (stateless API + zero infra management + auto scale-to-zero) → App Runner | If (full container orchestration + microservices + Blue/Green via CodeDeploy + ECS Anywhere + GPU) → ECS | If (traditional web app + PaaS model + Worker Tier + SSH access to EC2 + .ebextensions customization) → Elastic Beanstalk | If (multi-container Docker on Elastic Beanstalk) → Note: uses ECS under the hood | If (Windows containers) → ECS or Elastic Beanstalk (NOT App Runner) | If (on-premises containers) → ECS Anywhere only
CRITICAL — Elastic Beanstalk multi-container Docker environments use ECS under the hood. When you see 'Elastic Beanstalk multi-container Docker' on an exam, remember that ECS Task Definitions and ECS clusters are created automatically. This means ECS knowledge applies to understanding what Beanstalk creates behind the scenes.
CRITICAL — ECS Blue/Green deployments REQUIRE CodeDeploy + Application Load Balancer. Elastic Beanstalk Blue/Green uses CNAME swap between two environments (no CodeDeploy required). App Runner does automatic blue/green-style deployments with no configuration. These three different mechanisms are a prime exam trap — match the mechanism to the service.
CRITICAL — ECS Task IAM Role vs Task Execution Role: Task IAM Role = permissions your APPLICATION code uses (e.g., read S3, write DynamoDB). Task Execution Role = permissions ECS AGENT uses to pull ECR images and write CloudWatch Logs. Both are required for a fully functioning ECS Fargate task. Confusing these two roles is the #1 ECS IAM mistake on DVA-C02 and SAA-C03.
IMPORTANT — App Runner is the ONLY service of the three that scales to zero automatically. For cost optimization questions about sporadic/unpredictable traffic with containerized workloads → App Runner. ECS Fargate does NOT scale to zero by default (you can set desired count to 0 manually, but it's not automatic). Elastic Beanstalk cannot scale to zero.
IMPORTANT — Elastic Beanstalk Worker Tier with SQS is a unique architectural pattern not available in ECS or App Runner natively. If an exam scenario describes a web application that needs to offload long-running tasks to a background processor using SQS decoupling within the same Elastic Beanstalk application → Worker Tier is the answer. ECS would require custom SQS polling code.
IMPORTANT — ECS Anywhere is the ONLY option among these three for running containers on on-premises or non-AWS infrastructure. SAP-C02 and DOP-C02 frequently test hybrid scenarios. If you see 'on-premises containers managed from AWS' → ECS Anywhere. Elastic Beanstalk and App Runner are cloud-only.
NICE-TO-KNOW — Elastic Beanstalk .ebextensions files (in .config format inside the application bundle) allow deep customization of the environment including installing packages, running commands, modifying configuration files, and creating AWS resources. This is unique to Beanstalk — ECS uses Task Definition overrides and App Runner uses environment variables only.
NICE-TO-KNOW — App Runner VPC connector allows OUTBOUND connections from App Runner to private VPC resources (RDS, ElastiCache, etc.). Inbound traffic to App Runner always comes through App Runner's managed public endpoint. You cannot make App Runner fully private (no inbound VPC-only access) — this is a limitation that may eliminate App Runner for strict private network requirements.
The #1 exam trap: Assuming Elastic Beanstalk is the best choice for containerized microservices because it 'supports Docker.' Elastic Beanstalk was designed for traditional web applications and uses ECS under the hood for multi-container Docker — meaning ECS directly is almost always the better answer for container-native architectures. App Runner is the trap answer for any scenario requiring stateful workloads, Windows containers, GPU, on-premises, or complex pipeline control. Candidates also frequently confuse ECS Blue/Green (CodeDeploy + ALB required) with Elastic Beanstalk Blue/Green (CNAME swap, no CodeDeploy) — these are fundamentally different mechanisms despite the same name.
CertAI Tutor · SAA-C03, DOP-C02, DVA-C02, SAP-C02, DEA-C01, CLF-C02 · 2026-02-22
Services