AWS Compute

AWS Compute is not one service. It is a set of execution models. You can rent virtual servers, schedule containers, run functions after events, or submit jobs to a managed queue.

The first decision is not which product name you recognize. The first decision is what you want AWS to operate for you.

Amazon EC2 gives you virtual servers and broad control over the operating system, networking, and storage. That control creates work. You patch the guest operating system, deploy software, protect credentials, monitor capacity, and replace failed instances.

AWS Fargate removes the server fleet from a container workload. AWS Lambda removes server and container orchestration from a function workload. Amazon Lightsail packages common web resources behind a smaller interface. AWS Batch schedules queued work onto suitable compute capacity.

No option removes architecture. You still choose identity, network access, data placement, failure behavior, observability, and cost controls.

Start with the execution unit

The execution unit tells you what the platform starts and scales.

• EC2: an instance, which is a virtual server created from an Amazon Machine Image.
• Amazon ECS: a task, which runs one or more containers from a task definition.
• Amazon EKS: a Kubernetes pod, scheduled through a managed Kubernetes control plane.
• Fargate: serverless capacity for ECS tasks or EKS pods.
• Lambda: a function invocation triggered by an event or API call.
• AWS Batch: a queued job placed onto EC2 or Fargate capacity through managed orchestration.
• Lightsail: a bundled instance or container service for a smaller, simpler web workload.

Use the smallest execution unit that matches the application. A long-running operating system service fits an instance. A packaged application with several processes often fits a container. A short event handler often fits a function. A finite, queueable computation fits a batch job.

EC2 is the control-rich baseline

An EC2 instance is a virtual server. An Amazon Machine Image, or AMI, defines its starting operating system and software. The instance type determines its compute, memory, networking, storage, and accelerator characteristics.

Storage has different lifetimes. Amazon EBS provides persistent block volumes. Instance store provides temporary storage tied to the host and instance lifecycle. Put durable state in a service whose failure behavior matches the workload. Do not treat one instance or its temporary disk as a durable system.

A security group controls allowed network traffic for an instance or network interface. It is not a substitute for application authentication or guest operating system hardening.

Choose EC2 when you need operating system access, a specific instance family, specialized hardware, a legacy runtime, or control over host-level configuration. Avoid it when the application does not justify image maintenance, patching, capacity management, and fleet operations.

A fleet is a system, not a pile of instances

One instance is one failure domain. Production services usually need repeatable instances and replacement behavior.

An EC2 launch template records how instances start. An Auto Scaling group sets minimum, desired, and maximum capacity. It monitors health, replaces impaired instances, and can adjust capacity through scaling policies. A group can spread capacity across several Availability Zones.

Elastic Load Balancing sends incoming traffic to healthy registered targets. The target can be an EC2 instance, a container, or an IP address. Auto Scaling changes how many targets exist. Load balancing changes where traffic goes. You often use both, but they solve different problems.

Scaling does not repair an application that stores session state on one instance. Design instances to be replaceable. Move shared state to an appropriate storage or database service. Test deployment, scale-in, and failure paths before traffic tests them for you.

Containers split orchestration from capacity

Amazon ECS is AWS-native container orchestration. Amazon EKS provides managed Kubernetes. Both decide where containerized work should run and keep the requested workload state.

Then choose capacity:

• Use EC2 capacity when you need specific instance types, accelerators, host access, custom images, or detailed control over fleet economics.
• Use Fargate when you want to specify container CPU, memory, networking, and IAM without managing the underlying instances.

ECS is a direct choice when you want AWS-native orchestration and do not need the Kubernetes API or ecosystem. EKS is appropriate when Kubernetes compatibility, Kubernetes tooling, or an existing Kubernetes operating model is a requirement. Managed Kubernetes still leaves work around workloads, policies, networking, upgrades, and observability.

Functions and jobs solve different timing problems

Lambda runs code after an event or API call. AWS manages the underlying infrastructure, capacity, scaling, and patching. Each function invocation should be treated as independent. Use external services for durable state.

Lambda fits event handlers, API operations, automation, and data transformations that fit its execution model. A continuously running service, a workload that needs host control, or a process with unsuitable runtime constraints belongs elsewhere.

AWS Batch fits finite work that can wait in a queue. You submit jobs and AWS Batch provisions and schedules EC2 or Fargate resources according to the compute environment. Batch is not an online request router. It is a throughput-oriented scheduler for queued work.

Cost follows the allocation model

Every execution model exposes a different billing unit.

EC2 charges for allocated instances and related resources. On-Demand Instances avoid a long-term commitment. Savings Plans exchange a usage commitment for lower eligible compute prices. Reserved Instances apply to a more specific EC2 configuration commitment. Spot Instances use spare capacity at a discount but can be interrupted.

Spot is a workload property, not only a purchase option. The application must tolerate interruption and retry work. AWS provides an interruption notice on a best-effort basis, normally two minutes before stop or termination.

Fargate charges for requested task resources over time. Lambda uses request and execution resource dimensions. Batch charges through the resources that jobs consume. Lightsail uses bundles with predictable monthly prices.

Compare the whole system. Include idle capacity, storage, data transfer, load balancers, logs, support services, and the engineering time required to operate it.

Security responsibility moves with the service

AWS secures the underlying cloud infrastructure. Your responsibility changes with the compute choice.

With EC2, you manage network access, credentials, guest operating system updates, application software, and the attached IAM role. With Fargate, AWS provisions and patches the compute infrastructure. You still own container images, task permissions, network configuration, encryption choices, and application behavior.

Use an IAM role for the workload. Do not place long-term AWS credentials in an AMI, container image, function package, or user-data script. Restrict network paths and permissions to what the workload needs.

Operate the signals that drive decisions

Amazon CloudWatch collects metrics, logs, dashboards, and alarms for AWS resources and applications. Those signals support health checks, scaling policies, incident response, and capacity decisions.

Watch both platform and application behavior. CPU use alone may not describe queue delay, request latency, error rate, memory pressure, or dependency saturation. Choose a scaling signal that represents the constraint users feel.

The durable mental model is a responsibility ladder. EC2 gives you the most host control and host work. Managed containers remove control-plane or fleet work. Lambda narrows the execution model and removes more infrastructure work. Batch and Lightsail package common operating patterns. Move up the ladder only when its constraints fit the workload.