Cloud / Amazon EC2 (Elastic Compute Cloud) Interview questions

Amazon EC2 (Elastic Compute Cloud) is a web service that provides resizable virtual compute capacity in the AWS cloud, letting you launch virtual servers called instances instead of buying and racking physical hardware.

You choose an instance's CPU, memory, storage, and networking capacity through an instance type, boot it from a preconfigured Amazon Machine Image (AMI), and pay only for the compute time you actually use.

Because EC2 sits inside a VPC, you also control networking details like subnets, security groups, and IP addressing, which makes it possible to run anything from a single test server to a large fleet behind a load balancer.

EC2 instance types are grouped into families that are each optimized for a different resource profile, and you pick the family and size that best match your workload's CPU, memory, storage, or networking needs.

The main families are:

Within each family, the size (like large or 2xlarge) scales vCPUs, memory, and network bandwidth up together, so picking a type is really a two-step choice: family for the workload shape, then size for the raw capacity you need.

An AMI is a template that packages everything an EC2 instance needs to boot: an operating system, any pre-installed software, and a block device mapping describing which volumes to attach, plus launch permissions controlling who can use it.

When you launch an instance, EC2 copies the AMI onto a fresh root volume, so the same AMI can be used to launch one instance or thousands of identical ones.

AMIs can be provided by AWS, published by third parties in the AWS Marketplace, or created by you from an existing instance or snapshot, which is the usual way teams "bake" a golden image with their own patches and agents already installed.

EC2 offers several purchasing options that trade flexibility for cost savings, so the right model depends on how predictable and interruptible your workload is.

Most production accounts blend these: a Savings Plan or Reserved Instances covering the steady baseline load, Spot for batch or stateless work, and On-Demand for burst capacity.

An EC2 instance moves through a defined set of lifecycle states that you can see in the console or via describe-instances.

1. pending - the instance is launching
2. running - the instance is up and billable for compute
3. stopping - a stop was requested (EBS-backed only)
4. stopped - the instance is off; EBS volumes persist but compute isn't billed
5. shutting-down - termination was requested
6. terminated - the instance is permanently deleted

Instance-store-backed instances skip stopping/stopped entirely, since without a persistent root volume there's nothing to preserve, so for them a "stop" is effectively a terminate.

Launching an instance means choosing an AMI, an instance type, a network (VPC/subnet), a security group, a key pair, and storage, then submitting the request through the console, CLI, SDK, or infrastructure-as-code.

Using the AWS CLI, a minimal launch looks like:

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --key-name my-key \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0

EC2 validates the request, allocates capacity, attaches the requested networking and storage, and moves the instance into the pending then running state, at which point it's reachable per your security group rules and route table.

A security group is a virtual, stateful firewall attached to an instance's network interface that controls inbound and outbound traffic using allow rules only - there are no explicit "deny" rules.

Because it's stateful, a response to an allowed inbound request is automatically allowed back out, so you don't need a matching outbound rule for reply traffic.

An instance can belong to multiple security groups at once, and the rules across all of them are combined (unioned), which lets you compose access from smaller, reusable groups such as "web-tier" and "ssh-admins" rather than one giant rule set per instance.

A key pair is used for secure, passwordless authentication to a Linux instance (or to decrypt the administrator password on Windows) instead of relying on a static password.

AWS stores the public key on the instance at launch (in ~/.ssh/authorized_keys for Linux), while you keep the private key (.pem file) locally; only someone holding the matching private key can complete the SSH handshake.

Because AWS never keeps a copy of the private key after you download it, losing it means you can't SSH in with that pair anymore, though you can typically detach the root volume, attach it to another instance, and add a new key manually.

Amazon EBS (Elastic Block Store) provides persistent, network-attached block storage volumes that you attach to EC2 instances, similar to a virtual hard drive.

Unlike the ephemeral instance store, EBS volumes exist independently of the instance's life: data survives a stop/start cycle, and a volume can be detached from one instance and reattached to another.

Each volume is automatically replicated within its Availability Zone for durability, and you can take point-in-time snapshots to Amazon S3 for backup or to create new volumes/AMIs elsewhere.

EBS offers several volume types split into SSD-backed (for IOPS-intensive or general workloads) and HDD-backed (for throughput-intensive, large sequential workloads).

gp3 is the modern default for most workloads since, unlike its predecessor gp2, its IOPS and throughput are billed and configured separately from size, so you're not forced to over-provision storage just to get more performance.

An Elastic IP (EIP) is a static, public IPv4 address that you allocate to your AWS account and associate with an instance or network interface, so it doesn't change if you stop and start the instance the way an auto-assigned public IP would.

You can quickly remap an EIP from one instance to another, which is useful for masking an instance failure - you launch a replacement and reassociate the same address without updating DNS.

AWS charges a small hourly fee for an EIP that is allocated but not associated with a running instance, to discourage hoarding a limited public IPv4 resource.

A VPC (Virtual Private Cloud) is the isolated, software-defined network that every EC2 instance launches into, giving you control over IP address ranges, subnets, route tables, and gateways.

Placing an instance in a public subnet (with a route to an internet gateway) versus a private subnet (routed only internally, or out through a NAT gateway) determines whether it's directly internet-reachable.

Because security groups and network ACLs are VPC constructs, the VPC is really the security and connectivity boundary within which every other EC2 networking decision, from subnetting to peering, gets made.

User data is a script or cloud-init directive you pass at launch time that the instance runs automatically once during its first boot, commonly used to install packages, pull configuration, or register the instance with a service.

A simple Bash example:

#!/bin/bash
yum update -y
yum install -y httpd
systemctl enable httpd
systemctl start httpd

User data is not a substitute for a golden AMI when startup logic gets complex or slow, since it runs fresh on every launch; teams often combine a pre-baked AMI with a small user data script for environment-specific setup.

A placement group is a logical grouping that influences how AWS physically places a set of instances on underlying hardware, to either maximize network performance or spread instances for fault tolerance, depending on the strategy you choose.

You create the placement group first, then launch instances into it; you can't move an already-running instance into a placement group after the fact.

Placement groups matter most for workloads sensitive to network latency (like HPC or tightly coupled clustered applications) or workloads that need explicit hardware-failure isolation.

EC2 supports three placement group strategies, each solving a different problem:

1. Cluster - packs instances close together in a single Availability Zone for the lowest network latency and highest throughput, ideal for HPC.
2. Spread - spreads a small number of instances across distinct underlying hardware to minimize correlated hardware failures, good for a handful of critical instances.
3. Partition - divides instances into logical partitions that don't share underlying hardware, used by distributed systems like Hadoop or Cassandra that already handle their own replication across partitions.

Picking the wrong strategy is a common mistake: Cluster trades fault isolation for speed, while Spread and Partition trade some placement efficiency for resilience.

On-Demand instances are billed per second with no upfront commitment, so you pay a premium for the freedom to start and stop capacity at any time.

Reserved Instances (RIs) commit you to a specific instance family/region (or a Convertible RI that can change family) for a 1- or 3-year term, in exchange for a discount of up to roughly 70% versus On-Demand.

The trade-off is straightforward: RIs make sense once you can confidently predict a steady baseline of usage, while On-Demand suits spiky or unpredictable capacity.

On-Demand guarantees capacity at a fixed hourly rate for as long as you keep the instance running. Spot Instances use AWS's spare capacity at up to ~90% off, but AWS can reclaim that capacity with a two-minute interruption warning when it's needed elsewhere.

Spot pricing fluctuates with supply and demand, so cost savings come with the risk of interruption, meaning workloads must tolerate being stopped or terminated unexpectedly.

This makes Spot best for stateless, fault-tolerant, or checkpointable work like batch processing, CI jobs, or rendering, while On-Demand (or Reserved) suits anything that must run continuously without interruption, like a primary database.

An Auto Scaling group (ASG) maintains a fleet of instances within a minimum, maximum, and desired capacity, launching new instances from a launch template and terminating ones that fail health checks or are no longer needed.

Scaling is driven by policies: target tracking (keep a metric like CPU near a target), step scaling (add/remove capacity in steps based on alarm thresholds), or scheduled actions for predictable patterns.

flowchart LR
A["CloudWatch metric crosses threshold"] --> B["Scaling policy triggers"]
B --> C{Scale out or in?}
C -->|Out| D["Launch instances from launch template"]
C -->|In| E["Terminate selected instances"]
D --> F["Register with load balancer"]
E --> G["Deregister from load balancer"]

Because the ASG continuously replaces unhealthy instances too, it doubles as a self-healing mechanism, not just a capacity-matching one.

HPC and tightly coupled workloads (like MPI-based simulations) are sensitive to inter-node network latency and bandwidth, since nodes constantly exchange data during a computation.

A Cluster placement group packs instances onto hardware that's physically close within a single Availability Zone, minimizing hop count and maximizing throughput between them, often unlocking full bisection bandwidth on supported instance types.

The trade-off is reduced fault isolation, since instances share the same underlying hardware pool, so a hardware failure has a higher chance of affecting multiple instances in the group at once, which is acceptable for HPC jobs designed to checkpoint and restart.

Stopping an EBS-backed instance shuts it down but keeps its EBS volumes, so you can start it again later with the same data and (if not using an Elastic IP) it usually gets a new public IP.

Terminating permanently deletes the instance; by default the root EBS volume is deleted too (controlled by its "delete on termination" flag), while any additional non-root volumes with that flag unset survive.

A good mental model: stop is a pause button, terminate is a delete button.

Spot Instances make sense whenever a workload can tolerate interruption and doesn't need guaranteed continuous availability, since the savings, often 70-90% off On-Demand, only pay off if you can absorb reclamation gracefully.

• Batch processing and data pipelines that checkpoint progress
• CI/CD build and test runners
• Stateless web tiers behind an Auto Scaling group mixing Spot with On-Demand
• Big data and rendering jobs distributed across many nodes

Spot is a poor fit for anything stateful without built-in redundancy, like a single primary database instance, since a two-minute interruption warning isn't enough time to safely migrate live state without a pre-built failover plan.

An Elastic Load Balancer sits in front of a fleet of instances, accepts incoming connections, and distributes them across healthy targets registered in one or more target groups, based on a routing algorithm (like round robin or least outstanding requests) and continuous health checks.

If a target fails its configured health check, the ELB stops sending it new traffic until it passes again, which lets Auto Scaling replace unhealthy instances without user-facing downtime.

Because the ELB itself scales automatically and spans multiple Availability Zones, it also removes the single point of failure that a lone instance handling all traffic would represent.

An Application Load Balancer (ALB) operates at Layer 7 (HTTP/HTTPS), so it can route based on URL path, host header, or headers, and supports features like WebSockets and native container/Lambda targets.

A Network Load Balancer (NLB) operates at Layer 4 (TCP/UDP/TLS), handling millions of requests per second with ultra-low latency and a static IP per Availability Zone, but without visibility into HTTP content.

Choose an ALB for typical web applications needing content-based routing, and an NLB for extreme performance, static IP requirements, or non-HTTP protocols.

The standard way is SSH using the private key that matches the key pair specified at launch:

ssh -i my-key.pem ec2-user@<public-ip-or-dns>

This requires the instance to have a public IP (or you connecting through a bastion/VPN into the VPC), and a security group rule allowing inbound TCP 22 from your IP.

For environments that want to avoid managing SSH keys and open port 22 at all, AWS Systems Manager Session Manager lets you connect through the console or CLI over the SSM agent, using IAM permissions instead of network-level SSH access, which many security teams now prefer.

An IAM role attached to an instance (via an instance profile) provides temporary, automatically rotated credentials through the instance metadata service, so applications can call AWS APIs without any access key ever being written to disk.

Hardcoded or file-stored long-term credentials are a common source of leaks, since they can end up in logs, backups, source control, or an AMI, and they don't expire on their own if compromised.

Because role-based credentials are short-lived and scoped by an IAM policy to only the actions the instance actually needs, the blast radius of a compromised instance is far smaller than if it held a broadly-permissioned static key.

An EBS-backed AMI boots from a durable EBS volume; the instance can be stopped and started, and its root volume persists independently of the instance.

An instance-store-backed AMI boots from ephemeral storage physically attached to the host; there is no stop/start capability, data on that volume is lost on termination, and the AMI itself is stored in S3 rather than as an EBS snapshot.

Nearly all modern AMIs, including every default AWS-provided one, are EBS-backed, since instance-store root volumes are now a legacy option mainly seen on a handful of storage-optimized instance types.

From the console or CLI, you select the running (or stopped) instance and create an image, which triggers EC2 to take snapshots of its attached EBS volumes and register a new AMI referencing them.

aws ec2 create-image \
  --instance-id i-0123456789abcdef0 \
  --name "my-app-golden-2026-09-22" \
  --no-reboot

By default EC2 reboots the instance briefly to ensure filesystem consistency before snapshotting; passing --no-reboot skips that but risks capturing data mid-write, so it's only safe when the application can tolerate a crash-consistent (not clean) snapshot.

Once registered, the AMI can be shared with other accounts, copied to other Regions, or used directly in a launch template so future instances start pre-configured.

A Region is a separate geographic area (like us-east-1) containing multiple, isolated data centers grouped into Availability Zones (AZs), each with independent power, cooling, and networking but connected to other AZs in the same Region by low-latency links.

EC2 instances, subnets, and most resources live inside one AZ; you achieve high availability by spreading instances across multiple AZs within a Region, not by spanning Regions for a single application.

Crossing Regions is a separate, larger decision, used for disaster recovery, data residency requirements, or serving users with lower latency worldwide, since Regions are fully isolated and don't share most resources like VPCs or security groups by default.

EC2 automatically publishes basic metrics (CPU utilization, network in/out, disk I/O, status checks) to CloudWatch every 5 minutes by default, or every minute if detailed monitoring is enabled.

Metrics that require visibility inside the OS, like memory or disk-space utilization, aren't published automatically; they need the CloudWatch agent installed on the instance to collect and push them.

You can graph these metrics, set alarms that trigger notifications or Auto Scaling actions when a threshold is breached, and centralize instance logs by having the same agent stream them to CloudWatch Logs.

Instance metadata is data about the running instance itself, like its instance ID, AMI, IP addresses, and IAM role credentials, available from inside the instance via a link-local address, not over the internet.

With IMDSv2 (the current recommended version), you must first request a session token, then use it to read metadata:

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id

Applications commonly use this endpoint to fetch temporary IAM role credentials automatically, rather than embedding any secrets in code or configuration.

IMDSv1 answers plain GET requests to the metadata endpoint with no session or token, which made it vulnerable to server-side request forgery (SSRF) attacks: a vulnerable web app could be tricked into proxying a request to the metadata endpoint and leaking the instance's IAM role credentials.

IMDSv2 requires a session-oriented PUT request first to obtain a token, and rejects the common SSRF pattern because most SSRF vulnerabilities can forward GET requests but can't easily set custom headers or issue a PUT, closing off that attack path.

AWS lets you enforce IMDSv2-only access at the instance or account level (via the HttpTokens: required launch parameter), and many security baselines now require it everywhere.

A Dedicated Host is a physical server fully allocated to your account, giving you visibility into and control over which sockets and physical cores your instances land on, useful for licensing software that's billed per-core or per-socket.

A Dedicated Instance also runs on hardware dedicated to a single account, but you don't get that host-level visibility or control over placement, and different Dedicated Instances for the same account may still land on different physical servers.

Choose a Dedicated Host when license terms require tracking physical cores or sockets, and a Dedicated Instance when you just need hardware isolation without that extra bookkeeping.

An EBS snapshot is a point-in-time, incremental backup of a single volume stored in S3; it captures block-level data but has no concept of an operating system or launch configuration.

An AMI is a launchable template that references one or more snapshots (for the root and any additional volumes) plus metadata like architecture, virtualization type, and block device mappings needed to actually boot an instance.

In short, every AMI is backed by snapshots, but a snapshot alone isn't directly launchable - you'd need to create a volume from it, attach it to an instance, or register it as part of a new AMI first.

A Reserved Instance (RI) makes sense when you know the exact instance family and Region you'll run for the full term and want the option of an RI marketplace to resell unused capacity, or need zonal capacity reservation guaranteed in a specific AZ.

Standard RIs also allow reselling on the AWS Marketplace if your needs change, an option Savings Plans don't offer, and some organizations already have RI-based cost governance tooling built around them.

In most other cases, a Compute Savings Plan is more flexible since its discount automatically applies across instance families, sizes, and Regions, so teams migrating architectures or unsure of exact future instance types generally prefer it.

You can't hot-swap the instance type of a running instance; you must stop it, use modify-instance-attribute (or the console) to change the type, and start it again.

On stop and start, EC2 typically migrates the instance to different underlying hardware compatible with the new type, and the instance may receive a new public IP unless it has an Elastic IP.

Resizing can fail if the new type isn't compatible with the current virtualization type, root volume type, or network setup (for example, moving to an instance type requiring ENA-enabled networking without that driver present), so it's worth checking compatibility before attempting it in production.

An instance's lifecycle begins the moment you submit a launch request and ends only at termination, moving through distinct states that reflect both its compute status and billing behavior.

stateDiagram-v2
[*] --> Pending
Pending --> Running
Running --> Stopping: stop requested
Stopping --> Stopped
Stopped --> Pending: start requested
Running --> ShuttingDown: terminate requested
Stopped --> ShuttingDown: terminate requested
ShuttingDown --> Terminated
Terminated --> [*]

While running, an instance is billed for compute per second; moving to stopped halts compute billing but EBS storage charges continue, and only terminated stops storage billing too (unless volumes were set to survive termination).

Each transition can also trigger automation: Auto Scaling lifecycle hooks can pause an instance in a wait state during launch or termination, EventBridge can react to state changes, and user data only ever runs on the very first boot after launch, not on every subsequent start.

When you submit a launch request, EC2's control plane validates the parameters (AMI, instance type, network, IAM role), reserves capacity on a physical host, and attaches the requested ENIs and EBS volumes before powering on the virtual machine.

sequenceDiagram
participant You
participant EC2 API
participant Host
participant Instance
You->>EC2 API: RunInstances request
EC2 API->>Host: Allocate capacity, attach ENI/EBS
Host->>Instance: Power on VM
Instance->>Instance: Boot OS, cloud-init runs
Instance->>Instance: Fetch and execute user data
Instance-->>EC2 API: Status checks pass
EC2 API-->>You: Instance state: running

Inside the guest, cloud-init (or an equivalent agent) sets the hostname, injects the SSH public key, configures networking from DHCP, and then fetches and runs any user data you supplied, all before the instance reports a passing status check.

Only once both the system status check (host-level) and instance status check (OS-level reachability) pass does the instance become fully usable, which is why a newly launched instance can briefly show "running" while still not yet accepting connections.

Cost optimization on EC2 is rarely one lever; it usually combines right-sizing, purchasing strategy, and automation.

1. Right-size instances using CloudWatch utilization data (via Compute Optimizer) instead of guessing.
2. Match purchasing to predictability: Savings Plans/RIs for steady baseline load, Spot for fault-tolerant work, On-Demand only for the unpredictable remainder.
3. Scale down automatically with Auto Scaling and scheduled scaling for known off-peak hours (nights, weekends).
4. Clean up waste: unattached EBS volumes, unused Elastic IPs, and old snapshots all bill even when idle.
5. Modernize architecture to Graviton (ARM) instances where compatible, which often cut cost 20-40% versus equivalent x86 types for the same performance.

The highest-leverage step for most accounts is usually right-sizing first, since running an oversized instance at low utilization wastes money regardless of which pricing model you chose.

EC2 reports two independent status checks: the system status check (underlying hardware/host/network) and the instance status check (the guest OS itself), and identifying which one failed determines your next step.

1. Check the console or describe-instance-status to see which check failed.
2. A system status check failure usually means an underlying host issue; a simple stop/start (not reboot) migrates the instance to new hardware, which resolves most of these.
3. An instance status check failure points to the OS: check for kernel panics, a full root volume, misconfigured networking, or a corrupted filesystem via the console's serial/system log output.
4. If the instance is unreachable but the volume is intact, detach the root EBS volume, attach it to a healthy rescue instance to inspect/repair logs and configuration, then reattach and relaunch.

Rebooting alone won't fix a system status check failure since it restarts the OS on the same, potentially faulty, physical host.

Savings Plans commit you to a dollar amount of compute usage per hour (Compute Savings Plans apply across any instance family, size, Region, and even to Fargate/Lambda; EC2 Instance Savings Plans are narrower but still flexible on size and AZ).

Reserved Instances commit you to a specific instance configuration (family, and optionally Region/AZ), offering similar or slightly higher discounts in exchange for that reduced flexibility, plus the option to resell unused RIs.

Most organizations today default to Compute Savings Plans for their baseline and layer in RIs only where they have specific, unchanging capacity needs.

An ASG can source health status from EC2 status checks alone, or additionally from an attached ELB's target health checks and, for containerized workloads, ECS container health, combining whichever sources you configure.

flowchart TD
A["Instance in ASG"] --> B{EC2 status check healthy?}
B -->|No| E["Mark Unhealthy"]
B -->|Yes| C{ELB health check healthy?}
C -->|No, past threshold| E
C -->|Yes| D["Mark Healthy, keep in service"]
E --> F["ASG terminates instance"]
F --> G["ASG launches replacement"]

A grace period after launch (HealthCheckGracePeriod) prevents the ASG from prematurely marking a still-booting instance unhealthy before its application has finished initializing.

Once an instance is marked unhealthy past its configured threshold, the ASG terminates it and launches a replacement to restore desired capacity, which is what makes an ASG self-healing rather than just a capacity-matching tool.

A regular Stop shuts the OS down cleanly, discarding the contents of RAM; the next start performs a full, fresh boot.

Hibernate saves the contents of RAM to the root EBS volume before shutting down, then restores that exact memory state on start, so applications, open files, and in-memory caches resume instantly instead of re-initializing from scratch.

Hibernate requires the root volume to be encrypted EBS with enough free space to hold the RAM contents, is limited to a supported OS/instance combination and instance sizes up to a set memory ceiling, and instances can stay hibernated for a bounded maximum duration (up to 60 days) before AWS requires them to be started or terminated.

When AWS needs the capacity back, or the Spot price exceeds your maximum, it sends a Spot interruption notice roughly two minutes before reclaiming the instance, delivered both to the instance's metadata endpoint and as an EventBridge event.

Your application (or an agent polling the metadata endpoint) can catch this warning and take action: flush in-flight work, checkpoint state, deregister from a load balancer, or gracefully shut down a process before the deadline.

Depending on the interruption behavior you configured at launch, the instance is then either terminated, stopped, or hibernated; if it's part of a Spot Fleet or an ASG using mixed instance types, the group typically launches a replacement automatically from a different pool to maintain desired capacity.

A client's request first resolves the load balancer's DNS name, connects to one of its nodes across the ALB's Availability Zones, and is matched against listener rules (host, path, or header conditions for an ALB).

sequenceDiagram
participant Client
participant DNS
participant ELB
participant TargetGroup
participant EC2
Client->>DNS: Resolve load balancer name
Client->>ELB: HTTP/TCP request
ELB->>ELB: Evaluate listener rules
ELB->>TargetGroup: Select healthy target
TargetGroup->>EC2: Forward request
EC2-->>TargetGroup: Response
TargetGroup-->>ELB: Response
ELB-->>Client: Response

The matched rule points to a target group, and the ELB picks one of its currently healthy registered instances using the configured algorithm, forwards the request, and relays the instance's response back to the client, adding headers like X-Forwarded-For for an ALB so the origin instance still knows the real client IP.

Because health checks run continuously and independently of live traffic, an instance can be pulled out of rotation mid-session if it starts failing checks, without the client seeing anything beyond its current connection being routed elsewhere on retry.

Start by confirming the CPU metric itself in CloudWatch to rule out a monitoring artifact, then check for CPU credit exhaustion if it's a burstable T-family instance, since a depleted credit balance throttles CPU hard.

top -o %CPU
ps aux --sort=-%cpu | head
vmstat 1 5

Inside the instance, top or htop identifies the offending process; if it's an unexpected process, check for a runaway loop, a memory leak causing excessive garbage collection, or, on a public-facing box, a compromise like a cryptominer.

If the workload is legitimately CPU-bound at capacity, the fix is usually one of: switching to a compute-optimized instance family, enabling unlimited burst mode (with its extra cost) on a T-family instance, or scaling out horizontally behind a load balancer rather than scaling one instance up indefinitely.

Older EC2 instance generations ran on the Xen hypervisor, where a software-based hypervisor layer handled networking, storage virtualization, and I/O, consuming host resources and adding overhead.

The AWS Nitro System offloads networking, storage, and security functions to dedicated hardware/firmware (Nitro cards) and uses a lightweight Nitro Hypervisor, so nearly all of the host's CPU and memory goes to your instance instead of the hypervisor.

Nitro also enables features that weren't practical on Xen, like bare-metal instances, higher network/EBS throughput, and always-on EBS encryption with negligible performance cost, which is why virtually all current-generation instance types are Nitro-based.

Each tier gets its own Auto Scaling group spread across at least two (ideally three) Availability Zones, so the loss of a single AZ never takes down the whole tier.

1. Web/app tier: stateless EC2 instances in an ASG behind an ALB, with subnets in each AZ registered as targets.
2. Data tier: a Multi-AZ managed database (or a self-managed cluster replicated across AZs) so a primary failure fails over automatically.
3. Session/cache state: kept out of individual instances, in something like ElastiCache or DynamoDB, so any instance in any AZ can serve any request.
4. Networking: private subnets per AZ for app/data tiers, public subnets per AZ only for the load balancer and NAT gateways (one NAT per AZ to avoid a cross-AZ single point of failure).

The unifying principle is that no tier depends on a single AZ or a single instance holding unique, unreplicated state, since that's what turns an AZ outage into a full application outage instead of a partial capacity dip.

Lifecycle hooks let you pause an instance in a wait state during scale-out (Pending:Wait) or scale-in (Terminating:Wait) for up to 48 hours by default, so you can run custom actions before the instance fully joins or leaves service.

flowchart LR
A["ASG launches instance"] --> B["Pending:Wait"]
B --> C["Custom action: bootstrap, register with service"]
C --> D[CompleteLifecycleAction] --> E[InService]
E --> F["Scale-in triggered"]
F --> G["Terminating:Wait"]
G --> H["Custom action: drain connections, backup logs"]
H --> I[CompleteLifecycleAction] --> J[Terminated]

A common launch-time use is waiting for a configuration management run or service registration to finish before the instance receives live traffic; a common termination-time use is draining in-flight connections or shipping final logs before the instance disappears.

The hook doesn't run the action itself, it just pauses the transition and emits a notification (via SNS/EventBridge); your own automation is responsible for calling CompleteLifecycleAction to let the instance proceed, and if that call never comes, the instance eventually times out and proceeds automatically after the configured heartbeat timeout.

For a truly steady-state workload where the instance family, size, and Region are locked in for the long term, both options offer comparable, often near-identical, discount levels, so the deciding factor is usually flexibility and operational overhead rather than raw savings.

Savings Plans are generally the better default even here because the commitment is expressed in dollars of compute spend rather than a specific instance configuration, so a later migration to a new instance family, a Graviton switch, or a Region change doesn't strand the discount the way changing away from a Standard RI's exact configuration would.

Reserved Instances still win in narrower cases: when you specifically need a capacity reservation in a particular AZ, or want the option to resell unused commitment on the RI Marketplace if plans change, neither of which Savings Plans support.

In practice, most teams default to Compute Savings Plans for baseline coverage and reach for RIs only when one of those specific capabilities is actually required.

Network performance depends on the instance type's baseline/burst bandwidth, the network interface driver, and how instances are placed relative to each other.

1. Choose a sufficiently large instance type/family, since network bandwidth generally scales with instance size within a family.
2. Enable enhanced networking (ENA, or on legacy types Intel 82599 VF) for higher packets-per-second and lower latency versus the default virtualized network path.
3. Use a Cluster placement group for workloads needing the lowest latency and highest throughput between instances in the same AZ.
4. Consider Elastic Fabric Adapter (EFA) for HPC/tightly-coupled workloads needing OS-bypass networking beyond what standard ENA provides.
5. Verify the driver is actually active inside the guest, since enabling ENA at the API level does nothing if the instance's OS/AMI lacks the ENA driver.

ethtool -i eth0 | grep driver

Checking the driver with a command like the one above confirms whether the instance is actually using the enhanced networking path rather than falling back to a legacy, slower one.