Compute architecture35 min5 exam topics

Choose where your code should run

Decide whether a workload needs a virtual machine, container, or function—then separate container orchestration from the compute capacity underneath it.

LESSON GOALS

By the end, you can

Decide whether a workload needs a virtual machine, container, or function from its execution and host requirements.
Separate a container image, its orchestrator, and its capacity before choosing ECS, EKS, Fargate, or EC2.

Start with the program—not the product

Ask three questions before naming an AWS service. How does the program start: one event, a long-running process, or an operating-system service? How long does it run? Does it need a particular kernel, device, filesystem, network port, or licence tied to a host?

A virtual machine gives you an operating system and host-level control. Amazon EC2 is the AWS virtual-machine service. Choose it when the program needs a custom kernel module, special device, legacy installer, or another assumption that a managed runtime cannot provide.

A container packages a process and its dependencies as an image. A function packages code around short, event-driven invocations. Packaging alone does not create replicas, move state out of the process, or survive an Availability Zone failure.

For migration, list every process, file, session, secret, port, and dependency. Move durable state and secrets outside the compute unit. If that change is impossible, rehost on EC2 rather than hiding a machine-dependent application inside a fragile container.

A container still needs two more choices

A container image answers, “What should run?” An orchestrator answers, “How many copies should exist, where should they run, and how should they be replaced?” Amazon ECS and Amazon EKS are orchestrators.

Amazon ECS is AWS-native container orchestration. Amazon EKS provides a managed Kubernetes control plane. Choose EKS when Kubernetes APIs, controllers, or ecosystem compatibility are actual requirements—not because Kubernetes sounds more advanced.

Capacity answers, “Which compute runs the containers?” AWS Fargate supplies managed capacity without you operating EC2 worker hosts. EC2 capacity gives you control over instance type, GPU, custom machine image, privileged behavior, and host economics.

AWS Lambda is different from both. It runs invocation-oriented functions rather than acting as a container orchestrator. It can scale execution environments, but runtime, concurrency, networking, and downstream limits still decide whether it fits.

Choose the smallest boundary that satisfies the hard need

Prefer the candidate that satisfies every hard requirement with the least unnecessary operating work. A short event handler may fit Lambda. A normal container service with no Kubernetes or host requirement may fit ECS on Fargate. A GPU container with a custom kernel module needs compatible EC2 capacity.

Availability is a separate decision. Run replaceable services as multiple healthy units across the required failure domains. Keep durable state elsewhere, distribute traffic or events, and test draining, replacement, and rollback.

Compare cost only after capability, security, resilience, and performance fit. Fargate can remove host operations; EC2 can be economical or necessary for steady specialised capacity. A cheaper option that cannot expose the required GPU or kernel feature is not a valid option.

A migration can also be staged. Rehost the unchanged machine first when time or compatibility decides, then externalise state and package the process after behavior is stable. Do not call the later container move successful until replacement, shutdown, logging, secrets, and rollback are observable.

DECISION TABLE

Compare the architecture constraints

requirement	choose	because	reject
Short stateless event handler with bounded execution	Lambda	Invocation model and minimal host operations fit	EC2 service and EKS add unneeded work
Container service; no Kubernetes or host-control requirement	ECS on Fargate	ECS schedules while Fargate supplies managed capacity	EKS adds Kubernetes burden; EC2 adds host management
Container requires GPU and custom kernel module	ECS on EC2	The workload needs selectable instances and host control	Fargate and Lambda cannot satisfy the host capability
Kubernetes APIs and controllers are contractual	EKS	The explicit Kubernetes ecosystem requirement decides	ECS does not expose the Kubernetes control model

GUIDED WORKED SCENARIO

Reason from the stated constraints

This is a guided example, not a question to memorise. The knowledge check uses new situations to test the same reasoning.

A company must migrate a stateless HTTPS API and a nightly GPU model-training job. The API is containerized; the GPU job needs a vendor kernel module. The team has no Kubernetes requirement and must survive one instance failure.

Requirements

Run three API replicas across two AZs
Use the existing API image with minimal host operations
Provide a GPU and custom kernel module to the six-hour nightly job
Keep durable outputs in S3 and credentials out of images

Reasoning path

Classify the API and batch job separately.
Select ECS because desired-state container orchestration is required but Kubernetes is not.
Place the API on Fargate across two AZs and the GPU task on ECS EC2 GPU capacity.
Externalize outputs and secrets; add health checks, draining, and replacement.

Recommended architectureECS for both workloads, using Fargate for the stateless API and a GPU EC2 capacity provider for the kernel-dependent task.

Why it wins

One orchestrator manages both images while each gets the capacity contract it needs.
Multi-AZ API replicas and external state survive instance loss.

Why the alternatives lose

EKS with a compatible EC2 GPU node group

It can satisfy the GPU host requirement but adds Kubernetes operations when no Kubernetes contract exists.

Becomes correct when: Kubernetes APIs and operators are mandatory and the EKS EC2 node group supports the vendor GPU and kernel module.

Lambda for both workloads

The long GPU container and custom host dependency do not fit the function model.

Becomes correct when: Work becomes short stateless event code within current limits and needs no special host.

ECS entirely on EC2

It meets capability but makes the API team manage hosts unnecessarily.

Becomes correct when: Host control or measured steady-state economics justify EC2 for all tasks.

ARCHITECTURE VISUAL · TEXT MODE

Inspect the model

Decision tree: choose function, container, or virtual machine. For a container, choose ECS or EKS as orchestrator and then Fargate or EC2 as capacity. The GPU kernel requirement is the first gate that eliminates Fargate.

KNOWLEDGE CHECK

Answer one question at a time

Pass every question to complete this lesson. Each answer includes reasoning before you continue.

KEY TERMS

Glossary

Virtual machine (VM): A software-defined computer with its own operating system; Amazon EC2 provides this boundary.
Container: A packaged process and its dependencies, represented by an image.
Container image: The immutable package used to start one or more container tasks or pods.
Orchestrator: A system that places, replaces, scales, and rolls out containers, such as ECS or EKS.
Capacity: The compute resources underneath an orchestrator, such as Fargate or EC2 instances.
AWS Fargate: Managed container capacity for ECS or EKS that removes customer management of worker hosts.
AWS Lambda: An event-driven function service that runs bounded invocations on managed infrastructure.
Host control: Access to choose or configure the operating system, kernel, devices, or instance.
Stateless compute: Compute that can be replaced without losing hidden local business state.
Task role: An IAM role whose temporary permissions are supplied to an ECS task.

PRIMARY SOURCES

Verify the claims