1 AWS Compute Foundations and Service Selection

Understand the compute choices

AWS compute services differ in the level of control customers have over machines or runtimes, how infrastructure is managed, and how capacity scales. Choose based on the workload, infrastructure requirements, scaling needs, and acceptable operations work.

Compare the main services

Amazon EC2 provides virtual machines called instances. Customers select the instance type and manage the operating system, patches, and application environment. EC2 can suit applications requiring OS-level control, specialized hardware, or a continuously running server. EC2 Auto Scaling can adjust instance capacity.

AWS Lambda runs functions in response to events or requests. AWS manages the underlying servers and scales execution capacity. Standard Lambda function invocations are designed for short-lived, stateless work and can run for up to 15 minutes, making Lambda a candidate for event processing, scheduled tasks, and APIs with variable or intermittent traffic.

Amazon ECS orchestrates containers. Tasks can run on EC2 instances when more host control is needed, or on Fargate to avoid managing servers. Amazon EKS orchestrates containers with Kubernetes: AWS manages the Kubernetes control plane, while customers select and operate compute capacity, such as EC2 or Fargate. EKS can fit workloads that need Kubernetes APIs, tools, or portability.

AWS Fargate supplies managed server capacity for containers launched through ECS or EKS. Customers specify task or pod resources, and Fargate manages the underlying server capacity. Fargate is a compute option, not a container orchestrator by itself; it can support long-running services or jobs packaged as containers without requiring customers to manage EC2 hosts.

Other services address more specialized needs. AWS Batch schedules large-scale batch jobs. Elastic Beanstalk simplifies deploying web applications while retaining access to the underlying AWS resources. App Runner provides a managed way to build and run containerized web applications. Multiple compute services can be combined within one workload.

Separate container roles

A container image packages application code and its dependencies so an application can run consistently in different environments. Amazon ECR stores container images. Amazon ECS and Amazon EKS decide where containers run and manage their lifecycle; Amazon EC2 or AWS Fargate supplies the capacity on which they run.

For example, a web service could store its image in ECR, deploy it as an ECS service, and run its tasks on Fargate. This separates image storage, orchestration, and compute capacity.

Plan for Regions and availability

A Region is a separate geographic area. Each Region contains multiple isolated Availability Zones, which are separate locations connected by low-latency networking. A resource created in one Region is generally regional; AWS does not automatically replicate every resource to another Region.

To improve availability within a Region, design for multiple Availability Zones. For example, an EC2 Auto Scaling group can span zones, or a service can run capacity in more than one zone. Multi-zone placement is a design choice, not automatic cross-Region replication.

Evaluate cost and capacity

There is no universally cheapest compute service. Cost depends on resource size, runtime, traffic pattern, storage, data transfer, and other services used.

• EC2: On-Demand instances are charged for running instance time. Spot and commitment-based discounts may fit workloads with appropriate flexibility or predictable usage. Related resources, such as storage and data transfer, also contribute to cost.

• Lambda: Standard functions are priced by requests and execution duration, with allocated memory affecting compute use. This can suit intermittent work, but sustained or high-volume usage should be evaluated against other options.

• Containers on Fargate: Compute charges are based on the resources and runtime requested for tasks.

• Containers on EC2: With ECS or EKS on EC2, customers pay for the underlying instances and related resources; orchestration does not remove the cost of that capacity.

Use AWS Pricing tools to estimate a specific design and review current pricing for the selected Region and services.

Distinguish scaling from availability

Scaling can mean adding capacity, or scale out, or increasing the resources of an individual unit, or scaling up. EC2 Auto Scaling can add or remove instances according to policies and can distribute an Auto Scaling group across Availability Zones. Lambda scales execution capacity for incoming invocations, subject to service quotas.

Container services scale tasks or pods, but the underlying capacity must also be available unless using a managed option such as Fargate. Scaling is not the same as high availability: the application must also be designed to tolerate failures, including failures of an Availability Zone.

Apply shared responsibility

AWS is responsible for security of the cloud, including physical facilities and underlying infrastructure. Customers remain responsible for security in the cloud, including application code, data, identity permissions, and service configuration.

The division depends on the service. With EC2, customers also manage the guest operating system and its patches. With Fargate or Lambda, AWS manages more of the underlying compute infrastructure, but customers still secure their code, data, permissions, and configuration.

Choose by workload requirements

Use workload requirements to narrow the choice:

1. Host, operating system, or hardware requirements: Start with EC2 when a workload requires a particular operating system, host configuration, or hardware. For containers requiring host control, consider ECS or EKS on EC2.

2. Container packaging and orchestration: For an application already packaged as a container, choose ECS for AWS-native orchestration or EKS when Kubernetes is required. Choose Fargate to avoid managing container hosts; choose EC2 when host-level control or capacity optimization matters more.

3. Short event-driven work: Consider Lambda when work happens in response to events and finishes quickly, such as resizing an uploaded image or processing a queue message.

4. Large collections of jobs: Consider AWS Batch for large collections of scheduled or queued jobs; it can schedule batch workloads across AWS compute options.

5. Operations capacity: More control generally means more responsibility for provisioning, patching, capacity, and scaling. Managed services reduce that burden but can impose different limits and configuration choices.

Examples illustrate these fits: a legacy application needing a custom operating-system package may fit EC2; a stateless function handling an object-storage upload may fit Lambda; a long-running service distributed as a Docker image may fit ECS on Fargate, or EKS if Kubernetes is required. A scientific workload that can tolerate interruptions may use Batch with eligible Spot capacity.

Bring the choices together

Amazon EC2 provides virtual machines and the most direct control over hosts. AWS Lambda runs short-lived functions in response to events without requiring customers to manage servers. Amazon ECS and Amazon EKS orchestrate containers; AWS Fargate supplies managed container compute, while EC2 supplies customer-managed host capacity.

Make the selection based on workload shape, operational responsibility, scaling needs, regional availability, and total cost—not on the service name alone.