The Decision That Gets Made Implicitly
A platform engineer at a mid-market SaaS company told me her team had three different compute platforms running across their applications. Some services on Lambda. Some on Fargate. A few new services on App Runner. The mix had emerged team by team without an overall decision framework. When she joined the company in 2024, she spent six weeks understanding why each service was where it was.
The answers were mostly historical rather than principled. The first team had picked Lambda because the founder was a serverless enthusiast. The second team had picked Fargate because they had a Docker workflow. The third team had picked App Runner because they had a tight deadline and App Runner had the lowest setup overhead.
She told me the audit confirmed something she suspected. Each platform was running workloads that fit it, and each was also running workloads that did not fit. The Lambda fleet had services that should have been on Fargate. The Fargate fleet had services that should have been on Lambda. The App Runner fleet had services that should have been on Fargate.
The pattern is common. Modern AWS app deployment offers three platforms with overlapping capabilities. The decision among them gets made based on team familiarity or tactical convenience more often than based on workload fit. The result is portfolios that operate adequately and waste meaningful amounts of cost and engineering attention.
Why 95% Demo Accuracy Becomes 65% On Your Real Portfolio
Why AI lease abstraction drops from 95% to 65% in production.
What Each Platform Actually Is
The three platforms target different workload patterns despite their overlap.
AWS Lambda is function-as-a-service compute. Code runs in response to events. The platform handles all infrastructure. Pricing is per invocation and per execution duration. The platform fits stateless, event-driven, request-response workloads with short to moderate execution times.
AWS App Runner is fully managed container compute. Container images run as web applications. The platform handles deployment, scaling, and load balancing. Pricing is per provisioned vCPU and memory. The platform fits stateless web applications and APIs that benefit from container packaging without container operational overhead.
AWS Fargate is serverless container orchestration. Container images run with explicit task and service definitions. The platform handles the underlying compute; the customer configures the orchestration. Pricing is per vCPU and memory consumed. The platform fits container workloads that need more control than App Runner provides.
The boundaries between them are real and matter for specific workloads.
When Lambda Wins
Lambda wins for workloads with specific characteristics.
Event-driven processing of individual items. S3 events, EventBridge events, SQS messages all trigger Lambda naturally. The pay-per-invocation pricing matches the workload pattern. The operational simplicity is meaningful.
API endpoints with bursty traffic patterns. Lambda combined with API Gateway scales from zero to substantial traffic without infrastructure management. The pricing model favors variable workloads with significant idle time.
Short-running compute that fits within Lambda's timeout. Most AI inference calls. Most data transformation jobs. Most integration logic between AWS services. The pattern fits.
Stateless workloads without sticky session requirements. Lambda's execution model assumes statelessness. Stateful workloads work poorly.
For these patterns, Lambda usually beats Fargate on cost and operational simplicity. The decision is straightforward.
When App Runner Wins
App Runner wins for workloads that fall between Lambda and Fargate in needs.
Web applications and APIs that need container packaging but not container orchestration complexity. App Runner runs the container without requiring task definitions, service configurations, or load balancer setup. The deployment is simpler than Fargate.
Workloads that benefit from automatic scaling without explicit scaling configuration. App Runner scales based on traffic without operator configuration. Fargate also scales but requires more explicit setup.
Teams without strong container operations expertise. App Runner hides much of the container orchestration that Fargate exposes. Teams that want the benefits of containers without learning Kubernetes or ECS service management benefit from App Runner.
Workloads that need persistent connections or longer execution than Lambda allows. App Runner handles long-running HTTP connections that Lambda's timeout would constrain.
For these patterns, App Runner usually fits well. The platform's positioning between Lambda's full abstraction and Fargate's explicit orchestration matches specific workload needs.
When Fargate Wins
Fargate wins for workloads that need container orchestration capabilities.
Workloads with explicit service patterns. Microservices that need to scale based on specific metrics, services with specific networking requirements, services that need to participate in service mesh patterns. ECS or EKS with Fargate provides the orchestration these workloads need.
Workloads with stateful or sticky requirements. WebSocket connections, long-running tasks, services that need predictable identity. Fargate's task lifecycle gives explicit control that Lambda and App Runner do not.
Workloads with complex deployment patterns. Blue-green deployments, canary releases with specific routing logic, multi-container services. Fargate within ECS or EKS supports these patterns natively.
Workloads with cost optimization concerns at sustained scale. Fargate Spot for batch workloads. Savings Plans for steady workloads. The cost optimization options for Fargate exceed what App Runner and Lambda provide.
For these patterns, Fargate is usually the right choice. The additional operational complexity pays back through the orchestration capability.
The Three Decisions That Distinguish
Three specific decisions usually distinguish which platform fits.
The first decision is around state and persistence. Stateless request-response workloads fit Lambda or App Runner. Stateful workloads usually fit Fargate.
The second decision is around scaling pattern. Bursty workloads with idle time fit Lambda. Steady workloads with predictable traffic fit Fargate. Mixed patterns fit App Runner.
The third decision is around team operational capacity. Teams without container expertise fit App Runner or Lambda. Teams with container expertise can take advantage of Fargate's flexibility.
These three decisions together usually point to one platform clearly. Workloads where multiple platforms fit equally often benefit from picking based on team consistency rather than continuing to evaluate.
What the Hybrid Portfolio Looks Like
Most enterprises in 2026 end up with mixed portfolios across the three platforms.
A typical mid-market SaaS company might have webhook receivers, async processing, and event-driven integrations on Lambda. Public APIs and customer-facing web services on App Runner or Fargate depending on operational maturity. Background services, batch processing, and orchestrated workflows on Fargate.
The mix is fine when each workload runs on the right platform for its characteristics. The mix becomes a problem when workloads are on the wrong platform for historical reasons.
The pattern that produces a healthy mix is deliberate platform selection per workload combined with periodic review of placement. Workloads that have grown beyond their original platform get migrated. Workloads on platforms that produce friction get reevaluated.
What This Costs
The cost economics differ substantially across the three platforms.
Lambda pricing is per-invocation plus per-execution-duration. The pricing is predictable for known invocation rates and variable for unknown rates.
App Runner pricing is per-provisioned-vCPU and memory plus invocation count. The pricing is more predictable than Lambda for sustained workloads but less variable for low-traffic ones.
Fargate pricing is per-vCPU and memory consumed. The pricing is most predictable of the three but requires explicit capacity planning.
For workloads where multiple platforms fit, the cost comparison depends on specific traffic patterns. A workload with 10K invocations per day costs differently across the three than a workload with 10M invocations per day.
Why $400K of API Integrations Doesn't Fix Your Property Management
Why $400K in integrations fails to fix property data issues.
What Logiciel Does Here
Logiciel works with engineering teams designing or rationalizing compute platform decisions across AWS. The work is typically structured around workload-by-workload assessment and platform selection appropriate to each workload's characteristics.
The EKS vs ECS vs Fargate: 2026 Compute Decision framework covers the container orchestration decisions that affect Fargate adoption. The AWS Lambda for AI Inference framework covers the AI-specific Lambda considerations.
A 30-minute working session is enough to assess your workload portfolio against the three platforms.
Frequently Asked Questions
Can I use multiple platforms for the same application?
Yes, and most successful architectures do. Different parts of an application have different characteristics. The API layer might be App Runner. The async processing might be Lambda. The background workers might be Fargate. The mix follows workload fit.
How does this work with EKS?
EKS provides a different orchestration model than ECS with Fargate. Workloads requiring Kubernetes ecosystem benefit from EKS. Workloads that fit ECS patterns get more operational simplicity. App Runner is not directly comparable to EKS; it targets simpler workload patterns.
What about Lightsail?
Lightsail targets simpler workloads than the three discussed here. It fits very basic use cases (small websites, simple databases, basic compute) where the abstraction simplicity matters more than the flexibility. Most production workloads outgrow Lightsail.
How does AI workload integration affect the decision?
AI inference workloads usually fit Lambda for request-response patterns. AI workloads with longer execution or sustained throughput fit Fargate. The patterns from the broader decision apply with AI-specific characteristics.
When should I migrate between platforms?
When the current platform produces friction the alternative would solve. Migration carries real cost. The benefits have to be specific. Migration for fashion rarely justifies the cost. Sources: - AWS App Runner documentation, 2024 - AWS Compute Comparison Guide, 2024
