AWS Services
Amazon EC2
Learn EC2 as the core AWS virtual machine service, including instances, AMIs, storage, networking, scaling, security, and exam decision signals.
After this, you will understand
EC2 is the baseline compute model that makes managed alternatives easier to understand: what they remove, what they keep, and what you still own.
EC2 gives you virtual machines in AWS that you configure, secure, scale, and operate.
Learners treat EC2 as just a server and miss placement, instance profiles, EBS behavior, Auto Scaling, and responsibility boundaries.
Use EC2 when you need VM-level control, then add load balancing, Auto Scaling, IAM roles, private subnets, and managed storage around it.
Think before readingWhen is EC2 the right answer instead of a more managed compute service?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- EC2 instances
- Amazon Machine Images
- instance families and sizes
- purchasing options
- EBS and instance store
- security groups and key pairs
- IAM instance profiles
- user data
- Elastic Load Balancing and Auto Scaling
- SAA-C03 compute signals
1. Plain-English Mental Model
Amazon Elastic Compute Cloud, or EC2, is AWS virtual machines.
You choose an Amazon Machine Image, an instance type, a network placement, storage, security rules, and permissions. AWS gives you a running server. You can install software, run agents, deploy applications, attach disks, join networks, and manage the operating system.
The beginner model is:
AMI + instance type + subnet + storage + security group + IAM role = EC2 instance
EC2 is close to traditional server thinking. That makes it familiar, but it also means you keep more responsibility than with managed services. You manage the guest operating system, packages, application runtime, patching approach, host-level monitoring, and many scaling decisions.
EC2 matters because many managed AWS services are easier to understand by contrast. RDS is like "database without managing the database server." Lambda is like "compute without managing the server." ECS and EKS are "container orchestration around compute." EC2 is the baseline.
2. Why This Service Exists
EC2 exists because teams need flexible compute without buying physical servers.
Some workloads need deep control: custom operating system settings, special agents, GPU instances, high-memory machines, legacy software, lift-and-shift migrations, licensed software, or precise networking behavior. EC2 gives that control while still letting AWS handle the physical data center, hardware procurement, host virtualization, and elastic capacity pool.
For Solutions Architect study, EC2 teaches core AWS design patterns:
- place compute in private subnets
- expose traffic through load balancers
- scale horizontally with Auto Scaling groups
- attach permissions with IAM roles
- use EBS for persistent block storage
- use user data or images for bootstrapping
- select instance families based on workload shape
Even if a final architecture uses containers or serverless, the EC2 model helps you reason about compute, networking, storage, and responsibility boundaries.
3. The Naive Approach And Where It Breaks
The naive EC2 design is one public instance running the whole application.
It is simple:
user -> public EC2 instance -> local app and data
It breaks quickly. The instance is a single point of failure. Public SSH exposure is risky. Local instance data may be lost. Vertical scaling has limits. Deployments become manual. Operating system patching is easy to forget. Traffic spikes can overload the server. The application and database may be coupled to one machine.
A more durable design separates concerns:
users -> load balancer -> EC2 Auto Scaling group in private subnets -> database
The load balancer handles public entry. EC2 instances scale across Availability Zones. Persistent data moves to managed storage or databases. IAM roles replace hardcoded credentials. Logs and metrics go to centralized systems. The design starts to look like cloud architecture rather than rented hosting.
4. Core Primitives
An AMI is a template for launching an instance. It includes an operating system and optional software. You can use AWS-provided AMIs, marketplace AMIs, or custom AMIs.
An instance type defines the compute shape: CPU, memory, network performance, storage features, and hardware family. General purpose, compute optimized, memory optimized, storage optimized, accelerated computing, and burstable families support different workload profiles.
EBS provides persistent block storage. An EBS volume exists in one Availability Zone and can be attached to EC2 instances in that AZ. Instance store is temporary storage physically attached to the host and is not durable across stop, terminate, or hardware failure events.
Security groups control instance network traffic. They are stateful and attached to network interfaces.
An instance profile attaches an IAM role to an EC2 instance. This is the standard way for applications on EC2 to call AWS APIs without storing long-lived access keys.
User data can run scripts at launch to bootstrap configuration.
5. Architecture Use Cases
EC2 is a good fit for legacy applications that expect a server, applications requiring full OS control, commercial software packages, custom networking agents, game servers, high-performance computing, GPU workloads, and migrations where rewriting the application is not practical yet.
In a web architecture, EC2 instances usually sit behind an Application Load Balancer. The instances run in private subnets across multiple AZs. An Auto Scaling group maintains capacity and replaces unhealthy instances. The database is externalized to RDS, Aurora, DynamoDB, or another data service.
For batch processing, EC2 can run worker fleets that scale based on queue depth. Spot Instances can reduce cost for interruptible work. For steady-state predictable workloads, Savings Plans or Reserved Instances can reduce cost.
For administrative access, prefer AWS Systems Manager Session Manager where possible instead of opening SSH from the internet.
7. Security Model
EC2 security has several layers.
Network exposure is controlled with subnet placement, route tables, security groups, and NACLs. Production instances should often live in private subnets, with public traffic entering through a load balancer.
Identity is controlled with IAM roles. Applications should use instance profiles to receive temporary credentials. Avoid placing AWS access keys on disk.
Operating system security is the customer's responsibility. That includes patching, local users, packages, host firewalls, malware controls when needed, and secure configuration.
Data protection depends on storage choices. EBS volumes can be encrypted. Snapshots can be encrypted. Secrets should be stored in services such as Secrets Manager or Systems Manager Parameter Store, not hardcoded in user data or application files.
Audit and operations use CloudTrail for API actions and CloudWatch or other tooling for instance metrics, logs, alarms, and health.
8. Reliability And Resilience
An individual EC2 instance is not a highly available architecture. Instances can fail, be replaced, or be affected by AZ issues.
Reliability usually comes from spreading instances across multiple AZs, using Auto Scaling groups, keeping instances stateless where possible, and using load balancers for health-based routing.
Persistent state should live outside the instance when possible. Use RDS, Aurora, DynamoDB, EFS, S3, or other managed storage depending on the data model. EBS is durable within one AZ, but it does not make a single instance architecture highly available.
Auto Scaling can replace unhealthy instances. Launch templates help standardize how new instances are created. Health checks can come from EC2, load balancers, or custom monitoring.
Backups matter. EBS snapshots can protect block volumes, but recovery design must include how new instances attach data and resume service.
9. Performance And Scaling
EC2 can scale vertically by changing instance size or horizontally by adding instances.
Vertical scaling is simple but limited and often requires a stop/start or replacement. Horizontal scaling is the cloud-native pattern for web and worker fleets. Auto Scaling groups can scale based on CPU, request count, queue depth, custom metrics, or schedules.
Instance family selection matters. Compute-optimized instances fit CPU-heavy workloads. Memory-optimized instances fit caches and in-memory databases. Storage-optimized instances fit local high-throughput storage needs. GPU and accelerator instances fit machine learning, graphics, and specialized compute.
Placement groups can improve network performance or spread instances for failure isolation, but they are specialized tools. For the associate exam, know the high-level intent: cluster for low latency, spread for reducing correlated failures, partition for large distributed workloads.
10. Cost Model
EC2 cost depends on instance type, runtime, operating system, Region, storage, data transfer, and purchasing option.
On-Demand is flexible and good for unpredictable workloads. Reserved Instances and Savings Plans reduce cost for committed usage. Spot Instances are much cheaper but can be interrupted, so they fit stateless, fault-tolerant, or batch workloads. Dedicated Hosts and Dedicated Instances support certain compliance or licensing needs.
Right sizing matters. Oversized instances waste money. Under-sized instances cause performance problems. Auto Scaling can align capacity with demand, but poorly chosen scaling policies can also create cost surprises.
EBS volumes, snapshots, elastic IP addresses when unused, load balancers, NAT gateways, and data transfer can all contribute to the full architecture cost.
12. SAA-C03 Exam Signals
"Application on EC2 needs AWS API access without access keys" points to an IAM role and instance profile.
"Highly available EC2 web tier" points to multiple AZs, an Auto Scaling group, and a load balancer.
"Reduce cost for interruptible batch jobs" points to Spot Instances.
"Predictable steady usage" points to Savings Plans or Reserved Instances.
"Need persistent block storage attached to an instance" points to EBS.
"Need shared file storage for multiple EC2 instances" points to EFS, not EBS.
"Avoid opening SSH to the internet" points to Systems Manager Session Manager or bastion patterns with tight controls.
13. Common Exam Traps
Do not put long-lived AWS credentials on an instance. Use roles.
Do not use instance store for durable data.
Do not assume one large EC2 instance is highly available. Use multiple instances across AZs.
Do not put databases on EC2 when the requirement emphasizes low operational overhead and a managed relational service fits.
Do not confuse EBS and EFS. EBS is block storage attached within an AZ. EFS is a managed file system that can be mounted by multiple clients.
Do not choose Spot Instances for workloads that cannot tolerate interruption.
15. Related Topics
Before going deeper, make sure the VPC Networking Model and IAM Foundations are clear. EC2 combines both.
Next, study Amazon S3 and Amazon RDS. Most EC2 architectures externalize object storage and relational data into those services.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.