Cargando...
Cargando...
Resizable virtual servers in the cloud — the backbone of AWS compute workloads
Amazon Elastic Compute Cloud (EC2) provides scalable, on-demand virtual machine capacity in the AWS Cloud, letting you launch instances with your choice of CPU, memory, storage, and networking. EC2 eliminates the need to invest in hardware upfront, enabling you to develop and deploy applications faster with full control over the underlying compute environment. It supports a vast range of instance types, purchasing options, and integrations, making it the foundational compute service for virtually every AWS architecture.
To provide flexible, scalable, and fully configurable virtual compute capacity for running any workload — from simple web servers to high-performance computing clusters — without managing physical hardware.
Use When
Avoid When
Instance Types (700+ variants across families)
General Purpose (M, T), Compute Optimized (C), Memory Optimized (R, X, U), Storage Optimized (I, D, H), Accelerated Computing (P, G, Inf, Trn)
Auto Scaling (EC2 Auto Scaling Groups)
Scale out/in based on CloudWatch metrics, schedules, or predictive scaling
Elastic Load Balancing integration
Works with ALB, NLB, CLB, and GWLB for traffic distribution
Spot Instances
Up to 90% discount vs On-Demand; interruptible with 2-minute notice
Reserved Instances
1 or 3-year commitment; Standard and Convertible types
Savings Plans
Compute Savings Plans (EC2+Lambda+Fargate) and EC2 Instance Savings Plans
Dedicated Hosts
Physical server dedicated to your use; required for BYOL per-socket/per-core licensing
Dedicated Instances
Isolated on dedicated hardware but no host-level control or BYOL socket/core visibility
Placement Groups (Cluster, Spread, Partition)
Cluster: low latency same AZ; Spread: max 7/AZ fault isolation; Partition: large distributed systems
Elastic Network Interfaces (ENI)
Multiple ENIs per instance; useful for network appliances and dual-homed instances
Elastic IP Addresses (EIP)
Static public IPv4; charged when unattached or attached to stopped instance
EC2 Instance Connect
Browser-based SSH without managing SSH keys; uses IAM for access control
AWS Systems Manager Session Manager
No SSH/RDP port required; full audit trail via CloudTrail; preferred for compliance
User Data (bootstrap scripts)
Runs once at launch (by default); can be re-run with cloud-init configuration
Instance Metadata Service (IMDSv1 and IMDSv2)
IMDSv2 is session-based and more secure; IMDSv1 is legacy and SSRF-vulnerable
Hibernate
Saves RAM to EBS root volume; instance resumes faster than full restart; root volume must be encrypted
EC2 Nitro System
Next-gen virtualization platform; enables bare-metal performance, ENA networking, NVMe storage
Bare Metal Instances
Direct hardware access; no hypervisor overhead; required for VMware Cloud on AWS
Amazon Machine Images (AMI)
Regional resource; supports EBS-backed and instance store-backed; can be shared cross-account
EBS Volume Types (gp2, gp3, io1, io2, st1, sc1)
gp3 is current default; io2 Block Express for highest IOPS; st1/sc1 for throughput-optimized/cold HDD
Instance Store (ephemeral storage)
Physically attached NVMe; extremely fast; data lost on stop/terminate/host failure
Elastic Fabric Adapter (EFA)
Low-latency networking for HPC/ML; supports OS-bypass for MPI workloads
Enhanced Networking (ENA)
Higher bandwidth, lower latency, lower jitter; supported on Nitro instances
EC2 Fleet and Spot Fleet
Launch multiple instance types/AZs in a single request; optimize for cost or capacity
Capacity Reservations (On-Demand)
Reserve capacity in specific AZ without commitment; pay On-Demand rate regardless of use
Scheduled Instances (legacy)
Deprecated; use Capacity Reservations or Auto Scaling with scheduled actions instead
EC2 Image Builder
Automated AMI creation pipeline with OS hardening, patching, and testing
AWS Compute Optimizer integration
ML-based right-sizing recommendations for EC2 instances based on CloudWatch metrics
IPv6 support
Supported in VPCs; instances can have both IPv4 and IPv6 addresses
Burstable Performance (T-family with CPU Credits)
T3/T4g earn credits when below baseline; spend credits when bursting; unlimited mode available at extra cost
Dynamic and Predictive Scaling
high freqEC2 Auto Scaling Groups automatically add or remove EC2 instances based on CloudWatch alarms (dynamic scaling) or ML-predicted load (predictive scaling). Use target tracking policies for simplest configuration (e.g., maintain 60% CPU utilization). Critical for cost optimization and availability in exam scenarios.
Static Asset Offload and Data Lake Access
high freqEC2 instances use IAM roles (not access keys) to access S3 buckets for storing logs, application artifacts, ML training data, or static assets. S3 Transfer Acceleration or VPC Gateway Endpoints eliminate data transfer costs for S3 access from EC2 within the same region.
Web/App Tier to Managed Database
high freqEC2 application servers connect to RDS via security groups (EC2 SG as source in RDS SG inbound rule — no IP hardcoding). RDS should be in private subnets with no public access. Use RDS Proxy for connection pooling with Lambda or high-concurrency EC2 workloads.
EC2 Launch Type for Containers
high freqECS can run containers on EC2 instances (EC2 launch type) giving you control over instance type, placement, and cost optimization via Spot. The ECS agent runs on each EC2 instance. Use this when you need GPU instances, specific networking, or cost control that Fargate doesn't provide.
Hybrid Compute — EC2 for Long-Running, Lambda for Event-Driven
high freqArchitect stateful, long-running workloads on EC2 and trigger Lambda for event-driven processing (S3 events, API Gateway, SQS). Lambda can invoke EC2 APIs via SDK to start/stop instances for cost optimization. EC2 and Lambda can communicate via SQS queues for decoupled processing.
Session State and Low-Latency Data Store
high freqEC2 app servers use DynamoDB for session state storage (enabling stateless EC2 instances behind ALB), shopping carts, or leaderboards. Use VPC Endpoint (Gateway type, free) for DynamoDB access from EC2 to avoid internet traffic and reduce latency.
High Availability Web Architecture
high freqALB distributes HTTP/HTTPS traffic across EC2 instances in multiple AZs. NLB handles TCP/UDP at ultra-low latency. EC2 instances registered as targets in Target Groups. Health checks automatically remove unhealthy instances. Combined with Auto Scaling for the classic HA pattern.
Patch Management and Secure Access
high freqSSM Agent on EC2 enables Patch Manager, Session Manager (no SSH ports needed), Run Command, and Parameter Store integration. Preferred over SSH for compliance-heavy environments. Requires SSM IAM role on EC2 instance and either internet access or VPC endpoints for SSM.
Monitoring, Alerting, and Auto Scaling Triggers
high freqCloudWatch collects EC2 metrics (CPU, network, disk — basic monitoring every 5 min free, detailed monitoring every 1 min at cost). Custom metrics (memory, disk utilization) require CloudWatch Agent. Alarms trigger Auto Scaling actions, SNS notifications, or EC2 actions (stop/terminate/recover).
Instance Profiles and Roles
high freqEC2 instances assume IAM roles via Instance Profiles to access AWS services without embedding credentials. The IAM role credentials are delivered via IMDS (169.254.169.254) and auto-rotated. NEVER store long-term access keys on EC2 instances — use roles. This is both a security best practice and a frequent exam scenario.
Network Isolation with Public/Private Subnets
high freqClassic 3-tier: public subnet (ALB, NAT Gateway), private subnet (EC2 app servers), isolated subnet (RDS). EC2 in private subnets access internet via NAT Gateway. Security groups act as instance-level firewalls (stateful); NACLs as subnet-level (stateless). VPC Flow Logs capture traffic metadata.
EC2 On-Demand vCPU limits are per instance FAMILY (e.g., Standard instances, High Memory instances), NOT per instance type or per total instance count. When you hit a limit, you request more vCPUs for that family via Service Quotas — not more instances.
Spot Instance interruption gives exactly 2 minutes notice. Design Spot-based architectures to checkpoint state, drain connections, or use Spot with On-Demand fallback via EC2 Fleet or Auto Scaling with mixed instance policies. Spot is NOT suitable for databases or stateful workloads without a checkpointing strategy.
Dedicated Hosts vs. Dedicated Instances: If the question mentions BYOL (Bring Your Own License) for software licensed per-socket or per-core (Windows Server, SQL Server, Oracle), the answer is ALWAYS Dedicated Hosts. Dedicated Instances provide hardware isolation but NOT socket/core visibility needed for BYOL.
IMDSv2 is session-oriented (requires PUT request to get token, then GET with token). IMDSv1 is a simple GET and is vulnerable to SSRF attacks. For security-focused questions, enforce IMDSv2 using 'HttpTokens: required' in instance metadata options or via Service Control Policy (SCP) to deny IMDSv1 across the org.
EC2 memory and disk utilization metrics are NOT available in CloudWatch by default. You must install and configure the CloudWatch Agent on the instance. This is a very common exam trap — default EC2 metrics only cover CPU, network I/O, and disk I/O (not utilization percentages for memory/disk).
Placement Groups — know the hard limits: Spread placement group = max 7 running instances per AZ per group. Cluster placement group = same AZ, same rack, lowest latency but single point of failure for the rack. Partition placement group = up to 7 partitions per AZ, each partition on distinct hardware, used for HDFS/Cassandra/Kafka.
Security groups are STATEFUL — if you allow inbound traffic on port 80, the return traffic is automatically allowed regardless of outbound rules. NACLs are STATELESS — you must explicitly allow both inbound AND outbound rules for each traffic flow. Ephemeral ports (1024-65535) must be allowed in NACL outbound rules for return traffic.
BYOL per-socket/per-core licensing ALWAYS requires Dedicated Hosts (not Dedicated Instances). Dedicated Instances only provide hardware isolation without host-level visibility. When you see 'BYOL' + 'per socket' or 'per core' in a question, the answer is Dedicated Hosts.
CloudWatch does NOT collect EC2 memory or disk utilization by default. You MUST install the CloudWatch Agent to publish these as custom metrics. Default metrics only cover CPU, network I/O, disk I/O bytes/ops, and status checks. This is the #1 monitoring trap on EC2 exam questions.
EC2 On-Demand limits are measured in vCPUs per instance family (since 2020), not total instance count. Spot limits are also vCPU-based. When a question describes hitting EC2 limits, think 'request vCPU quota increase for that instance family via Service Quotas' — not 'request more instances.'
gp3 vs gp2 EBS: gp3 provides 3,000 IOPS baseline and 125 MB/s throughput regardless of volume size, and IOPS/throughput are independently configurable. gp2 ties IOPS to size (3 IOPS/GB). For cost optimization questions, gp3 is almost always cheaper than gp2 at the same IOPS level. gp3 is now the AWS-recommended default.
EC2 Hibernate: RAM contents are saved to the EBS root volume (which must be encrypted). The instance 'appears' to resume faster because the OS and applications don't need to restart. Use cases: long-running processes that take time to initialize, pre-warming instances. Root volume must have enough free space to store RAM.
Convertible RIs can be exchanged for other Convertible RIs of equal or greater value — you can change instance family, OS, tenancy, and payment option. However, Convertible RIs CANNOT be sold on the Reserved Instance Marketplace (only Standard RIs can). This distinction appears in cost optimization and flexibility questions.
Compute Savings Plans apply to EC2 (any family, size, region, OS, tenancy), AWS Lambda (per-request and duration charges), and AWS Fargate — making them the most flexible commitment option. EC2 Instance Savings Plans apply only to a specific instance family in a region but offer the highest discount (up to 72%). Know which to recommend for flexibility vs. max savings.
EC2 Auto Scaling lifecycle hooks allow you to perform custom actions during instance launch (pending:wait state) or termination (terminating:wait state). Use cases: install software, register with external systems, drain connections. The hook has a heartbeat timeout (default 1 hour) after which the instance proceeds to the next state.
When an EC2 instance is STOPPED (not terminated), you are NOT charged for compute (per-second billing stops). However, you ARE still charged for: EBS volumes attached, Elastic IPs associated with the stopped instance (pre-Feb 2024 — now all public IPs are charged), and any data in instance store is LOST on stop.
For the SAP-C02 and DOP-C02 exams: EC2 Image Builder automates the creation, testing, and distribution of AMIs. It integrates with AWS Organizations for cross-account AMI sharing, supports CIS benchmarks and STIG hardening, and can distribute AMIs to multiple regions automatically. This replaces manual AMI baking pipelines.
Common Mistake
Amazon Lightsail is just a simpler version of EC2 with the same enterprise-scale auto-scaling capabilities
Correct
Lightsail is a separate, simplified VPS service designed for small workloads with fixed monthly pricing. It does NOT provide the same Auto Scaling capabilities as EC2 Auto Scaling Groups, does not integrate natively with the full suite of AWS services (VPC, ALB, etc.), and has significant feature and scale limitations compared to EC2.
Exam questions often present Lightsail as a valid solution for enterprise workloads requiring dynamic scaling. The correct answer will always be EC2 + Auto Scaling for enterprise-grade, dynamically scaling architectures. Lightsail is for developers who want simplicity over control.
Common Mistake
EC2 instances automatically recover from all failures — AWS manages disaster recovery for you
Correct
EC2 provides tools for resilience (Auto Scaling, Multi-AZ deployments, CloudWatch EC2 auto-recovery for system failures), but YOU are responsible for designing HA/DR architectures. Auto-recovery only works for certain failure types (system impairment, not instance failures). You must configure Multi-AZ, backups, and failover — they are not automatic.
This reflects the AWS Shared Responsibility Model. AWS manages the physical infrastructure, but the customer is responsible for application-level HA, data backups, and DR planning. Exam questions test whether you know what AWS does automatically vs. what requires customer configuration.
Common Mistake
Stopping and starting an EC2 instance is the same as rebooting it — the instance stays on the same physical host
Correct
REBOOT keeps the instance on the same host (instance store data preserved, same private IP). STOP/START moves the instance to a NEW physical host (instance store data LOST, same private IP in VPC, Elastic IP preserved if associated, but public IP changes if no EIP). This distinction is critical for understanding data loss scenarios.
Candidates often assume stop/start is safe for instance store data. It is not. Any data on instance store (ephemeral) volumes is permanently lost when an instance is stopped or terminated. Only EBS-backed data persists across stop/start cycles.
Common Mistake
You can use Dedicated Instances for BYOL software licensed per socket or per core
Correct
Dedicated Instances provide hardware isolation (your instances don't share physical hardware with other AWS accounts) but do NOT give you visibility into the number of physical sockets or cores on the host. BYOL for per-socket/per-core licensed software (SQL Server, Windows Server, Oracle) REQUIRES Dedicated Hosts, which provide full host-level visibility and control.
This is one of the most tested EC2 misconceptions. The key differentiator: Dedicated Instances = isolation only. Dedicated Hosts = isolation + host visibility + BYOL support. When you see 'BYOL' and 'per socket/core' in an exam question, immediately think Dedicated Hosts.
Common Mistake
CloudWatch automatically monitors EC2 memory utilization and disk usage percentage
Correct
CloudWatch default EC2 metrics include CPU utilization, network in/out, disk read/write bytes and ops (for instance store), and status checks. Memory utilization, disk space utilization percentage, and swap usage are NOT collected by default. These require the CloudWatch Agent (formerly CloudWatch Logs Agent) to be installed and configured on the instance.
This is a top-5 EC2 exam trap. Whenever a question asks about monitoring memory or disk space on EC2, the answer involves installing the CloudWatch Agent and publishing custom metrics. The CloudWatch Agent also enables collecting application logs.
Common Mistake
T-series instances (T2, T3, T4g) always perform at their full advertised CPU capacity
Correct
T-series instances are burstable performance instances. They earn CPU credits when running below their baseline CPU utilization and spend credits when bursting above baseline. If credits are exhausted (in standard mode), CPU is throttled to baseline. In 'unlimited' mode, the instance can burst beyond credits but you pay extra for surplus credits used.
Exam questions present scenarios where a T2/T3 instance suddenly degrades in performance. The answer is often CPU credit exhaustion. The fix is either switching to unlimited mode, right-sizing to a non-burstable instance (M or C family), or enabling T3 unlimited. Know that t2.micro is free tier eligible but t3.micro is more efficient.
Common Mistake
Spot Instances are always cheaper than Reserved Instances for predictable workloads
Correct
Spot Instances offer the highest discount (up to 90%) but can be interrupted at any time with only 2-minute notice. For predictable, steady-state workloads that cannot tolerate interruption, Reserved Instances or Savings Plans provide guaranteed capacity and significant discounts (up to 72%) without interruption risk. Spot is best for fault-tolerant, flexible, or stateless workloads.
Cost optimization questions require matching the right purchasing option to the workload characteristics. The decision framework: Spot = interruptible/flexible. RI/Savings Plans = steady-state/predictable. On-Demand = short-term/unpredictable. Dedicated = compliance/BYOL.
Common Mistake
An IAM role attached to an EC2 instance requires the application to manually retrieve and refresh credentials from the metadata service
Correct
The AWS SDKs and CLI automatically retrieve and refresh temporary credentials from the EC2 Instance Metadata Service (169.254.169.254) when an IAM role is attached via an Instance Profile. Applications using the AWS SDK do not need to manually manage credential refresh — the SDK credential provider chain handles this automatically.
This misconception leads candidates to incorrectly suggest storing long-term credentials on EC2 instances or writing custom credential refresh code. The correct best practice is always: attach IAM role → use SDK → credentials are auto-managed. Never embed access keys on EC2.
STOP vs REBOOT: 'S' = Shift to new host (Stop loses instance store, public IP changes). 'R' = Remains on same host (Reboot keeps instance store, same IPs).
Placement Groups — 'CSP' = Cluster (Close together, same rack, speed), Spread (Separated, 7 max/AZ, safety), Partition (Parts of a distributed system like HDFS).
EC2 Purchasing Options — 'SORDC': Spot (cheapest, interruptible), On-Demand (flexible, no commitment), Reserved (steady-state, commitment), Dedicated Instance (isolated, no BYOL), Capacity Reservation (guaranteed capacity, no discount alone).
Dedicated Hosts vs Instances: 'HOST = Hardware visiblity, Own-socket licensing, Specific placement, BYOL-ready'. Dedicated Instances just give you isolation — nothing more.
EBS Types: 'GP3 = Goldilocks Performance 3' — just right for most workloads, independently configurable IOPS/throughput, cheaper than gp2.
IMDSv2 = 'PUT before GET' — you must PUT a request to get a session token, then GET with that token. This prevents SSRF attacks that can only make GET requests.
Security Groups vs NACLs: 'SG = Stateful Guardian' (remembers return traffic). 'NACL = Not A Clue about return traffic' (stateless, must explicitly allow both directions).
CertAI Tutor · DOP-C02, SAA-C03, SAP-C02, DEA-C01, CLF-C02, DVA-C02 · 2026-02-21
In the Same Category
Comparisons