---
title: Amazon EC2
description: Amazon Elastic Compute Cloud — scalable virtual server infrastructure for running applications in the AWS cloud.
url: https://www.factualminds.com/glossary/amazon-ec2/
publishDate: 2026-06-13
updateDate: 2026-06-13
---

# Amazon EC2

> Amazon Elastic Compute Cloud — scalable virtual server infrastructure for running applications in the AWS cloud.

## 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.

| Family                   | Optimized for              | Examples (2026)                       |
| ------------------------ | -------------------------- | ------------------------------------- |
| General purpose (M, T)   | Balanced CPU/memory        | m7g.large, m8g.xlarge, t4g.micro      |
| Compute optimized (C)    | CPU-bound workloads        | c7g.2xlarge, c8g.4xlarge              |
| Memory optimized (R, X)  | In-memory DBs, caches      | r7g.4xlarge, r8g.8xlarge              |
| Storage optimized (I, D) | High IOPS, local NVMe      | i4i.xlarge, i8g.2xlarge               |
| Accelerated (P, G, Trn)  | ML training/inference, GPU | p5.48xlarge, g6.xlarge, trn2.48xlarge |

## 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](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) — target tracking and predictive scaling patterns.
- [Graviton best practices](https://github.com/aws/aws-graviton-getting-started) — porting and benchmark checklist for ARM64.

## Related FactualMinds content

- [Cloud Cost Optimization Services](/services/aws-cloud-cost-optimization-services/)
- [FinOps Consulting](/services/finops-consulting/)
- [AWS Well-Architected Review Checklist](/blog/aws-well-architected-framework-6-pillars-explained/)
- [AWS Serverless Services](/services/aws-serverless/) — when EC2 is not the right fit

## Related AWS Services

- aws-serverless
- finops-consulting
- aws-cloud-cost-optimization-services

## Related Posts

- aws-well-architected-framework-6-pillars-explained

---

*Source: https://www.factualminds.com/glossary/amazon-ec2/*