Amazon EC2

Definition

Amazon Elastic Compute Cloud (EC2) is AWS’s foundational virtual server service. You launch instances — VMs with configurable CPU, memory, networking, and storage — inside a VPC, attach EBS volumes or instance store, and pay by the second for On-Demand or commit for Savings Plans and Reserved Instances. EC2 remains the default when you need full OS control, long-running processes, licensed software, or hardware profiles (GPU, local NVMe, bare metal) that serverless and container services cannot expose cleanly.

Instance choice drives both performance and bill. As of mid-2026, Graviton4 families (M8g, C8g, R8g) and the newer Graviton5 M9g line deliver strong price-performance on ARM64 Linux; m7g/c7g/r7g remain common in existing fleets. Match family to workload: general purpose (M/T), compute (C), memory (R/X), storage (I/D), and accelerated (P/G/Trn) for ML and graphics.

When to use it

• You need a persistent VM with SSH/RDP access, custom kernel modules, or vendor software tied to sockets/cores.
• Workloads run 24/7 with predictable baseline CPU — Savings Plans or RIs on M/R families usually beat Lambda or Fargate on unit economics.
• You require specialized hardware: GPU inference, Trn for training, high local NVMe for databases, or Dedicated Hosts for license compliance.
• Auto Scaling groups behind an ALB/NLB for stateless web tiers, batch queues on Spot, or CI runners that tolerate interruption.

When not to use it

• Event-driven, spiky, or sub-15-minute jobs — Lambda or Fargate remove patching and capacity planning.
• You only need containers and accept Kubernetes ops — EKS with Karpenter or Auto Mode may be simpler than hand-managing ASGs.
• Minimal traffic dev/test boxes left running overnight — idle On-Demand instances are the most common FinOps leak on new AWS accounts.

Tips

• Benchmark Graviton (m7g/m8g/m9g) before defaulting to x86; most Java, Python, Node.js, Go, and .NET on Linux builds run ARM64 with 20–40% better $/perf on equivalent sizes.
• Use Compute Optimizer plus two weeks of CloudWatch CPUUtilization, NetworkIn/Out, and EBS VolumeRead/WriteOps before right-sizing; one size down on memory often saves more than CPU tweaks.
• Split baseline vs burst: cover steady On-Demand hours with Compute Savings Plans; put fault-tolerant batch/CI on Spot with diversified instance pools and capacity-optimized allocation.
• Enable IMDSv2 required on launch templates and use instance profiles — never bake long-lived access keys into AMIs.
• Pair production ASGs with ELB health checks and a minimum healthy percentage during deployments; replace in-place SSH deploys with golden AMIs or container pulls.

Gotchas

• Serious: A single oversized On-Demand instance in the wrong AZ without Multi-AZ failover becomes a silent single point of failure — combine ASG across ≥2 AZs and test failover before calling the tier “HA.”
• Serious: T-class CPU credits exhaust under sustained load; production on db.t* analogs or t3/t4g without unlimited mode throttles hard with no obvious CloudWatch alarm unless you watch CPUCreditBalance.
• Regular: EBS gp3 defaults to 3,000 IOPS — heavy databases on gp3 without provisioned IOPS look “slow” while CPU graphs stay green.
• Regular: Elastic IP attached to a stopped instance still bills — release or reassign idle EIPs during cost reviews.
• Regular: Changing instance type often requires stop/start (not reboot) to pick up new network or ENA limits; schedule maintenance windows accordingly.

Official references

• EC2 Auto Scaling — target tracking and predictive scaling patterns.
• Graviton best practices — porting and benchmark checklist for ARM64.

Related FactualMinds content

• Cloud Cost Optimization Services
• FinOps Consulting
• AWS Well-Architected Review Checklist
• AWS Serverless Services — when EC2 is not the right fit