If you’re studying for the AWS Certified Solutions Architect (Associate or Professional), compute is where a lot of exam questions “hide the ball.” The scenario might mention users, latency, or cost—but what the prompt really tests is whether you can pick the right compute model and justify it.
This guide focuses on EC2, Lambda, and AWS Fargate and the compute patterns you’ll keep seeing on both the Solutions Architect and hands-on architecture interviews. Along the way, we’ll connect compute decisions to VPC networking, storage choices, and managed services, because on real AWS projects you rarely design compute in isolation.
You’ll also get budget/cost thinking (great for ROI) and practical mental models you can reuse during timed exams.
Why compute patterns matter on the Solutions Architect exams
The Solutions Architect exams aren’t only “service recall.” They’re design reasoning exams. That means they test whether you can:
- Choose the best compute option for workload shape (steady vs spiky, stateful vs stateless)
- Handle scaling requirements correctly (vertical vs horizontal vs event-driven)
- Control operational overhead (patching, servers, deployments, observability)
- Keep costs aligned with usage patterns (especially for spikes or low traffic)
- Use the right integration patterns with other services
EC2, Lambda, and Fargate represent three very different operational models:
- EC2: You manage the compute layer—great control, more ops responsibility
- Lambda: Event-driven, serverless functions—great for spiky workloads and quick wins
- Fargate: Container runtime with managed infrastructure—great for portability and steady workloads
A good exam answer usually includes a why, not just a what.
Quick mental model: pick compute by workload shape
Here’s the core decision logic you can apply to almost any compute question:
Workload shape → compute model
- Always-on, predictable, or long-running → often EC2 or Fargate
- Spiky or event-driven → usually Lambda
- Need containers but don’t want to manage servers → Fargate
- Need OS-level tuning, custom networking/kernel modules, or special runtime needs → EC2
- Need rapid scaling without thinking about server groups → Lambda (or Fargate with autoscaling)
Operational burden → compute model
- If you want to manage patching, AMIs, instance lifecycle, and OS details → EC2
- If you want AWS to manage the runtime environment for you → Lambda (fully managed)
- If you want containers without managing EC2 instances → Fargate
Keep this lens in mind. It’ll make the rest of the article click.
EC2: the “classic” compute building block (and exam favorite)
EC2 is the foundation of many AWS architectures. Even when you use serverless or containers, EC2 shows up behind the scenes in a lot of setups.
When EC2 is the best choice
EC2 tends to win when you need:
- Stateful workloads where the instance lifetime matters
- Custom operating system requirements
- Fixed/steady capacity with predictable demand
- Integration patterns requiring control over networking on the host (within reason)
- HPC-style or specialized software stacks
On the exam, EC2 is often the right answer when the prompt says things like:
- “The application runs continuously.”
- “We need to control the operating system.”
- “We have a legacy app that requires a specific runtime environment.”
- “We need consistent performance for a certain throughput.”
How EC2 scales: the core patterns
EC2 doesn’t scale itself. You scale it with AWS primitives that sit around it.
1) Auto Scaling Groups (ASGs) + Launch Templates
This is the default exam answer for “scale out/in EC2 under a load balancer” scenarios.
A typical pattern:
- Application Load Balancer (ALB) routes traffic to healthy targets
- ASG maintains desired capacity
- CloudWatch alarms trigger scaling policies
- Launch Template defines AMI, instance type, security groups, user data, and tags
Why exam writers like this: it demonstrates classic enterprise best practice—health checks, rolling updates, and capacity management.
2) Spot Instances for cost-sensitive workloads
If a scenario emphasizes cost and tolerates interruptions, Spot becomes relevant.
Key exam nuance:
- Spot is not for “cannot be interrupted” workloads.
- You need to design for interruption handling and resilience.
3) Vertical scaling vs horizontal scaling
EC2 scaling strategies:
- Vertical: larger instance type (often faster to implement)
- Horizontal: more instances (more resilient, usually better for availability)
For Solutions Architect questions, if they mention availability zones and scaling, they’re usually nudging you toward horizontal scaling.
EC2 + networking: why VPC design is inseparable
Compute doesn’t live in a vacuum. On AWS, compute decisions are shaped by VPC design, subnets, routing, and security groups.
If you haven’t already, revisit the fundamentals here: VPC, Route 53, and CloudFront Fundamentals: Networking Concepts That Make or Break Your AWS Architect Designs. Even for pure compute questions, you’ll often need to place workloads correctly (public vs private subnets, NAT access, load balancer placement).
Also, remember that security groups are stateful, and NACLs are stateless. On the exam, “can’t reach the database” issues often trace back to these.
Lambda: serverless compute for event-driven architectures
Lambda is where the exam transitions from “servers” to “work units.” Instead of scaling instances, you scale invocations.
When Lambda is the best choice
Lambda shines when:
- Work is triggered by events (API calls, S3 uploads, DynamoDB changes, queues)
- You don’t want to manage servers or patch runtimes
- You have spiky traffic
- You need to respond quickly to events without running always-on services
Typical exam cues:
- “The workload is intermittent.”
- “We only run tasks when events occur.”
- “We need to process data when it lands in S3.”
- “We’re building a lightweight API backend.”
The Lambda execution model (important for exam reasoning)
Lambda executes your code in an AWS-managed environment. Key concepts you should internalize:
- Concurrency scaling: Lambda can run many invocations in parallel
- Event sources: triggers that start executions
- Timeout: max duration before Lambda stops
- Memory size: affects CPU allocation (more memory can improve performance)
- Cold starts: not always mentioned, but can appear in latency discussions
On exam day, you’ll rarely be asked for exact numbers—but you need to understand the direction of performance/cost tradeoffs.
Common Lambda patterns you’ll see
1) API backend (HTTP API/Lambda integration)
You might get a question like “we need an API with low ops overhead.” The best answer may involve:
- API Gateway → Lambda (for routing and auth)
- Lambda does compute work
- Optional: store data in DynamoDB or call RDS
This is a classic “reduce server management” path.
2) S3 event processing
Example: When a file is uploaded to S3, Lambda:
- Reads the object
- Processes it (resize, parse, transform)
- Writes results back to S3 or updates a database
Exam twist: sometimes it asks how to decouple processing. Lambda + S3 events is usually the decoupling mechanism.
3) Queue-based async processing
If the prompt mentions reliability and decoupling:
- SQS → Lambda (event source mapping)
- Lambda processes messages
- Retries and DLQ patterns handle failures
This is one of the safest ways to demonstrate asynchronous compute reasoning.
4) Orchestration with Step Functions
Lambda often becomes part of a bigger workflow:
- Step Functions coordinates multi-step processes
- Lambda performs tasks
- Failure handling is built into the workflow
If you see multi-step logic with retries and state transitions, Step Functions frequently becomes the “clean” answer.
Lambda cost thinking (exam + ROI)
Cost on Lambda is usually described in terms of:
- request count
- duration per invocation
- memory allocation
How to reason quickly during the exam:
- If traffic is low or spiky, Lambda is often cost-effective because you pay per use, not for idle capacity.
- If traffic is high and steady, Fargate/EC2 might be cheaper depending on the details.
For budgetcourses.net readers, the key ROI takeaway is: Lambda helps you avoid paying for idle compute, especially when the workload isn’t constant.
Fargate: containers without managing servers
Fargate sits in a sweet spot: it provides container benefits without EC2 instance management. It’s commonly used with Amazon ECS (and also with EKS in other contexts, but ECS + Fargate is the common exam focus).
When Fargate is the best choice
Choose Fargate when:
- You want containers for portability and packaging
- You don’t want to manage underlying EC2 instances
- You need autoscaling based on demand
- You have steady workloads that don’t fit Lambda’s “event function” model well
Exam cues:
- “We’re already using containers.”
- “We don’t want to manage the server fleet.”
- “We need a scalable environment for a long-running service.”
Fargate vs EC2 for containers: the key difference
- EC2 + ECS: you manage the instances; you configure capacity providers and scaling
- Fargate + ECS: AWS manages the compute layer; you configure task definitions and desired scaling
On exam day, when the prompt says “simplify operations” or “don’t manage servers,” that’s often your pointer toward Fargate.
The ECS/Fargate design pieces to recognize
A typical pattern includes:
- Task definitions (container image, CPU/memory, ports, environment variables)
- Services (desired count, deployment configuration)
- Load balancers (often ALB for HTTP/HTTPS)
- Auto scaling policies (CPU/memory or custom metrics)
- Networking (awsvpc mode, subnets, security groups)
If you’re fuzzy on networking placement, the exam becomes guesswork. Use the networking guide mentioned earlier: VPC, Route 53, and CloudFront Fundamentals: Networking Concepts That Make or Break Your AWS Architect Designs.
Side-by-side: EC2 vs Lambda vs Fargate (how to choose fast)
You’ll likely see questions that require selecting the “best fit.” Here’s a comparison you can use while studying.
| Category | EC2 | Lambda | Fargate |
|---|---|---|---|
| Primary model | Virtual machines | Event-driven functions | Containers as managed tasks |
| Ops responsibility | Higher (patching/OS) | Low (fully managed runtime) | Medium-low (no server management) |
| Best workload shape | Steady, long-running, custom OS/runtime needs | Spiky, event-driven, short tasks | Steady services packaged as containers |
| Scaling control | ASG + Load Balancing | Concurrency + event source scaling | ECS service autoscaling |
| Typical triggers/inputs | Requests to instances | Events (S3/SQS/API/etc.) | Service traffic via load balancer |
| Exam “tell” | “We need OS control” / “always-on app” | “event-driven” / “intermittent” | “containers” / “don’t manage servers” |
| Cost intuition | Pay for capacity (instances) | Pay per request + duration | Pay per task resource usage |
The trick is not memorizing this table—it’s applying the right row based on the scenario language.
The compute patterns you need to master (deep dives + exam reasoning)
Now let’s get practical. Below are compute patterns that map directly to what exam questions test. For each, I’ll explain the “why,” what can go wrong, and a realistic example you can mentally simulate.
Pattern 1: Autoscaling web tier (EC2 + ALB + ASG)
What the prompt usually looks like
- “An application must handle variable traffic.”
- “We need high availability across multiple AZs.”
- “We need to automatically scale without manual intervention.”
- “Use a managed load balancer.”
Best-fit design
- ALB for routing
- ASG with Launch Template
- Health checks integrated with the ALB target group
- Optionally CloudFront in front for global edge caching
Why this is a classic Solutions Architect answer
Because it shows:
- High availability (multi-AZ)
- Resilient scaling behavior (ASG)
- Managed routing and health checks (ALB)
- Clean separation between networking and compute
Common pitfalls (that exam questions love)
- Scaling instances without a load balancer (leads to manual traffic changes)
- Using a single AZ when HA is requested
- Forgetting security group rules or subnet placement
- Confusing scaling based on CPU when the workload is I/O-bound (CPU-based scaling may lag behind)
If the question includes “internet-facing” or “global users,” you may need to mention the edge layer. Tie it together with CDN knowledge in: CloudFront Fundamentals: Networking Concepts That Make or Break Your AWS Architect Designs.
Pattern 2: Event-driven processing pipeline (S3 → Lambda → DynamoDB/S3)
What the prompt usually looks like
- “Process files when they are uploaded.”
- “We need asynchronous processing.”
- “Avoid provisioning servers.”
Best-fit design
- S3 event notification triggers Lambda
- Lambda performs transformation or validation
- Results written back to DynamoDB or S3
- Consider DLQs or retry logic for failure handling
Why Lambda is the correct “compute pattern”
Because it perfectly matches the event-driven trigger model. There’s no reason to run containers or EC2 instances 24/7 when the workload happens only when objects arrive.
Expert insight: designing for retries and idempotency
Event-driven systems fail sometimes. The exam may not go deep into idempotency, but the best architecture answers always consider it.
Use strategies like:
- Idempotent writes (e.g., deterministic keys in DynamoDB)
- Checking whether work already completed
- DLQ patterns when retries exceed limits
ROI angle
Lambda often reduces cost for workflows that run irregularly, because you don’t pay for idle capacity. That’s an exam-aligned “cost optimization” story.
Pattern 3: Asynchronous microservices (SQS → Lambda → downstream services)
What the prompt usually looks like
- “We need decoupling.”
- “We want to buffer traffic.”
- “Improve reliability and avoid losing messages.”
Best-fit design
- Producers send work to SQS
- Consumers are Lambda functions triggered by SQS
- Failed messages can be retried and eventually routed to DLQ
- Downstream services might be RDS, DynamoDB, or another Lambda
Why this pattern wins
It prevents tight coupling. Your frontend or API doesn’t need to wait for every downstream operation.
On the Solutions Architect exam, this is often the “best answer” when they explicitly mention reliability and buffering.
Common pitfalls
- Doing long-running work synchronously in an API request (time-outs, poor user experience)
- Not using DLQs, leading to silent failures
- Not thinking about concurrency controls (can overwhelm downstream dependencies)
Pattern 4: Containerized long-running service (ECS + Fargate + ALB)
What the prompt usually looks like
- “We need to run a containerized web service.”
- “We don’t want to manage EC2 instances.”
- “We need autoscaling.”
Best-fit design
- ECS service using Fargate
- Task definition describes the container
- ALB routes traffic
- ECS autoscaling scales task count based on metrics
Why Fargate is right here
Because it matches the combination of:
- containers (packaging requirement)
- long-running service (not an event function)
- reduced ops (no EC2 instance management)
Deployment considerations (exam-relevant)
You may see questions about rolling deployments and minimizing downtime. ECS services support controlled deployments, and ALB health checks help route traffic only to healthy tasks.
Pattern 5: Legacy application with custom OS needs (EC2 + bespoke AMI)
What the prompt usually looks like
- “We need to run a legacy application.”
- “The application requires a custom runtime or OS configuration.”
- “We need control over the environment.”
Best-fit design
- EC2 instances with custom AMI
- Use Launch Template for consistency
- Place in private subnets with NAT if needed for updates/downloads
- Use ASG if scaling or resilience is requested
- Use ELB/ALB if traffic distribution is required
Why EC2 beats Lambda/Fargate here
Lambda and Fargate assume certain managed behaviors. If the application requires deep OS control (drivers, kernel modules, special agent configurations), EC2 is the straightforward answer.
This is also where you demonstrate “right tool for the job” on the exam.
Pattern 6: Compute + storage architecture decisions (don’t ignore this)
Compute architecture is tightly coupled to storage. For example:
- a stateless service can use distributed storage
- a stateful process might need EBS or EFS
- a cache might use ElastiCache (not our focus here, but the exam references it)
If you want the broader storage context that shows up again and again, revisit: S3, EBS, and EFS Compared: Storage Architectures You’ll See Again and Again on the AWS Solutions Architect Path.
How storage choice changes compute decisions
- EC2 often uses EBS for attached block storage and performance needs.
- Fargate tasks commonly rely on shared external storage (EFS) or object storage rather than depending on a local disk lifecycle.
- Lambda storage is ephemeral unless you use external services; for persistent data, you typically use S3/DynamoDB/RDS/EFS patterns.
Even when the question is “compute,” you’ll get partial credit for connecting the correct storage model.
Pattern 7: “Pick the most cost-effective option” (cost + workload matching)
This is where exam questions become tricky because they’re designed to bait you with familiarity.
A common exam setup
- “We have an intermittent workload.”
- “We need a cost-efficient solution.”
- “We don’t need servers running constantly.”
Best answer often:
- Lambda for event-driven processing
- Not EC2 (because idle instance cost)
- Not Fargate (because tasks may still run or you may pay for managed container capacity)
Another common setup
- “We have an always-on containerized service.”
- “We want to avoid server management.”
Best answer:
- Fargate (instead of EC2) because it reduces ops while keeping service semantics.
Expert insight: “cost-effective” doesn’t always mean “lowest unit price”
It means lowest total cost for the workload pattern. For example:
- Lambda can be cheap for infrequent tasks but expensive if you run extremely high invocation volume.
- EC2 can be cheap when steady usage keeps instances busy.
- Fargate can reduce ops cost but might not always be the cheapest compute.
The exam expects you to interpret cost relative to usage.
Compute in real AWS architectures: combining services correctly
A common trap is treating compute services as standalone. In AWS solutions, compute is just one part of the system. This section gives you the “architecture glue” patterns you’ll need.
The “core services” mindset
If you want a comprehensive compute-centric overview of how the services connect, revisit: AWS Core Services Every Solutions Architect Must Master: Compute, Storage, Networking, and More.
That knowledge helps you answer questions like:
- Where does data live?
- How does traffic reach the workload?
- How do we handle auth and rate limiting?
- What happens during failures?
Managed databases are part of compute design (and show up in scenarios)
Many compute questions include database requirements implicitly or explicitly.
If the prompt includes “scalable, managed, no server management,” your mind should jump to managed database services and how they integrate with compute.
A relevant refresher is: Managed Databases on AWS: RDS, DynamoDB, and Aurora Scenarios Every Solutions Architect Candidate Should Know.
How DB choice affects compute patterns
- Lambda often works beautifully with DynamoDB (event-driven and serverless-friendly).
- Stateful services on EC2 might use RDS with optimized connectivity.
- Containers on Fargate can integrate with any managed DB, but you’ll need correct network/security configuration.
Even if the exam question focuses on compute, the best answers demonstrate “system-level consistency.”
Security and IAM: the hidden scoring dimension
Compute answers are correct only if they’re secure. On AWS exams, “least privilege” and “secure defaults” are expected.
What to look for in compute scenarios
- Does the question mention IAM roles?
- Do they ask about who can invoke Lambda?
- Do they mention access to S3 buckets?
- Are there compliance requirements?
EC2
- Use instance profiles (IAM roles attached to instances)
- Lock down access via security groups and IAM policies
- Avoid embedding secrets in user data; use secret managers if needed
Lambda
- Use execution roles for least privilege access
- For API access, integrate auth (API Gateway / authorizers) rather than building insecure auth inside the function
Fargate
- Task roles for container permissions
- Security groups per task networking mode
- Centralized secrets strategy for container environment variables
The exam may not ask for deep IAM policy JSON, but it often tests whether you understand roles vs resources vs where permissions apply.
Observability: how to prove your architecture is healthy
Solutions Architect questions often include troubleshooting hints like “metrics,” “logs,” “alerts,” or “diagnostics.”
Typical observability expectations
- CloudWatch Logs for Lambda, ECS/EC2 app logs
- CloudWatch Metrics for scaling and alarms
- X-Ray or tracing for distributed systems
- ALB access logs and target health checks
For compute:
- Lambda automatically integrates with CloudWatch.
- ECS/Fargate logs can be shipped through log drivers.
- EC2 needs more explicit setup but CloudWatch Agent simplifies it.
Being able to describe the “observability path” earns you confidence and prevents wrong answers.
Exam strategy: how to identify the right compute service in under a minute
When you’re in exam mode, speed matters. Here’s a practical workflow.
Step-by-step approach
- Underline workload shape
- intermittent vs steady
- event-driven vs request-driven
- long-running service vs short tasks
- Identify ops appetite
- “manage servers” vs “no server management”
- Look for container hints
- image-based, container orchestration, task definitions
- Look for event source hints
- S3 uploads, queue messages, scheduled jobs
- Check scaling expectations
- “automatic” + “high traffic” + “multi-AZ”
- Confirm integration requirements
- DB type, caching, and network access
This prevents the most common mistake: choosing a service because it sounds modern rather than because it matches the scenario.
Associate vs Professional: what changes in compute questions?
For AWS Certified Solutions Architect – Associate (focus areas)
You’ll see more:
- straightforward selection between EC2/Lambda/Fargate
- standard scaling patterns (ALB + ASG, SQS + Lambda, ECS + Fargate autoscaling)
- basic cost/availability reasoning
Depth is present, but the question structure is more direct.
For AWS Certified Solutions Architect – Professional (focus areas)
You’ll see more:
- multi-service architecture decisions (designing end-to-end)
- trade-offs and constraints (compliance, scalability targets, operational requirements)
- deeper resilience and operational maturity expectations
Professional-level answers often require:
- connecting compute to networking, data, security, and deployment strategy
- choosing patterns that remain robust under real-world failure modes
If you’re aiming for Professional, spend time practicing scenario-to-architecture mapping.
Common misconceptions (and the corrections you should memorize)
Misconception 1: “Lambda is always cheapest”
Lambda can be cheap for intermittent workloads, but not always for high-throughput steady workloads. If the prompt indicates constant traffic and long-running tasks, consider Fargate or EC2.
Misconception 2: “Fargate is for background jobs only”
Fargate can run long-running services and APIs—any containerized workload that behaves like a service.
Misconception 3: “EC2 is outdated”
EC2 is extremely relevant, especially for workloads needing:
- custom OS behavior
- tight control
- specific networking or runtime conditions
- large-scale steady capacity
EC2 remains central to many enterprise architectures.
Misconception 4: “Compute choice is independent of storage”
Persistent state, session management, and data durability often change how compute should be designed. For refreshers, review: S3, EBS, and EFS Compared: Storage Architectures You’ll See Again and Again on the AWS Solutions Architect Path.
Putting it all together: scenario walkthroughs (exam-style)
Here are a few scenario mini-cases that show how to reason.
Scenario A: Intermittent file processing
Question style: “We upload images to S3. We need to resize them automatically. No servers to manage.”
Best compute: Lambda
- S3 triggers Lambda
- Lambda resizes images
- outputs stored in S3
- optionally update metadata in DynamoDB
Why not EC2/Fargate?
- Not event-driven
- Extra overhead for intermittent work
- Less efficient cost model for low-frequency operations
Scenario B: Containerized API with predictable traffic
Question style: “We have a containerized web service. Traffic is consistent. We want autoscaling and minimal ops.”
Best compute: Fargate
- ECS service with Fargate
- ALB routes to tasks
- ECS autoscaling maintains desired capacity
Why not Lambda?
- This is not “short-lived event function” style
- You need service semantics
Scenario C: Legacy app requiring custom runtime
Question style: “We must run a legacy application that requires OS-level customization and continuous availability.”
Best compute: EC2
- EC2 instances managed with Launch Templates
- ASG for horizontal scaling if needed
- ALB for load balancing if multiple instances
Budgetcourses.net perspective: cost and career ROI
The best Solutions Architect candidates don’t only know services—they understand trade-offs that impact cost and operational effort.
ROI-friendly study mindset
If you learn compute patterns as reusable blueprints, you’ll:
- answer exam questions faster
- reduce confusion under time pressure
- build architecture intuition that transfers to real job tasks
Cost-aware architecture intuition
- Use Lambda when you can truly capitalize on pay-per-use for intermittent work.
- Use EC2 when you need control and steady capacity.
- Use Fargate when containers are required but operational overhead must stay low.
That’s not just exam strategy—it’s a real-world architecture competency.
Practical checklist: “Is this architecture compute-appropriate?”
Before you lock an answer, check these:
- Workload type
- event-driven? → Lambda
- service-based container? → Fargate
- custom OS / steady capacity? → EC2
- Scaling expectation
- variable and bursty? → Lambda or autoscaling compute
- steady with service traffic? → Fargate or ASG
- Ops overhead
- “no server management” language → Lambda/Fargate
- “control OS” → EC2
- State management
- stateless workloads pair well with serverless and containers
- stateful workloads may push you toward EC2 + proper storage design
- Networking and security
- private subnets and SG rules
- IAM roles/least privilege
If you can justify these points, your answer will feel “designed,” not guessed.
Final takeaway: master patterns, not memorization
To pass (and to actually learn), focus on compute patterns that map to real architectures:
- EC2 + ALB + ASG for scalable, always-on workloads with OS control
- Lambda for event-driven processing and spiky workloads with low operational overhead
- Fargate + ECS for containerized services that need managed infrastructure and clean scaling
When you consistently match workload shape + ops appetite + scaling behavior to the right compute model, you’ll outperform candidates who only memorize service features.
If you want a broader compute-and-core-services reinforcement, start with: AWS Core Services Every Solutions Architect Must Master: Compute, Storage, Networking, and More. And if you’re also brushing up networking and request flow thinking, pair it with: VPC, Route 53, and CloudFront Fundamentals: Networking Concepts That Make or Break Your AWS Architect Designs.
You’ve got this—now go design like an architect, not like a service catalog.
