AWS offers several ways to run code, and they differ mainly in how much of the stack you manage: with EC2 you run whole virtual machines; with ECS and EKS you run containers on capacity that you or AWS manage; with Lambda you upload a function and AWS handles everything below it. This page covers each model, how it works, its limits and pricing levers, and how to choose between them. Pricing strategy across services is covered in Cost Optimization; network placement (VPCs, subnets, load balancers) in Networking.

Choosing a Compute Option

Moving down the table below, you give up control of the host in exchange for less operational work.

flowchart TD
    A([New workload]) --> B{Event-driven and<br/>under 15 min per run?}
    B -->|Yes| C{Steady high volume?}
    C -->|No, bursty or idle often| L[Lambda]
    C -->|Yes| LMI[Lambda Managed Instances<br/>or containers]
    B -->|No| D{Packaged as a container?}
    D -->|Yes| E{Need Kubernetes APIs<br/>or ecosystem?}
    E -->|Yes| EKS[EKS<br/>Auto Mode or managed node groups]
    E -->|No| F{Need specific hardware,<br/>GPUs, or privileged mode?}
    F -->|No| FG[ECS on Fargate]
    F -->|Yes| ECSEC2[ECS Managed Instances<br/>or ECS on EC2]
    D -->|No| EC2[EC2 with Auto Scaling]

A rough rule: start as far down the stack as the workload allows (Lambda or Fargate), and move to EC2 only when a concrete requirement (hardware, licensing, long-lived connections, sustained utilization that makes per-second serverless pricing expensive) forces it.

Amazon EC2

Amazon Elastic Compute Cloud (EC2) provides virtual machines (“instances”) launched from an Amazon Machine Image (AMI) into a subnet of a VPC. Almost all current instance types run on the AWS Nitro System, which offloads networking, storage, and security to dedicated hardware so that close to all of the host’s CPU and memory goes to the guest. Instances are billed per second (60-second minimum) for Linux while running; attached EBS volumes are billed whether or not the instance is running.

Instance types

An instance type name encodes its family, generation, processor, and extras:

  m  8  g  d . 2xlarge
  │  │  │  │   └── size: vCPU/memory scale (large = 2 vCPU, each step up doubles)
  │  │  │  └────── option: d = local NVMe instance store, n = enhanced networking, e = extra memory/storage
  │  │  └───────── processor: g = AWS Graviton (Arm), i = Intel, a = AMD
  │  └──────────── generation: higher is newer and usually better price-performance
  └─────────────── family: m = general purpose, c = compute, r = memory, ...

Notes on choosing:

• Graviton (Arm) instances usually give the best price-performance for software that runs on arm64 (most Linux distributions, JVM/Go/Python/Node runtimes, containers built multi-arch). Graviton4 powers the 8g families; the Graviton5-based 9g families (M9g, C9g, R9g) are the newest, and AWS quotes up to 25% better compute performance for M9g than M8g.
• Burstable T instances accrue CPU credits below their baseline and spend them above it. T3/T4g default to unlimited mode, which bills for surplus credits: a T instance pinned at high CPU can cost more than an M instance of the same size.
• Instance type availability varies by Region and Availability Zone. Specifying several interchangeable types (see attribute-based selection) avoids capacity errors.

Purchasing options

The same instance can be bought several ways. The discount comes from commitment (Savings Plans, Reserved Instances) or from accepting interruption (Spot).

Savings Plans and Reserved Instances are billing constructs: they do not change how an instance runs, and they apply automatically to matching usage. See Cost Optimization for how to size a commitment.

Spot Instances

Spot Instances use spare EC2 capacity at a steep discount. The trade-off is that EC2 can reclaim the instance when it needs the capacity back. The price itself changes slowly and is rarely the reason for interruption; capacity is.

stateDiagram-v2
    [*] --> Running: capacity available
    Running --> RebalanceRecommended: elevated interruption risk
    RebalanceRecommended --> Running: risk subsides
    RebalanceRecommended --> InterruptionNotice: capacity reclaimed
    Running --> InterruptionNotice: capacity reclaimed
    InterruptionNotice --> Terminated: after 2 minutes (default)
    InterruptionNotice --> Stopped: if interruption behavior = stop
    InterruptionNotice --> Hibernated: if interruption behavior = hibernate
    Terminated --> [*]

Both the rebalance recommendation and the two-minute interruption notice are published to instance metadata and as EventBridge events, so an application or an Auto Scaling group can drain work before the instance disappears.

Practices that make Spot reliable:

• Diversify. Allow many instance types across all AZs. The more capacity pools a workload can use, the less likely it is to be interrupted or unable to launch. Attribute-based instance type selection (specify vCPU and memory ranges instead of type names) does this automatically and picks up new generations.
• Use the price-capacity-optimized allocation strategy, which favors the pools with the most spare capacity and then the lowest price.
• Do not set a maximum price unless you have a specific reason; the default cap is the On-Demand price, and a low cap mostly increases interruptions.
• Launch through Auto Scaling groups, EC2 Fleet, or run-instances. AWS describes the RequestSpotInstances API and Spot Fleet as legacy APIs with no planned investment.
• Make work interruptible: checkpoint long jobs, keep state off the instance, and handle SIGTERM in containers.

# One-off Spot instance through the standard RunInstances API
aws ec2 run-instances \
  --launch-template LaunchTemplateName=batch-worker,Version='$Latest' \
  --instance-market-options 'MarketType=spot,SpotOptions={SpotInstanceType=one-time,InstanceInterruptionBehavior=terminate}'

Good Spot workloads: CI runners, batch and data processing, rendering, stateless web tiers behind a load balancer (mixed with an On-Demand base), and Kubernetes worker nodes managed by Karpenter or EKS Auto Mode.

Operating EC2 instances

# Launch an AL2023 instance with IMDSv2 required and an instance profile, no SSH key
aws ec2 run-instances \
  --image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-arm64 \
  --instance-type t4g.small \
  --subnet-id subnet-0abc1234 \
  --security-group-ids sg-0abc1234 \
  --iam-instance-profile Name=ssm-managed-instance \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-01},{Key=Owner,Value=platform}]'

The resolve:ssm: prefix looks up the latest AMI ID from a public SSM parameter, so scripts do not hard-code Region-specific AMI IDs.

Common EC2 problems

EC2 Auto Scaling

A single instance forces a choice between paying for peak capacity all day or failing at peak. An Auto Scaling group (ASG) removes that choice by keeping a desired capacity of instances across several AZs and changing it in response to demand.

flowchart LR
    CW[CloudWatch metrics<br/>CPU, request count, queue depth] --> P[Scaling policy<br/>target tracking, step,<br/>scheduled, predictive]
    P -->|adjust desired capacity| ASG[Auto Scaling group<br/>min / desired / max<br/>spread across AZs]
    LT[Launch template<br/>AMI, instance types,<br/>role, user data] --> ASG
    ASG -->|launch / terminate| I1[Instance AZ-a]
    ASG --> I2[Instance AZ-b]
    ASG --> I3[Instance AZ-c]
    ALB[Application Load Balancer<br/>target group] --> I1
    ALB --> I2
    ALB --> I3
    ALB -.->|ELB health checks| ASG

Scaling policies

# Keep average CPU near 50% (the group's min/max still bound the result)
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name cpu50 \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
    "TargetValue": 50.0
  }'

Other features worth knowing:

• Mixed instances policy combines an On-Demand base (for example two instances) with Spot above it, across several instance types, in one group.
• Capacity Rebalancing launches a replacement when a Spot instance receives a rebalance recommendation, before the interruption arrives.
• Warm pools keep pre-initialized, stopped instances ready, cutting scale-out time for applications with long boot or warm-up.
• Instance refresh rolls a new launch template version (for example a patched AMI) through the group in batches, with checkpoints and automatic rollback.
• Lifecycle hooks pause instances on launch or termination so scripts can register, drain connections, or ship logs.

AWS Lambda

AWS Lambda runs a function in response to an event (an HTTP request through API Gateway or a function URL, an S3 upload, a message on SQS, a DynamoDB stream record, a schedule) and bills for the requests and the compute time used. There are no instances to manage, and a function with no traffic costs nothing.

Execution model

Each concurrent request is served by an execution environment: a Firecracker microVM with the configured memory, the runtime, and the function code. An environment handles one request at a time and is reused for later requests, so anything created outside the handler (SDK clients, database connections, loaded models) is reused too.

sequenceDiagram
    participant S as Event source
    participant L as Lambda service
    participant E as Execution environment
    S->>L: Invoke
    alt No idle environment (cold start)
        L->>E: Create microVM, download code
        E->>E: INIT: start runtime, run code outside handler
    end
    L->>E: INVOKE: run handler(event, context)
    E-->>L: Response
    L-->>S: Response (sync) or ack (async)
    Note over E: Environment stays warm for reuse;<br/>idle environments are eventually shut down

A cold start is the INIT phase: creating the environment and running initialization code. It typically adds from under 100 ms (small Node.js or Python functions) to several seconds (large Java or .NET applications, heavy dependencies). Since August 2025, time spent in INIT is billed for all on-demand functions, which makes lean initialization a cost concern as well as a latency one.

Concurrency is the number of environments serving requests at once. The default Regional quota is 1,000 concurrent executions (lower on new accounts, raised automatically with usage), and each function can scale by 1,000 environments every 10 seconds. Reserved concurrency caps a function (and guarantees it that share); provisioned concurrency keeps a number of environments initialized ahead of time.

Invocation models

Quotas and limits

Pricing

Lambda charges per request and per GB-second of duration (memory size times execution time, rounded up to the millisecond). arm64 (Graviton) functions are priced about 20% lower per GB-second than x86_64 and usually run as fast or faster. Because CPU is proportional to memory, raising memory often reduces cost for CPU-bound functions by shortening duration; the open-source AWS Lambda Power Tuning tool measures this empirically. Compute Savings Plans apply to Lambda duration.

Reducing cold starts

Scheduled “keep-warm” pings are a legacy workaround: they keep only one environment warm and do nothing for concurrent bursts.

Handler examples

An S3 upload handler. Object keys in S3 events are URL-encoded, so decode them before use:

import urllib.parse
import boto3

s3 = boto3.client("s3")  # created once per environment, reused across invocations

def lambda_handler(event, context):
    for record in event["Records"]:
        bucket = record["s3"]["bucket"]["name"]
        key = urllib.parse.unquote_plus(record["s3"]["object"]["key"])
        body = s3.get_object(Bucket=bucket, Key=key)["Body"]
        for line in body.iter_lines():  # stream; do not read large objects into memory
            process(line)

An HTTP handler behind API Gateway (REST API proxy integration, payload format 1.0):

import json

def lambda_handler(event, context):
    method = event["httpMethod"]
    if method == "GET":
        return {"statusCode": 200, "body": json.dumps({"message": "hello"})}
    if method == "POST":
        data = json.loads(event.get("body") or "{}")
        return {"statusCode": 201, "body": json.dumps({"created": True, "id": data.get("id")})}
    return {"statusCode": 405, "body": ""}

HTTP APIs and function URLs default to payload format 2.0, where the method is at event["requestContext"]["http"]["method"].

Long-running and stateful work

The 15-minute limit and one-request-per-environment model shape how larger jobs are built:

Common Lambda problems

Containers: ECS, Fargate, and EKS

Many teams package applications as containers (see Docker) and hand them to an orchestrator. AWS has two:

• Amazon ECS (Elastic Container Service), AWS’s own orchestrator. Simpler API, deep integration with IAM, ALB, CloudWatch, and Service Connect; no control-plane fee.
• Amazon EKS (Elastic Kubernetes Service), managed Kubernetes. Use it when you want the Kubernetes API, its tooling (Helm, operators, Argo CD), or portability across clouds. EKS charges per cluster-hour for the control plane. See the Kubernetes guide.

ECS concepts

Where containers run

A minimal Fargate task definition. The execution role lets ECS pull the image and write logs; the task role is what the application itself uses to call AWS APIs:

{
  "family": "web-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "runtimePlatform": { "cpuArchitecture": "ARM64", "operatingSystemFamily": "LINUX" },
  "cpu": "256",
  "memory": "512",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::123456789012:role/web-app-task",
  "containerDefinitions": [{
    "name": "web",
    "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/web-app:1.4.2",
    "essential": true,
    "portMappings": [{ "containerPort": 8080 }],
    "logConfiguration": {
      "logDriver": "awslogs",
      "options": {
        "awslogs-group": "/ecs/web-app",
        "awslogs-region": "us-east-1",
        "awslogs-stream-prefix": "web"
      }
    }
  }]
}

Pin images to an immutable tag or digest rather than latest, so a redeploy or task replacement cannot silently pick up a different image.

Service-to-service networking

• ECS Service Connect gives ECS services short names, client-side load balancing, retries, and per-service metrics through a managed Envoy proxy.
• Amazon VPC Lattice connects services across VPCs and accounts, and across compute types (EC2, ECS, EKS, Lambda), with IAM-based auth policies.
• AWS App Mesh reaches end of support on 30 September 2026, after which its console and resources are no longer accessible. AWS directs ECS users to Service Connect, and EKS users to VPC Lattice or an open-source mesh such as Istio.

Other Compute Services

Getting Started Safely

A new account needs a few guardrails before the first instance is launched:

1. Protect the root user. Enable MFA on it, delete any root access keys, and use it only for the handful of tasks that require it.
2. Use federated or short-lived access. Configure IAM Identity Center for human users and sign in to the CLI with aws configure sso / aws sso login, instead of creating IAM users with long-lived access keys. Workloads use IAM roles.
3. Set a budget with email alerts at a low amount (see Cost Optimization).
4. Know the free tier. Accounts created since 15 July 2025 choose a free plan (up to 200 USD in credits over six months, after which the account closes unless upgraded) or a paid plan; some services such as Lambda also have always-free monthly allowances.
5. Launch into private subnets where possible, use Session Manager instead of SSH, and tag every resource with an owner.
6. Clean up. Terminate instances, delete unattached EBS volumes and snapshots, release Elastic IPs, and delete NAT gateways and load balancers when an experiment ends; these keep billing when idle.

See Also

• AWS Hub - Overview of all AWS documentation
• Cost Optimization - Savings Plans, Spot strategy, and budgets
• Storage Services - EBS volumes and S3
• Database Services - RDS, Aurora, and DynamoDB
• Networking & Content Delivery - VPC, load balancers, and CloudFront
• Security - IAM roles and instance hardening
• Architecture Patterns - How compute fits into complete designs
• Kubernetes - Orchestration concepts behind EKS
• Docker - Container fundamentals