Visual overview
An EC2 instance runs in a VPC and commonly uses EBS for durable block storage.
Technical reference
An EC2 launch combines image, compute, network, storage, identity, and placement parameters.
AMI supplies the boot image; instance type defines the compute resource profile.
Placement establishes network context; security groups provide stateful traffic rules.
Applications should use temporary role credentials instead of stored long-lived keys.
Volumes have independent type, size, performance, encryption, and snapshot settings.
What Amazon EC2 provides
Amazon Elastic Compute Cloud (Amazon EC2) provides virtual servers, called instances, in the AWS Cloud. It is an infrastructure-level compute service: you choose a machine image, an instance type, networking and storage characteristics, then run an operating system and applications on the resulting virtual machine. EC2 is therefore a natural choice when a workload needs operating-system access, custom software, specialized instance hardware, or infrastructure behavior that a more abstract managed compute service does not expose.
An EC2 instance should not be thought of as a complete application platform by itself. It participates in a larger architecture. The instance normally runs inside an Amazon VPC subnet, receives security-group rules, uses an IAM role when applications need AWS API permissions, and commonly attaches durable Amazon EBS volumes. Production applications often place multiple instances behind Elastic Load Balancing and manage the fleet with Amazon EC2 Auto Scaling rather than treating one server as permanent.
The launch building blocks
Every EC2 launch starts with an Amazon Machine Image (AMI). The AMI supplies the software needed to boot the instance and is tied to characteristics such as Region, operating system and processor architecture. The instance type then determines the hardware profile made available to the virtual machine, including combinations of CPU, memory, storage and networking capabilities. This separation lets the same software image run on different compatible instance sizes and lets one approved image become the baseline for many instances.
Networking and storage complete the basic server. A subnet determines where the primary network interface is placed inside the VPC, while security groups act as stateful virtual firewalls around network access. EBS-backed root volumes can persist independently according to their deletion settings; instance-store volumes, where available, are temporary storage tied to the host lifecycle. Treat storage behavior as an explicit architecture decision rather than assuming that every disk attached to a virtual server has the same durability semantics.
- AMI — bootable software baseline for the instance.
- Instance type — resource profile for compute, memory, storage and networking.
- VPC, subnet and security groups — network placement and traffic controls.
- EBS or instance store — different storage options with different persistence characteristics.
- IAM role — temporary AWS permissions for applications running on the instance.
Lifecycle and operations
EC2 exposes an instance lifecycle that includes launch, running, stop and termination states for supported EBS-backed configurations. Stopping a typical EBS-backed instance stops compute while retaining its EBS root volume, whereas terminating removes the instance and follows the configured delete-on-termination behavior for attached volumes. Because applications should survive individual server loss, mature designs store durable state outside disposable compute whenever practical and automate the creation of replacement capacity.
The shared responsibility model is especially visible with EC2. AWS operates the physical facilities, networking, host hardware and virtualization infrastructure. The customer manages the guest operating system, including patching and hardening, as well as applications, data, identities and service configuration. Monitoring with services such as Amazon CloudWatch, controlled administrative access, vulnerability management, backups and repeatable provisioning are therefore part of operating EC2 well.
When to choose EC2
EC2 is strong when you need deep control: custom operating-system packages, long-running processes, specialized CPU or accelerator families, particular networking capabilities, legacy software, custom agents, or software that expects a traditional server. It also provides a broad set of purchasing and tenancy choices. Those capabilities make EC2 suitable for workloads ranging from web application fleets to enterprise software, development environments, high-performance computing and specialized accelerated workloads.
Choose a higher-level compute service when its abstraction matches the requirement and the infrastructure control of EC2 would only create undifferentiated operations. Lambda removes server management for event-driven functions; Fargate removes the need to manage server capacity for supported container workloads; Elastic Beanstalk can manage common application-environment infrastructure; Lightsail packages a simpler subset of resources for straightforward projects. The best compute service is the one whose responsibility boundary matches what the workload actually needs.
Key takeaways
- 01
EC2 instances are virtual servers built from an AMI, an instance type, networking, storage and security configuration.
- 02
EC2 gives the customer operating-system control, which also makes guest OS patching and hardening customer responsibilities.
- 03
Production EC2 capacity is commonly designed as a replaceable fleet rather than as one permanent server.
- 04
Use EC2 when infrastructure control is valuable; use a more abstract compute service when server operations add no value.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.