Amazon EC2
Amazon EC2
Resizable virtual servers with full control of the OS. That control comes bundled with everything it implies. The processor architecture is locked in at launch and is never a later resize. The quota pools do not share capacity the way the dashboard suggests. And AWS runs the maintenance lifecycle on its own schedule, not yours. AWS will stop, reboot, or retire instances when the hardware needs it, and what that does to your data depends on choices made earlier. 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, so an instance running one can't be "upgraded in place" to the other. The architecture is decided at launch and stays decided.
The reason is the AMI. AMIs are architecture-specific: an image built for one architecture boots on that architecture and nothing else. Switching means launching a new instance from an architecture-matched AMI. There is no in-place path between the two.
The two commitment options for EC2 are Reserved Instances and Savings Plans, and they commit to different things.
A Reserved Instance commits to a specific configuration: instance family, size, region, OS, and tenancy. In exchange you get up to ~72% off On-Demand for that exact shape.
A Savings Plan commits to a dollar-per-hour spend instead. Any eligible usage counts toward the commitment, whatever shape it runs in, so the coverage follows your usage and nothing in the commitment is tied to a resource shape. The discount is a bit shallower: Compute Savings Plans top out lower, though EC2 Instance Savings Plans match RI's ~72% within one family/region.
Spot Instances trade guaranteed availability for savings of up to 90% off On-Demand. While a Spot Instance is running, it is identical to On-Demand in every way. Same machine class, same performance, same network.
There is exactly one difference, and it only shows up when AWS needs the capacity back: AWS can reclaim the instance at that moment. You get a two-minute warning when it does.
Every EC2 instance gets at least one Elastic Network Interface — its virtual network card — carrying a private IP. It can optionally carry a public IP or an Elastic IP, and an Elastic IP is a public address you hold separately from the instance.
Whatever address faces outward becomes the instance's network identity as clients see it. Other systems come to depend on it: DNS records, security group rules, allowlists, load balancer targets. They depend on it whether or not that was the plan.
EC2 quotas are vCPU-based, regional, and pooled by instance-family group. The pool is not per instance type, and that detail is where the surprises come from.
The Standard families — A, C, D, H, I, M, R, T, Z — all share one combined quota. G/VT, P, F, and X families each have their own separate pool.
That list is not complete either. Trn (Trainium), Inf (Inferentia), DL (Deep Learning), High Memory (the u-* family), and HPC-optimized families each draw from their own dedicated pool, independent of Standard and of each other.
One more axis: On-Demand and Spot draw from entirely separate quota pools as well.
EC2 runs two structurally different status checks, and which one fails determines what happens next.
System status checks monitor the underlying AWS hardware — the host your instance happens to sit on. Instance status checks monitor the instance itself: its OS, its network config, its resource usage.
Automatic recovery is EC2's built-in "fix it for me" mechanism, and it only responds to system status check failures. Since April 2022, simplified automatic recovery is enabled by default on every supported instance type at launch. You don't opt in through a CloudWatch alarm. It's just on. When the host breaks, EC2 moves the instance to a healthy one for you.
One category is excluded entirely: 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 changes nothing for them.
AWS schedules maintenance events on instances for hardware degradation or fleet-wide hardware retirement. The event types are stop, reboot, and retirement, and you're notified in advance by email and in the console. Retirement is the serious one: it means AWS has decided the hardware under your instance is going away.
What a retirement event actually does to your instance depends entirely on the instance's storage type. That's not a detail. It's the whole guardrail on this page. Storage type is a per-fleet fact, fixed long before any notice arrives.
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 — quietly sets the guardrail on two separate facets. The variable is what links the two pages.
EC2 buys you full control over the OS and the runtime, and the cost side of the bargain is owning everything that control implies. Patching is yours. Capacity planning is yours. Scaling configuration is yours.
Lambda and Fargate make the opposite trade: both give up that control specifically to remove operational overhead.
Which one fits is therefore a question about load, answered in units of scale. Lambda's unit is a single invocation; Fargate's is a running container; EC2's is a whole instance, billed running or idle. The question is which unit of scale matches the actual load pattern — set "which is more modern" aside.