Elastic Compute Service (ECS)
Core concepts
ECS instances are defined by instance family (general, compute-optimized, memory-optimized, GPU), vCPU/memory ratio, image (public, custom, shared, marketplace), system disk and data disks, and network type (VPC only in modern designs). Security groups are stateful virtual firewalls attached to instances; key pairs replace passwords for SSH and are region-scoped.
Understand lifecycle controls: start/stop/restart, auto-renewal, and the distinction between stopping (compute released, disks retained) and releasing (resources deleted). User data runs at first boot for automation. Instance metadata exposes instance identity to the guest. Auto Scaling adjusts capacity using scaling groups, scaling configurations, and scaling rules/alarms.
Traps in questions
- Security group default deny: inbound is denied unless allowed; outbound is allowed by default. Security groups are allow-only rules-there are no explicit deny rules.
- Security group vs. network ACL: security groups are stateful and instance-level; network ACLs are stateless and subnet-level.
- Stopping vs. releasing: stopping preserves disks and IP assignment (within limits); releasing destroys data unless snapshots exist.
- Key pair scope: a key pair is bound to a region; it is not global.
- Scaling vs. load balancing: Auto Scaling adds/removes instances; SLB distributes traffic. You usually need both.
Rule of thumb
For any stateless web tier, pair Auto Scaling with an SLB behind a multi-zone VPC, and keep state in a managed database or OSS rather than on instance local disk.
Worked example
An application must survive the loss of one zone and scale with demand. Deploy instances in two zones via a scaling group, attach them to an SLB with health checks, and store uploads in OSS. A single large instance is cheaper but fails the availability requirement.