Elastic Compute Service (ECS)
What ECS is made of
An ECS instance is defined by instance type (vCPU/memory family: general, compute-optimized, memory-optimized, GPU), image (public, custom, shared, marketplace), system disk and data disks, network (VPC vSwitch, private IP, optional public IP/EIP), and security group. Instance families map to workload shape; picking the wrong family is a performance and cost error.
Billing models
- Subscription - prepaid, cheapest for steady long-running workloads.
- Pay-as-you-go - hourly/second-level, flexible, most expensive per unit.
- Spot (preemptible) - deep discount, can be reclaimed; only for fault-tolerant, checkpointed work.
Images and lifecycle
Custom images capture the OS and installed software; they are the standard way to bake golden images for Auto Scaling. Snapshots back up disks, not instances. Remember: stopping an instance may still incur storage and EIP charges; releasing it stops compute billing but destroys ephemeral data unless disks are retained.
Traps
- Confusing security group (stateful, instance-level virtual firewall, allow-only) with network ACL (stateless, subnet-level, allow and deny).
- Assuming a public IP assigned at creation is permanent - classic public IPs are released with the instance; use an EIP for a durable address.
- Forgetting that instance metadata service can be a credential-exposure vector if not restricted.
Rule of thumb
Match family to bottleneck: CPU-bound → compute-optimized; memory-heavy caches/DBs → memory-optimized; balanced web apps → general purpose. Use subscription for baseline capacity and pay-as-you-go or spot for burst.
Worked example
A batch renderer runs 6 hours nightly and can restart. Spot instances plus a checkpoint to OSS are appropriate; a 24/7 database should use subscription general/memory-optimized instances with data disks on ESSD.