Amazon Elastic Compute Cloud (Amazon EC2) provides virtual servers on demand. To use it well, match an instance to the workload, place it in the right network and Availability Zone, protect access, and account for both compute and storage costs. This guide covers those building blocks and the choices that most often cause confusion.

What Amazon EC2 provides

An EC2 instance is a virtual server running in an AWS Region. At launch, you select an Amazon Machine Image (AMI), an instance type, a network location, storage, and access controls. You can start, stop, replace, or scale instances through the console, APIs, command-line tools, and infrastructure as code.

The EC2 responsibility boundary

AWS operates the physical infrastructure and virtualization layer. You remain responsible for the guest operating system, application software, instance credentials, permissions, and network rules. That division is the shared responsibility model for EC2. EC2 gives you control over a server; it does not patch your application or make a single instance highly available for you.

Elasticity and availability

You can add or remove instances as demand changes. An instance runs in one Availability Zone; a workload that must tolerate a zone failure needs capacity and dependencies in other zones as well. A load balancer can distribute requests, while an Auto Scaling group can replace unhealthy instances or adjust group capacity when the application is designed for that pattern. See the practical EC2 Auto Scaling setup guide for group configuration and rollout details.

Common workloads

EC2 is a fit when you need control over the operating system or runtime, have software that expects a server, or need a particular compute, memory, storage, or accelerator profile. Common examples include web services, background workers, development environments, and batch processing. For a managed database, container platform, or serverless function, compare the operational trade-offs before defaulting to a virtual machine.

Choose an instance family for the workload

The main EC2 instance families

Instance families group hardware around different resource balances. General purpose balances CPU, memory, and networking; compute optimized emphasizes CPU; memory optimized provides more memory for in-memory workloads; storage optimized targets local storage and I/O; accelerated computing adds hardware such as GPUs for supported tasks. These are starting points, not performance guarantees. Compare the exact family generation and size against your software and measured workload.

General purpose

Consider a general-purpose family for services that need a balanced mix of resources. Burstable T instances suit workloads with intermittent CPU peaks; sustained CPU-heavy work may exhaust credits or incur surplus-credit charges, so check the credit mode and usage before choosing one.

Compute optimized

Consider compute-optimized instances when processor capacity is the constraint, as in some batch, encoding, or high-throughput application workloads. Validate runtime, concurrency, and latency rather than assuming more vCPUs will improve every application.

Memory optimized

Memory-optimized instances can suit databases, caches, and analytics that keep large working sets in RAM. Check application and operating-system memory use; CPU utilization by itself cannot show whether a server has enough memory.

The choices behind an EC2 instance

AMI and processor architecture

An AMI supplies the software and boot configuration used to launch an instance. AMIs are Region-specific and are built for an operating system, processor architecture, and root-volume type; the AMI must be compatible with the chosen instance type. When comparing x86 and Arm options, confirm that the operating system, application binaries, agents, and dependencies support that architecture. See AWS’s AMI overview for the compatibility details.

Networking and access

EC2 instances launch into a subnet in a VPC and an Availability Zone. A security group controls allowed inbound and outbound traffic. Restrict administrative access to trusted sources, or use a private connection method; avoid exposing SSH or RDP to every internet address. Attach an instance role only when software on the instance needs AWS API access, and grant it the permissions that software requires.

Launch an instance safely

A launch checklist

Before you launch from the console, CLI, or a template, decide the following:

  1. Region and subnet: choose where the workload belongs and which Availability Zone will host this instance.
  2. Identity: name and tag the resource so its owner and purpose are clear.
  3. AMI: select a supported operating system and compatible architecture.
  4. Instance type: start with a family and size that meet the measured CPU, memory, network, and storage needs.
  5. Connection method: choose a key pair, EC2 Instance Connect, or Systems Manager Session Manager based on your access design.
  6. Network rules: allow only required application traffic and trusted administration paths.
  7. Storage: select the root and data volumes, including persistence and performance needs.
  8. Review: check the price model, tags, permissions, and delete-on-termination settings before launch.

In the console, this flow starts at EC2 > Instances > Launch instances. After launch, check instance and system status checks, connect using your selected method, and verify that the application starts and responds as expected.

Connect without broad public access

Systems Manager Session Manager can provide shell access without opening inbound SSH when the instance has a supported SSM Agent, the required IAM permissions, and connectivity to Systems Manager. EC2 Instance Connect is another option for supported configurations. Check the prerequisites for the specific method and network; neither works just by selecting its name.

Console, CLI, or infrastructure as code

The launch interface changes the workflow, not the underlying decisions. An API or CLI request still needs a compatible AMI, subnet, security groups, IAM profile when required, and storage configuration. Use the current AWS launch instructions for the interface you use.

When an instance is no longer needed, stop it if you expect to use it again or terminate it when it is finished. Stopping ends instance usage charges but does not remove EBS storage charges. After termination, review retained volumes, snapshots, and addresses so unused resources do not continue to incur charges.

Choose storage by persistence and access pattern

Amazon EBS volumes

Amazon Elastic Block Store (EBS) provides block storage that persists independently of a running instance. An EBS volume is in one Availability Zone and normally attaches to an instance in that same zone. You pay for provisioned EBS storage while it exists, including when its instance is stopped. An EBS-backed instance does not incur instance usage charges while stopped, but related resources can still cost money.

Check each volume’s DeleteOnTermination setting before terminating an instance. The root volume is deleted by default; data-volume behavior depends on how it was attached and configured. Keep snapshots or another backup when the data matters. See AWS’s guidance on instance states and billing and what termination deletes.

EC2 instance store

Instance store is local block storage available on some instance types. Its data survives a reboot, but not a stop, hibernation, termination, or certain host events. Use it for scratch data, caches, or other information you can recreate or copy elsewhere—not as the only copy of durable data.

Compare the storage options

Use EBS when you need a separately managed block volume that can survive a stop or instance replacement. Use instance store when local performance is useful and the data is disposable or replicated by the application. Storage performance also depends on the instance’s EBS and network limits, the volume configuration, and the application’s I/O pattern. The focused EC2 right-sizing guide explains how to include those constraints in a sizing decision.

Understand EC2 pricing before committing

Pay for compute, storage, and related resources

On-Demand is useful when capacity needs are uncertain because it does not require a long-term usage commitment. Spot Instances use spare capacity at a lower variable price, but AWS can interrupt them; use Spot only when the workload can handle interruption. EBS volumes, snapshots, data transfer, and public IPv4 addresses can add charges beyond instance compute. Review the pricing details for the Region, operating system, tenancy, and resources you plan to use.

Separate right-sizing from a usage commitment

First identify the instance configuration and workload capacity you need. If usage is steady, then compare eligible Savings Plans or Reserved Instances. Savings Plans exchange a one- or three-year commitment to a consistent hourly compute spend for lower rates. Reserved Instances apply a billing discount to matching EC2 usage; only zonal Reserved Instances reserve capacity. Either commitment can outlast the workload or configuration that justified it, so model the term and expected usage before purchasing.

Free Tier and operating-system lifecycle

Free Tier benefits depend on when the AWS account was created. Since July 15, 2025, new customers have had a credit-based option with a time-limited free plan; older accounts remain under legacy terms. As of this article’s October 2026 update, the original 12-month EC2 allowance has ended for every pre-cutoff account. Check the account’s current Free Tier and billing pages rather than assuming an instance is free. AWS explains the change in its Free Tier announcement.

Choose an operating system that is still supported. Amazon Linux 2 reached end of support on June 30, 2026, so it should not be treated as the default for a new deployment; AWS’s Amazon Linux 2 lifecycle FAQ describes the status.

Scale capacity and plan for change

Moving a workload to EC2

When moving software to EC2, check operating-system support, dependencies, licenses, storage, identity, networking, backups, and recovery needs. A direct move to a virtual machine does not guarantee lower cost or high availability; include operations and resilience in the comparison.

Scale out when the application can use more instances

EC2 Auto Scaling changes the number of instances in a group. It does not resize each running instance. Use an Auto Scaling group when the application can start replacement instances and distribute work among them. If one instance is the bottleneck, right-sizing or changing the application may be necessary. For web traffic, an Elastic Load Balancing service can route requests across healthy targets.

Design for Availability Zone failure

A load balancer and multiple instances improve resilience only when the application, data layer, and dependencies can operate across zones. A single instance in one zone remains exposed to that zone’s interruption. Test recovery and deployment behavior against the application’s actual availability needs.

EC2 essentials to carry forward

An EC2 instance combines an AMI, instance type, network placement, storage, and access policy. Keep the operating system and application secure, protect durable data, measure every resource that affects the workload, and include stopped-instance storage and long-term pricing commitments in cost decisions.