Compute

Why This Phase Exists

Compute is where your code actually runs. Every architecture decision you make in this domain determines three things that will follow you for years: your operational model, your cost structure, and your scaling behavior. Choose EC2 and you own the OS, the patching, and the scaling logic. Choose Lambda and you give all of that up in exchange for per-invocation pricing and zero idle cost. Choose containers and you get portability with orchestration complexity.

Most organizations do not pick just one. They run a mix of all three, matched to the workload characteristics of each service. A Solutions Architect who only knows one compute paradigm will design every system the same way. That is how you end up with Lambda functions running for 14 minutes doing batch processing that belongs on a container, or EC2 fleets sitting idle 22 hours a day running cron jobs that should be event-driven functions.

This phase teaches all three paradigms together so you build the judgment to select the right one. You will start with EC2 because it exposes the full stack. You will then learn Lambda, which removes layers you just learned to manage. Finally, you will learn containers, which sit between the two and offer portability that neither EC2 nor Lambda provides alone.

What You Will Master

By the end of Phase 3, you will be able to:

• Launch, configure, and connect to EC2 instances using appropriate instance families and sizes
• Attach, snapshot, and optimize EBS storage for different I/O patterns
• Design Auto Scaling architectures that respond to demand without manual intervention
• Select the right EC2 pricing model based on workload predictability and commitment tolerance
• Build and deploy Lambda functions with proper memory allocation, timeout configuration, and concurrency controls
• Package applications into container images and push them to Amazon ECR
• Define ECS task definitions and services that run reliably behind load balancers
• Deploy and operate Kubernetes workloads on EKS with managed node groups and Fargate profiles
• Make defensible compute selection decisions based on workload characteristics, team capabilities, and cost targets

Modules in This Phase

The Progressive Path

The module ordering in this phase is deliberate. EC2 comes first because virtual machines expose every layer of the compute stack. When you launch an instance, you choose the CPU architecture, allocate memory, attach storage, configure networking, install an operating system, manage security patches, and handle process supervision. That full-stack exposure builds understanding that pays dividends when you move to higher-level abstractions.

Lambda comes next. After spending four modules managing instances, storage, scaling, and pricing, you will immediately feel the contrast. Lambda removes the operating system, the patching, the capacity planning, and the scaling logic. You write a function, define a trigger, and AWS handles everything else. But you can only appreciate what Lambda removes if you first understand what EC2 requires. Students who learn Lambda first never develop intuition for the tradeoffs it makes on their behalf.

Containers close the phase because they represent the middle path. You package your application with its dependencies into an image, which gives you portability that Lambda cannot match. But you still need orchestration, which is where ECS and EKS enter. The orchestration layer handles scheduling, health checking, and scaling, but you retain control over the runtime environment inside the container. Understanding EC2 helps you grasp what the container host is doing. Understanding Lambda helps you appreciate what Fargate does when it removes the host entirely.

Services You Will Command

Amazon EC2

Elastic Compute Cloud is the foundation of AWS compute. EC2 gives you virtual servers with configurable CPU, memory, storage, and networking. You select from hundreds of instance types organized into families optimized for general purpose (M/T), compute-intensive (C), memory-intensive (R/X), storage-intensive (I/D), and accelerated computing (P/G/Inf). You control the operating system through AMIs, inject startup configuration through user data scripts, and query instance identity through the metadata service at 169.254.169.254. Modules 13 through 16 cover EC2 completely, from first launch through production-grade scaling and cost optimization.

Amazon EBS

Elastic Block Store provides persistent block storage volumes for EC2 instances. Unlike instance store (which is ephemeral), EBS volumes persist independently of the instance lifecycle. You will learn four volume types: gp3 for general workloads, io2 for latency-sensitive databases, st1 for throughput-intensive sequential access, and sc1 for infrequent cold data. Module 14 teaches you to create snapshots for backup and migration, enable encryption at rest, and optimize I/O performance by selecting the right volume type and enabling EBS-optimized instances.

EC2 Auto Scaling

Auto Scaling automatically adjusts the number of EC2 instances in response to demand. You define a launch template specifying the instance configuration, create an Auto Scaling Group with minimum, desired, and maximum capacity bounds, and attach scaling policies that react to CloudWatch metrics. Module 15 covers target tracking policies (maintain CPU at 60%), step scaling (add instances in tiers as load increases), and scheduled scaling (pre-warm capacity before known traffic spikes). You will also learn placement groups for controlling how instances are distributed across hardware.

AWS Lambda

Lambda runs your code without provisioning or managing servers. You upload a function (Python, Node.js, Java, Go, .NET, Ruby, or custom runtimes), configure a trigger (API Gateway, S3 events, SQS messages, EventBridge rules), and Lambda executes your code in response to events. You pay only for the compute time consumed, measured in milliseconds. Module 17 teaches the execution model (init, invoke, shutdown), cold start behavior and mitigation strategies, Lambda Layers for shared dependencies, and concurrency controls (reserved concurrency and provisioned concurrency) that prevent runaway invocations from exhausting account limits.

Amazon ECR

Elastic Container Registry is a fully managed Docker container registry. Before you can run containers on ECS or EKS, you need a place to store your container images. ECR provides private repositories with IAM-based access control, image scanning for known vulnerabilities, image tag immutability to prevent overwrites, and lifecycle policies that automatically clean up old images. Module 18 teaches you to build images locally, authenticate to ECR, push images to your repository, and pull them into your orchestration platform.

Amazon ECS

Elastic Container Service is AWS's native container orchestration platform. ECS manages the lifecycle of containers: it schedules tasks onto compute capacity, monitors health, replaces failed containers, and integrates with load balancers for traffic distribution. You define your application as a task definition (container image, CPU, memory, ports, environment variables) and deploy it as a service that maintains your desired count of running tasks. Module 19 covers both EC2 launch type (you manage the underlying instances) and Fargate launch type (AWS manages the infrastructure).

AWS Fargate

Fargate is a serverless compute engine for containers that works with both ECS and EKS. Instead of provisioning and managing EC2 instances to host your containers, Fargate allocates the right amount of compute resources per task. You specify CPU and memory at the task level, and Fargate handles the rest. There are no instances to patch, no cluster capacity to plan, and no idle resources to pay for. Module 19 teaches when Fargate is the right choice (variable workloads, small teams, operational simplicity) versus when EC2 launch type makes more sense (GPU workloads, sustained high usage, specific instance type requirements).

Amazon EKS

Elastic Kubernetes Service runs the Kubernetes control plane as a managed service. If your organization has invested in Kubernetes expertise, EKS lets you bring those skills to AWS without managing etcd, the API server, or the scheduler. You get a managed control plane with automatic upgrades and patching, then choose your data plane: managed node groups (EC2 instances that EKS provisions and updates), self-managed nodes (full control), or Fargate profiles (serverless pods). Module 20 covers EKS cluster creation, node group configuration, Fargate profile setup, and the EKS Anywhere option for running Kubernetes in your own data center with AWS tooling.

The Compute Decision Framework

Solutions Architects get asked the same question constantly: should we use EC2, Lambda, or containers? The answer depends on five factors.

Execution duration. Lambda functions have a 15-minute maximum. If your workload runs longer, Lambda is eliminated immediately. ECS tasks and EC2 instances have no such limit.

Startup latency tolerance. Lambda cold starts add hundreds of milliseconds to initial invocations. If your application requires consistent sub-100ms response times, you need warm compute. EC2 instances and long-running container tasks provide this. Provisioned concurrency on Lambda can mitigate cold starts but adds cost.

State requirements. Lambda functions are stateless by design. If your application needs in-memory state, persistent connections, or local disk beyond 10 GB, containers or EC2 are better fits. Containers can mount EFS for shared persistent storage; EC2 gives you full control over local and network-attached storage.

Operational capacity. A team of two engineers should not operate an EKS cluster. The operational overhead of Kubernetes is significant. Lambda and Fargate trade control for operational simplicity. If your team can invest in platform engineering, EKS delivers flexibility and portability. If your team wants to ship features without managing infrastructure, Lambda or ECS on Fargate removes that burden.

Cost profile. Lambda is cheapest for sporadic, unpredictable traffic with significant idle periods. EC2 with Reserved Instances or Savings Plans is cheapest for sustained, predictable baselines. Spot Instances offer steep discounts for fault-tolerant batch workloads. Fargate sits between Lambda and EC2 on cost, with per-second billing but higher per-unit pricing than equivalent EC2 capacity.

The SA's job is not to pick a favorite. It is to match the workload characteristics to the compute model that minimizes total cost of ownership, which includes engineering time, not just the AWS bill.

Architecture Context

Phase 3 builds directly on the networking and security foundations from earlier phases. Your EC2 instances launch into the VPC subnets you designed in Phase 2. Security groups control which traffic reaches your instances. IAM roles (not access keys) grant your compute resources permission to call other AWS services. The load balancers from earlier modules distribute traffic across your Auto Scaling Groups and ECS services.

Looking ahead, Phase 4 will layer observability and operations onto the compute infrastructure you build here. You will monitor EC2 instances with CloudWatch, trace Lambda invocations with X-Ray, and set alarms that trigger scaling actions. The compute resources you deploy in this phase become the workloads you observe, optimize, and operate in later phases.

Containers and Lambda functions also connect to the storage and database services from Phase 2. Lambda functions read from S3 buckets, write to DynamoDB tables, and publish to SNS topics. ECS services connect to RDS databases in private subnets. Understanding how compute integrates with storage, networking, and security is what separates an SA from someone who just follows tutorials.

Phase Exam

After completing all eight modules, you will take the Phase 3 exam:

• 35 multiple-choice and multiple-select questions
• Covers all compute services, pricing models, scaling strategies, and architectural decisions from this phase
• 70% pass threshold (25/35 correct)
• Timed: 55 minutes
• Questions emphasize the "when and why" of compute selection, not just configuration mechanics