AWS EC2 Compute Guide

Amazon Elastic Compute Cloud, known as EC2, is the foundational compute service in AWS. It provides resizable virtual servers in the cloud, giving you complete control over the operating system, networking, storage, and software stack running on each instance. Whether you are deploying a simple web application, running batch processing jobs, hosting databases, or building complex microservice architectures, EC2 is the service that makes it possible to run virtually any workload without owning physical hardware.

EC2 is one of the oldest and most mature AWS services, launched in 2006, and it remains central to how organizations run workloads in the cloud today. Even with the rise of serverless computing and container orchestration, EC2 underpins many of those higher-level services. Understanding EC2 deeply gives you the ability to make informed decisions about when to use raw compute versus managed services, how to optimize costs through instance selection and purchasing options, and how to architect for high availability and fault tolerance.

This guide covers everything you need to go from launching your first instance to running production workloads with auto-scaling, load balancing, and proper security configurations. If you are following the AWS services roadmap, EC2 is a critical service to master early because it connects to nearly every other AWS service through networking, storage, and identity integrations. You will also need a solid understanding of IAM to manage permissions for your instances and the users who operate them.

What You Will Learn

After completing this guide, you will have a thorough understanding of EC2 and how to use it effectively in production environments. Specifically, you will learn:

• How EC2 instances work at a fundamental level, including the relationship between AMIs, instance types, storage volumes, and networking interfaces that define every virtual server
• How to choose the right instance type from the dozens of families and sizes available, matching compute, memory, storage, and networking characteristics to your workload requirements
• How to launch, connect to, and manage instances using the AWS CLI, including key pair creation, security group configuration, and user data scripts for automated provisioning
• How security groups and network ACLs control traffic flow to and from your instances, and how to design security rules that follow the principle of least privilege
• How Elastic IP addresses provide static public endpoints for your instances and when to use them versus other networking approaches
• How Amazon Machine Images let you create reusable templates that capture your entire server configuration for consistent deployments across environments
• How EC2 Auto Scaling automatically adjusts capacity based on demand, maintaining application availability while optimizing costs
• How to integrate EC2 with Elastic Load Balancing to distribute traffic across multiple instances for high availability and fault tolerance
• How purchasing options like On-Demand, Reserved Instances, Savings Plans, and Spot Instances let you reduce compute costs by up to ninety percent depending on your workload characteristics

Each section builds progressively, so reading from start to finish gives you the most complete understanding of how these components work together in real deployments.

Prerequisites

Before working through this guide, ensure you have the following ready:

• An active AWS account with permissions to create EC2 instances, security groups, key pairs, and related resources, either through an administrator IAM user or through a role with the appropriate EC2 policies attached
• The AWS CLI installed and configured with valid credentials using aws configure, so you can execute commands directly from your terminal without switching to the console
• Familiarity with Linux developer commands including SSH, file permissions, process management, and basic shell scripting, since most EC2 instances run Linux and you will manage them through the command line
• A basic understanding of networking concepts like IP addresses, ports, TCP versus UDP, CIDR notation, and how firewalls filter traffic, since EC2 security groups operate at the network level
• An SSH client installed on your local machine, which is built into macOS and Linux terminals and available through tools like PuTTY or Windows Terminal on Windows

No prior EC2 experience is required. If you have ever used a virtual machine through VirtualBox, VMware, or any cloud provider, the concepts will feel familiar, though EC2 adds cloud-specific capabilities around scaling, purchasing models, and deep integration with other AWS services.

Concept Overview

EC2 provides virtual servers called instances that run on physical hardware managed by AWS. When you launch an instance, you are allocated a slice of a physical server in one of the AWS data centers within your chosen region and availability zone. The instance behaves like a dedicated server from your perspective, with its own operating system, CPU, memory, storage, and network interface, but AWS handles all the underlying hardware maintenance, power, cooling, and physical security.

Every EC2 instance is defined by four core components. The Amazon Machine Image specifies the operating system and pre-installed software. The instance type determines the hardware profile including CPU cores, memory, network bandwidth, and storage capabilities. The storage configuration defines the root volume and any additional EBS volumes or instance store disks. The network configuration places the instance in a VPC subnet with security groups controlling inbound and outbound traffic.

The instance lifecycle moves through several states. When you launch an instance it enters the pending state while AWS allocates resources. It then transitions to running, where it is accessible and billing begins. You can stop an instance to pause billing while preserving its EBS volumes and configuration, or terminate it to permanently destroy it. Stopped instances retain their private IP address and EBS data but release their public IP unless you have attached an Elastic IP.

EC2 pricing follows a pay-as-you-go model where you are billed per second of running time for most instance types. This granular billing means you only pay for exactly the compute time you use, making it economical to run instances for short tasks and shut them down when idle. Multiple purchasing options exist to reduce costs for predictable workloads, which we cover in detail later in this guide.

Step-by-Step Explanation

This section walks through the essential implementation steps in order. Each step builds on the previous one, providing a clear path from initial configuration to a production-ready setup that follows AWS best practices.

Launching Your First EC2 Instance

The process of launching an instance involves selecting an AMI, choosing an instance type, configuring networking and security, and specifying a key pair for SSH access. The following commands demonstrate launching a basic Amazon Linux 2023 instance using the AWS CLI.

# Create a key pair for SSH access and save the private key
aws ec2 create-key-pair \
  --key-name my-app-key \
  --query 'KeyMaterial' \
  --output text > my-app-key.pem
 
# Set proper permissions on the private key file
chmod 400 my-app-key.pem
 
# Create a security group that allows SSH and HTTP traffic
aws ec2 create-security-group \
  --group-name my-app-sg \
  --description "Security group for web application" \
  --vpc-id vpc-0abc123def456
 
# Allow SSH access from your IP address only
aws ec2 authorize-security-group-ingress \
  --group-name my-app-sg \
  --protocol tcp \
  --port 22 \
  --cidr $(curl -s https://checkip.amazonaws.com)/32
 
# Allow HTTP traffic from anywhere
aws ec2 authorize-security-group-ingress \
  --group-name my-app-sg \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0
 
# Launch an instance with Amazon Linux 2023
aws ec2 run-instances \
  --image-id ami-0c55b159cbfafe1f0 \
  --instance-type t3.micro \
  --key-name my-app-key \
  --security-groups my-app-sg \
  --count 1 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=my-web-server}]' \
  --user-data file://setup.sh
 
# Check instance status
aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=my-web-server" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,IP:PublicIpAddress}'
 
# Connect via SSH once the instance is running
ssh -i my-app-key.pem ec2-user@<public-ip-address>

The user data script referenced above runs automatically when the instance first boots. This is how you automate initial server configuration without manually SSHing in after launch. A typical user data script installs packages, configures services, and pulls application code.

Understanding Instance Types

EC2 offers hundreds of instance types organized into families that optimize for different workload characteristics. The naming convention follows a pattern like m5.xlarge where m is the family, 5 is the generation, and xlarge is the size. Understanding this system helps you select the right instance without trial and error.

General purpose instances in the M and T families provide a balanced ratio of compute, memory, and networking. The T family uses a burstable performance model where you accumulate CPU credits during idle periods and spend them during spikes, making T instances ideal for workloads with variable CPU usage like development environments, small web servers, and microservices that handle intermittent traffic.

Compute optimized instances in the C family provide the highest ratio of CPU performance to cost. They are designed for compute-intensive workloads like batch processing, scientific modeling, machine learning inference, gaming servers, and high-performance web servers that need to handle many concurrent requests with minimal latency.

Memory optimized instances in the R and X families provide large amounts of RAM relative to CPU. They suit workloads that process large datasets in memory, such as in-memory databases like Redis and Memcached, real-time analytics engines, and applications that cache large working sets to avoid disk access.

Storage optimized instances in the I and D families provide high sequential read and write access to very large datasets on local storage. They are designed for data warehousing, distributed filesystems, and high-frequency online transaction processing systems that need low-latency access to large volumes of data.

Security Groups and Network Access Control

Security groups act as virtual firewalls that control inbound and outbound traffic at the instance level. Every instance must be associated with at least one security group, and you can attach up to five security groups to a single instance. Security groups are stateful, meaning if you allow inbound traffic on a port, the response traffic is automatically allowed outbound regardless of outbound rules.

The principle of least privilege should guide your security group design. Start with no inbound rules and add only the specific ports and source addresses your application requires. Never open port 22 to the entire internet in production. Instead, restrict SSH access to your office IP range, a bastion host, or use AWS Systems Manager Session Manager which eliminates the need for open SSH ports entirely.

Security groups differ from network ACLs in important ways. Security groups operate at the instance level and are stateful, while network ACLs operate at the subnet level and are stateless. In practice, security groups handle most access control needs, and network ACLs provide an additional layer of defense for compliance requirements or to block specific IP ranges at the subnet boundary.

Elastic IP Addresses

By default, EC2 instances receive a dynamic public IP address that changes every time the instance is stopped and started. Elastic IP addresses solve this by providing a static public IPv4 address that you own until you explicitly release it. You can associate an Elastic IP with any instance in your account, and reassociate it with a different instance if the original fails, providing a simple failover mechanism.

Elastic IPs are free while associated with a running instance but incur a small hourly charge when unassociated or associated with a stopped instance. This pricing encourages you to release addresses you are not actively using. In modern architectures, load balancers and DNS-based routing often replace the need for Elastic IPs on individual instances, but they remain useful for bastion hosts, NAT instances, and services that require a fixed IP for allowlisting by external partners.

Amazon Machine Images

An AMI is a template that contains the operating system, application server, applications, and associated configuration needed to launch an instance. AWS provides official AMIs for Amazon Linux, Ubuntu, Red Hat, Windows Server, and other operating systems. The community and marketplace offer thousands of pre-configured AMIs with specific software stacks already installed.

Creating custom AMIs from your configured instances is a powerful practice for production deployments. Once you have an instance configured exactly as needed with your application code, dependencies, and system settings, you create an AMI from it. Future instances launched from that AMI start in an identical state, eliminating configuration drift and reducing deployment time from minutes to seconds.

The AMI creation process takes a snapshot of the instance root volume and any attached EBS volumes, registers them as a new AMI, and makes it available for launching new instances. You should version your AMIs with meaningful names and tags, and establish a lifecycle policy that deregisters old AMIs and deletes their backing snapshots to avoid accumulating storage costs.

EC2 Auto Scaling

Auto Scaling automatically adjusts the number of running instances based on demand, ensuring your application has enough capacity during traffic spikes while minimizing costs during quiet periods. It operates through three components: a launch template that defines what to launch, an Auto Scaling group that defines where and how many, and scaling policies that define when to scale.

A launch template captures the instance configuration including AMI, instance type, key pair, security groups, user data, and storage settings. It replaces the older launch configuration format and supports versioning so you can update configurations without recreating the entire Auto Scaling group.

The Auto Scaling group defines the minimum, maximum, and desired number of instances, the subnets where instances should be placed, and the health check configuration. Distributing instances across multiple availability zones provides fault tolerance because if one zone experiences issues, the group automatically launches replacement instances in healthy zones.

Scaling policies determine when the group adds or removes instances. Target tracking policies are the simplest, where you specify a target value for a metric like average CPU utilization at fifty percent, and Auto Scaling adjusts capacity to maintain that target. Step scaling policies provide more control by defining different scaling actions for different alarm thresholds. Scheduled scaling lets you proactively adjust capacity for predictable traffic patterns like business hours or marketing events.

Real-World Use Cases

EC2 serves as the compute backbone for countless production architectures. Understanding common deployment patterns helps you design solutions that are reliable, cost-effective, and operationally manageable.

Web application hosting is the most common EC2 use case. A typical production setup places multiple EC2 instances behind an Application Load Balancer across two or more availability zones. Auto Scaling maintains the desired capacity and responds to traffic changes. The instances run your application server, whether that is Node.js, Java with Spring Boot, Python with Django, or any other runtime, while databases run on managed services like RDS to separate compute from data.

Batch processing and data pipelines use EC2 Spot Instances to run compute-intensive jobs at a fraction of On-Demand pricing. Since Spot Instances can be interrupted with two minutes notice, batch architectures checkpoint their progress and resume from the last checkpoint when a new instance becomes available. This pattern works well for video transcoding, genomics analysis, financial modeling, and machine learning training where individual tasks are parallelizable and fault-tolerant.

Development and testing environments benefit from the T family burstable instances that provide adequate performance for intermittent workloads at low cost. Teams often use Auto Scaling scheduled actions to shut down development instances outside business hours, reducing compute costs by sixty percent or more without manual intervention.

Bastion hosts provide secure SSH access to instances in private subnets. A single hardened instance in a public subnet with strict security group rules serves as the jump point for administrators who need to reach backend servers. Modern alternatives like AWS Systems Manager Session Manager eliminate bastion hosts entirely by providing browser-based and CLI-based shell access through the AWS API without opening any inbound ports.

Best Practices

Following established best practices for EC2 ensures your deployments are secure, cost-effective, and operationally sound. These recommendations come from years of production experience across organizations of all sizes.

Right-size your instances by monitoring actual resource utilization over time. Many organizations over-provision instances based on peak estimates that never materialize. Use CloudWatch metrics to track CPU, memory, network, and disk utilization, then downsize instances that consistently run below thirty percent utilization. AWS Compute Optimizer provides automated right-sizing recommendations based on your historical usage patterns.

Use multiple availability zones for any workload that requires high availability. Placing all instances in a single zone creates a single point of failure. Auto Scaling groups should span at least two zones, and your minimum capacity should be set so that losing one zone still leaves enough instances to handle traffic.

Implement proper tagging from day one. Tags like Environment, Team, Application, and CostCenter enable you to track spending, enforce policies, and automate operations across hundreds of instances. Without consistent tagging, cost allocation becomes impossible and automation scripts cannot reliably identify which instances belong to which workload.

Prefer launch templates over manual instance launches. Templates ensure consistency across environments, enable version control of your infrastructure configuration, and integrate with Auto Scaling and other AWS services. Treat your launch templates as infrastructure code that lives in version control alongside your application.

Use IAM instance profiles instead of embedding credentials on instances. An instance profile attaches an IAM role to the instance, providing temporary credentials that rotate automatically. Applications running on the instance can then access AWS services without storing long-lived access keys, which eliminates a common security vulnerability.

Encrypt EBS volumes by default using AWS-managed keys or customer-managed KMS keys. Enable default encryption at the account level so every new volume is automatically encrypted without requiring developers to remember. This satisfies compliance requirements and protects data at rest with zero performance impact on modern instance types.

Common Mistakes

Even experienced engineers make mistakes with EC2 that lead to security vulnerabilities, unexpected costs, or operational incidents. Recognizing these patterns helps you avoid them in your own deployments.

Opening security group port 22 to the entire internet is the most common security mistake. Automated scanners constantly probe every public IP address for open SSH ports, and compromised instances are used for cryptocurrency mining, spam distribution, and lateral attacks. Always restrict SSH access to known IP ranges or eliminate the need for open ports entirely using Session Manager.

Forgetting to set up billing alerts leads to surprise charges when instances are left running accidentally. A single forgotten GPU instance can cost thousands of dollars per month. Set up AWS Budgets with alerts at fifty and eighty percent of your expected monthly spend, and use automated actions to stop non-production instances when budgets are exceeded.

Not using Auto Scaling for production workloads means your application cannot respond to traffic changes and has no automated recovery from instance failures. Even if your traffic is steady, Auto Scaling provides self-healing by automatically replacing unhealthy instances, which is valuable for any production service.

Storing application state on instance local storage means that data is lost when the instance terminates or the underlying hardware fails. Instance store volumes are ephemeral by design. Use EBS volumes for data that must persist, S3 for objects and backups, and external databases or caches for application state that must survive instance replacement.

Running outdated AMIs with unpatched operating systems exposes your instances to known vulnerabilities. Establish a regular patching cadence using AWS Systems Manager Patch Manager, or adopt an immutable infrastructure approach where you build new AMIs with the latest patches and replace running instances rather than patching them in place.

Choosing the wrong purchasing option wastes money. Running steady-state production workloads on On-Demand pricing when Reserved Instances or Savings Plans would provide the same capacity at forty to sixty percent less cost is a common oversight. Analyze your usage patterns after a few months of operation and commit to reservations for baseline capacity while using On-Demand or Spot for variable demand.

Summary

EC2 is the foundational compute service in AWS that gives you full control over virtual servers in the cloud. You learned how instances are defined by their AMI, instance type, storage, and network configuration, and how to launch and manage them through the AWS CLI. Security groups provide stateful firewall protection at the instance level, and following the principle of least privilege keeps your infrastructure secure.

Instance types are organized into families optimized for different workload characteristics, from general purpose T and M families to compute-optimized C, memory-optimized R, and storage-optimized I families. Choosing the right type based on actual workload requirements rather than guesswork is essential for both performance and cost optimization.

Auto Scaling ensures your applications maintain availability during demand fluctuations while minimizing costs during quiet periods. Combined with Elastic Load Balancing and multi-availability-zone deployments, Auto Scaling provides the foundation for highly available production architectures that self-heal from failures.

The purchasing options available for EC2, including On-Demand, Reserved Instances, Savings Plans, and Spot Instances, give you flexibility to optimize costs based on your workload characteristics. Production workloads benefit from a mix of committed capacity for baseline demand and flexible capacity for variable traffic.

As you continue building on AWS, EC2 integrates with virtually every other service in the ecosystem. Your instances connect to RDS databases, store objects in S3, receive traffic through load balancers, emit logs to CloudWatch, and authenticate to other services through IAM roles. Mastering EC2 gives you the compute foundation on which everything else is built. Return to the AWS services roadmap to continue exploring the services that complement EC2 in production architectures.