Amazon EC2
Amazon EC2
Resizable virtual servers with full control of the OS — but that control comes bundled with everything it implies: architecture lock-in at launch, quota pools that do not share capacity the way the dashboard suggests, and a maintenance lifecycle AWS runs on its own schedule, not yours. Eight pages, in the order the decisions actually depend on each other — start at one, not wherever looks interesting.
x86_64 and Graviton (ARM64) are genuinely different processor architectures, not a config flag — an instance running one can't be "upgraded in place" to the other. AMIs are architecture-specific, so switching means launching a new instance from an architecture-matched AMI, not resizing an existing one.
Reserved Instances commit to a specific instance family, size, region, OS, and tenancy in exchange for up to ~72% off On-Demand. Savings Plans commit to a dollar-per-hour spend instead of a specific configuration, trading some discount depth (Compute Savings Plans top out lower, though EC2 Instance Savings Plans match RI's ~72% within one family/region) for coverage that follows your usage instead of locking you to a resource shape.
Spot Instances trade guaranteed availability for savings up to 90% off On-Demand — while running, a Spot Instance is identical to On-Demand in every way except one: AWS can reclaim it back with a two-minute warning whenever it needs the capacity.
Every EC2 instance gets at least one Elastic Network Interface with a private IP, and optionally a public IP or an Elastic IP — a client-visible network identity that other systems (DNS records, security group rules, allowlists, load balancer targets) come to depend on, whether or not that was the intent.
EC2 quotas are vCPU-based, regional, and pooled by instance-family group, not per instance type — Standard families (A, C, D, H, I, M, R, T, Z) share one combined quota, while G/VT, P, F, and X families each have their own separate pool. That list isn't complete: Trn (Trainium), Inf (Inferentia), DL (Deep Learning), High Memory (the u-* family), and HPC-optimized families each draw from their own dedicated pool too, independent of Standard and of each other. On-Demand and Spot draw from entirely separate quota pools as well.
EC2 runs two structurally different status checks. System status checks monitor the underlying AWS hardware/host; instance status checks monitor the instance's own OS, network config, and resource usage. Automatic recovery — EC2's built-in "fix it for me" mechanism — only responds to system status check failures, and (since April 2022) simplified automatic recovery is enabled by default on every supported instance type at launch — it's not something you opt into via a CloudWatch alarm. "Supported" is doing real work in that sentence, though: simplified automatic recovery isn't available at all for instance-store-backed or bare-metal instances — there's no mechanism to migrate physically-attached local storage to new hardware, so those instances have no automatic path back after a system-level failure, default-on or not.
AWS schedules maintenance events (stop, reboot, retirement) on instances for hardware degradation or fleet-wide hardware retirement, notifying you in advance by email and the console. What "retirement" actually does to your instance depends entirely on storage type, and that's not a detail — it's the whole guardrail. It's also the same fact that decided whether automatic recovery applies at all on the failure-mode page before this one — one variable (EBS-backed vs. instance-store-backed) that quietly sets the guardrail on two separate facets, not a coincidence between two unrelated pages.
EC2 buys full control over the OS and runtime at the cost of owning everything that control implies — patching, capacity planning, scaling configuration. Lambda and Fargate both trade that control away specifically to remove operational overhead, and the question of which fits isn't "which is more modern" but which unit of scale matches the actual load pattern.