Cargando...
Cargando...
Deploy containerized web apps and APIs at scale — no infrastructure management required.
AWS App Runner is a fully managed service that lets developers deploy containerized web applications and APIs directly from source code or a container image, without managing servers, clusters, or load balancers. It automatically handles provisioning, scaling, load balancing, and TLS termination, making it ideal for teams that want container benefits without operational overhead. App Runner bridges the gap between raw container orchestration (ECS/EKS) and traditional PaaS (Elastic Beanstalk), offering automatic scale-to-zero cost optimization.
Rapidly deploy and auto-scale containerized web services and APIs without provisioning or managing any underlying infrastructure.
Use When
Avoid When
Automatic scaling (horizontal)
Scales in/out based on concurrent requests per instance
Scale to zero
Minimum instances can be set to 0; cold starts apply
Automatic TLS/HTTPS
No ACM management required; custom domains supported
Source code deployment (GitHub/Bitbucket)
App Runner builds and deploys from source automatically
Container image deployment (ECR)
Public and private ECR repositories supported
Automatic deployment on image push
Triggers on new ECR image or code commit
VPC connector (outbound to private VPC)
Required to reach RDS, ElastiCache, etc.
AWS Secrets Manager integration
Secrets injected as environment variables at runtime
AWS Systems Manager Parameter Store integration
Parameters injected as environment variables
AWS X-Ray tracing
Built-in distributed tracing, no sidecar needed
Amazon CloudWatch logs and metrics
Automatic log streaming and service metrics
AWS WAF integration
Web application firewall for API protection
Custom domains
With automatic ACM certificate provisioning
Health checks (HTTP and TCP)
Configurable interval, threshold, and timeout
Persistent storage volumes
No EBS/EFS mounting — stateless workloads only
Reserved Instance pricing
Pay-as-you-go only; no reserved capacity pricing model
Multi-port services
Single port per service only
Spot/preemptible compute
No Spot pricing equivalent; use ECS Fargate Spot for that model
GPU instances
CPU-only compute; use ECS/EKS for GPU workloads
Windows containers
Linux containers only
IPv6
IPv4 only for App Runner endpoints as of current docs
Private endpoints (inbound VPC)
Inbound traffic is always via App Runner's public managed endpoint
Automated Container CD Pipeline
high freqApp Runner monitors a private ECR repository and automatically deploys new image versions when pushed. The App Runner access role must have ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, and ecr:GetAuthorizationToken permissions. This eliminates the need for a separate CodePipeline trigger for simple deployments.
Secure Runtime Secret Injection
high freqApp Runner retrieves secrets from Secrets Manager at container startup and injects them as environment variables. The instance IAM role must have secretsmanager:GetSecretValue permission. This avoids hardcoding credentials in container images or source code — a key security pattern for DOP-C02 and SAP-C02.
Configuration Parameter Injection
high freqNon-sensitive configuration (feature flags, endpoints, non-secret config) stored in SSM Parameter Store is injected into App Runner containers at startup. Instance role needs ssm:GetParameters permission. Preferred over Secrets Manager for non-sensitive config due to lower cost.
Private Database Connectivity via VPC Connector
high freqApp Runner uses a VPC Connector (attached to a VPC, subnets, and security groups) to establish outbound connectivity to RDS instances in a private subnet. Without a VPC connector, App Runner cannot reach private VPC resources. This is the standard pattern for App Runner + database architectures.
API Audit Trail for Compliance
high freqAll App Runner API calls (CreateService, UpdateService, DeleteService, etc.) are logged by CloudTrail. For compliance requirements (SOC2, PCI-DSS), CloudTrail provides the authoritative audit trail of who changed what and when. CloudTrail is for AUDITING API calls; GuardDuty is for THREAT DETECTION — do not confuse them.
Migration Path: Beanstalk to App Runner
high freqOrganizations migrating from Elastic Beanstalk to App Runner gain scale-to-zero capability and reduced operational overhead. Key difference: Beanstalk manages EC2 instances (cannot scale to zero), while App Runner is fully serverless. This migration pattern appears in SAP-C02 modernization scenarios.
Configuration Compliance Monitoring
medium freqAWS Config tracks configuration changes to App Runner services (instance size, scaling config, VPC connector changes) and can trigger alerts or auto-remediation via Config Rules when services drift from desired state. Used in governance-heavy environments.
Static Asset and Object Storage Integration
medium freqApp Runner applications access S3 buckets (for uploads, downloads, or static content) via the instance IAM role with appropriate S3 permissions. App Runner itself does not natively serve S3 content — CloudFront + S3 handles static assets while App Runner handles dynamic API traffic.
API Protection with Web Application Firewall
medium freqAWS WAF is associated directly with an App Runner service to protect against OWASP Top 10 threats (SQL injection, XSS, etc.). WAF rules are evaluated before traffic reaches the App Runner instances. This is the recommended pattern for publicly exposed APIs.
Distributed Tracing for Microservices
medium freqX-Ray tracing is enabled in the App Runner service configuration. The X-Ray daemon runs as a managed sidecar — developers only need to instrument their application code with the X-Ray SDK. Traces flow automatically to X-Ray for end-to-end latency analysis across microservices.
App Runner CAN scale to zero (minimum instances = 0); Elastic Beanstalk CANNOT scale to zero because it always maintains at least one EC2 instance. Any exam question asking how to eliminate overnight compute costs for a containerized web service should choose App Runner over Elastic Beanstalk.
App Runner has NO Reserved Instance pricing, NO Savings Plans, and NO Spot pricing. It is pure pay-as-you-go. If an exam question asks about reducing App Runner costs via reserved capacity, that option is a DISTRACTOR — it does not exist.
There are TWO separate IAM roles in App Runner: (1) ACCESS ROLE — used by the App Runner SERVICE to pull images from ECR; (2) INSTANCE ROLE — used by your APPLICATION CODE to call AWS APIs (S3, DynamoDB, Secrets Manager, etc.). Exam questions that describe an app failing to read from S3 need the instance role fixed, not the access role.
VPC Connectors provide OUTBOUND connectivity from App Runner to private VPC resources (RDS, ElastiCache, internal services). Inbound traffic to App Runner always comes through App Runner's managed public HTTPS endpoint — you cannot route inbound traffic through your own VPC without using a proxy pattern.
CloudTrail logs App Runner API calls for compliance auditing (who created/modified/deleted services). GuardDuty detects threats and anomalous behavior. These are DIFFERENT services with DIFFERENT purposes — exam questions about compliance audit trails for App Runner changes require CloudTrail, not GuardDuty.
App Runner scales to ZERO (no traffic = no compute cost). Elastic Beanstalk CANNOT. Any scenario about eliminating idle compute costs for containerized HTTP services → choose App Runner.
App Runner has NO Reserved Instance, Savings Plan, or Spot pricing. If an answer choice suggests 'purchase reserved capacity for App Runner,' it is WRONG — that option does not exist.
Two IAM roles: ACCESS ROLE (App Runner service pulls ECR images) vs. INSTANCE ROLE (your app code calls AWS APIs). App can't read S3? Fix the INSTANCE role. Can't pull ECR image? Fix the ACCESS role.
App Runner auto-scales based on CONCURRENT REQUESTS per instance, not CPU or memory utilization. This is fundamentally different from ECS/EC2 Auto Scaling which uses CloudWatch metrics like CPU%. When an exam scenario describes traffic spikes causing latency, App Runner's scaling trigger is concurrent requests.
App Runner supports BOTH source code deployments (from GitHub/Bitbucket — App Runner builds the container) AND pre-built container image deployments (from ECR). Automatic deployment can be triggered by either a new code commit or a new ECR image push. This is a key CI/CD differentiator from ECS.
App Runner is HTTP/HTTPS ONLY. It cannot handle non-HTTP protocols (TCP arbitrary ports, UDP, WebSocket raw connections at the infrastructure level). If a workload needs arbitrary TCP or UDP, use ECS/EKS with NLB instead.
For the DEA-C01 (Data Engineer) exam context: App Runner can serve ML inference APIs and data processing microservices, but it does NOT support GPU compute or persistent storage. Data pipelines requiring GPU or stateful storage should use SageMaker endpoints or ECS with EFS.
Overprovisioning is an anti-pattern for App Runner. Because it auto-scales horizontally, you should right-size your INSTANCE (vCPU/memory) for a SINGLE request, not for peak load. Peak load is handled by scaling OUT the number of instances. Setting max instances too low is the real scaling bottleneck.
App Runner automatically provisions and renews TLS certificates via ACM for both the default apprunner.com subdomain AND custom domains. You do NOT need to manually create ACM certificates or attach them to a load balancer — this is a key operational simplicity differentiator from ALB+ECS patterns.
Common Mistake
App Runner supports Reserved Instance pricing, similar to EC2 or RDS, which can reduce costs for predictable workloads.
Correct
App Runner has NO Reserved Instance pricing, NO Savings Plans, and NO Spot instances. It is exclusively pay-as-you-go based on active compute time (vCPU-hours and GB-memory-hours). There is no way to pre-purchase capacity at a discount.
This is the #1 pricing misconception on certification exams. Candidates familiar with EC2 Reserved Instances assume all AWS compute services offer similar pricing tiers. For predictable, high-utilization workloads, ECS on Fargate with Compute Savings Plans may actually be more cost-effective than App Runner. The exam tests whether you know App Runner's pricing model is fundamentally different.
Common Mistake
ECS on Fargate Spot is always more cost-effective than App Runner for containerized APIs because Spot pricing offers up to 70% savings.
Correct
Fargate Spot CAN be cheaper per compute unit, but it introduces interruption risk — Spot tasks can be reclaimed by AWS with a 2-minute warning. For latency-sensitive APIs that cannot tolerate interruptions, App Runner's consistent pricing and scale-to-zero capability may deliver better total cost of ownership. The right answer depends on workload characteristics, not just the per-hour rate.
Exam scenarios often present Fargate Spot as the obvious cost winner. The trap is ignoring interruption risk and the operational complexity of handling Spot terminations. App Runner's scale-to-zero is the actual cost optimization lever — idle App Runner services cost nothing, while Fargate Spot tasks still cost money when running.
Common Mistake
Elastic Beanstalk can scale to zero instances to eliminate overnight costs, just like App Runner.
Correct
Elastic Beanstalk CANNOT scale to zero. It always maintains at least one EC2 instance running (the web tier), which incurs continuous compute costs. App Runner is unique among AWS application deployment services in supporting true scale-to-zero for HTTP workloads.
This misconception causes candidates to choose Elastic Beanstalk for cost-optimization scenarios when App Runner is the correct answer. The key differentiator: if the exam question mentions 'eliminate costs when no traffic' or 'scale to zero,' App Runner is the answer, not Beanstalk.
Common Mistake
You should provision App Runner instances to handle peak traffic load, just like sizing EC2 instances for maximum expected demand.
Correct
App Runner instances should be sized for a SINGLE concurrent request, not peak load. Peak load is handled automatically by scaling OUT (adding more instances) based on concurrent requests per instance. Overprovisioning instance size wastes money without improving throughput — the correct lever is adjusting the maximum instance count and the concurrent requests per instance threshold.
Candidates with EC2 background think 'bigger instance = more capacity.' In App Runner's horizontal scaling model, a fleet of smaller right-sized instances is more cost-effective and resilient than a few over-provisioned large instances. This is tested in cost optimization and architecture design scenarios.
Common Mistake
GuardDuty provides the audit trail for App Runner API changes needed for compliance requirements.
Correct
AWS CloudTrail provides the API audit trail for App Runner (and all AWS services) — it logs who called which API, when, and from where. GuardDuty is a threat detection service that identifies anomalous behavior and potential security threats. For compliance audit requirements (SOC2, PCI-DSS), you need CloudTrail, not GuardDuty.
GuardDuty vs. CloudTrail confusion appears frequently across multiple exam domains. Remember: CloudTrail = 'who did what' (audit log); GuardDuty = 'something suspicious is happening' (threat detection). A compliance auditor asking 'who deleted the App Runner service?' needs CloudTrail. A security team asking 'is someone trying to exfiltrate data?' needs GuardDuty.
Common Mistake
App Runner's VPC connector allows external users to access App Runner services through a private VPC endpoint.
Correct
VPC connectors provide OUTBOUND connectivity FROM App Runner TO private VPC resources (like RDS, ElastiCache, or internal services). Inbound traffic to App Runner services ALWAYS flows through App Runner's managed public HTTPS endpoint — VPC connectors do not create private inbound access paths.
This architectural misconception leads to incorrect network designs. If you need truly private inbound access to App Runner (no public internet exposure), you would need to architect a proxy layer in your VPC. For most use cases, App Runner's public HTTPS endpoint with WAF is the correct and simpler approach.
SCALE mnemonic for App Runner advantages: S=Scale-to-zero, C=Container or Code source, A=Automatic TLS, L=Load balancing managed, E=Elastic horizontal scaling — all without touching infrastructure.
TWO ROLES rule: 'A for Access = App Runner pulls from ECR; I for Instance = your app Instance calls AWS APIs.' If the app can't reach S3, fix the Instance role. If App Runner can't pull the image, fix the Access role.
App Runner vs Beanstalk cost: 'Runner runs away from cost (scales to zero); Beanstalk always has a stalk standing (minimum 1 EC2 always running).'
CloudTrail vs GuardDuty: 'Trail = tracks footprints (audit log of API calls); Guard = guards the door (detects threats).' Compliance audit = Trail. Security anomaly = Guard.
CertAI Tutor · SAP-C02, DEA-C01, DOP-C02 · 2026-02-21