Compute · Prasanta Kumar Behera

EC2 from a platform engineer's view: choosing instance types, launch templates and Auto Scaling groups, Spot capacity, IMDSv2 and why it matters for containers, bootstrapping with user data, and shell access without SSH.

Instances: pick by shape

EC2 instance names encode the family and generation: m7g.large = general purpose (m), generation 7, g = Graviton (ARM), size large.

Family	Shape	Typical use
m	Balanced CPU:memory (1:4)	General workloads, Kubernetes nodes
c	Compute-heavy (1:2)	CPU-bound services, batch
r	Memory-heavy (1:8)	Caches, in-memory databases
t	Burstable (CPU credits)	Low steady load; avoid for busy nodes
g / p	GPU	ML training and inference
i	Local NVMe	High-IOPS databases, caches

Graviton (ARM) instances usually give better price-performance. Your container images must be built for arm64 (multi-arch images).

Choosing an instance is like picking a vehicle for a job. A van for general deliveries (m), a sports car for speed (c), a lorry for huge loads (r), a scooter for short trips (t), and a crane for special heavy lifting (GPU). Spot instances are rental cars at a big discount, but the company can ask for them back with two minutes' notice.

Launch templates and Auto Scaling groups

A launch template is the recipe: AMI, instance type(s), security groups, IAM instance profile, user data, metadata options, disks. An Auto Scaling group (ASG) keeps N instances from that recipe running across AZs, replaces unhealthy ones, and scales between min and max.

Health checks: EC2 status, or load-balancer health (more meaningful for apps).
Instance refresh rolls instances onto a new template version gradually. It's how immutable node updates work.
For Kubernetes nodes, EKS managed node groups and Karpenter manage this for you (see Amazon EKS in Production).

Spot capacity

Spot instances use spare capacity at large discounts, with a two-minute interruption notice.

Use for stateless, fault-tolerant work: web replicas, CI runners, batch jobs.
Diversify across many instance types and AZs to reduce interruptions.
Handle the notice: drain the node (Karpenter and the AWS Node Termination Handler do this for Kubernetes).

IMDSv2: protect instance credentials

The instance metadata service (IMDS, at 169.254.169.254) gives the instance its role credentials. IMDSv1 answered any GET request, so an SSRF bug in an app could leak credentials. IMDSv2 requires a session token obtained with a PUT request, and a hop limit:

$ TOKEN=$(curl -sX PUT http://169.254.169.254/latest/api/token -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
$ curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id
i-0123456789abcdef0

Require IMDSv2 in launch templates (HttpTokens: required). On Kubernetes nodes, a hop limit of 1 stops pods from reaching the node's credentials. Pods should use their own identity (Pod Identity/IRSA) instead.

Bootstrapping and access

User data (usually processed by cloud-init) runs at first boot: install agents, join a cluster. Keep it small; bake the rest into the AMI (Packer image pipelines).
SSM Session Manager: shell access through the AWS API with IAM control and session logging. No SSH keys, no open port 22, no bastion.

Try it: an immutable, secure ASG (sandbox account)

Create a launch template: Amazon Linux or Ubuntu AMI, t4g.small (or t3.small), an instance profile with AmazonSSMManagedInstanceCore, IMDSv2 required, user data that installs nginx.
Create an ASG (min 2, max 4) across two private subnets behind a target group.
Connect with aws ssm start-session; confirm the IMDSv1 call (curl http://169.254.169.254/latest/meta-data/) fails and the IMDSv2 call works.
Change the user data (e.g. a different nginx page), create a new template version, and run an instance refresh. Watch instances replaced gradually.
Terminate one instance manually and watch the ASG replace it. Clean up afterwards.

Going deeper: compute at scale

Use Savings Plans for steady baseline capacity and Spot for elastic capacity; right-size before committing (lesson 07).
Build golden AMIs in CI with hardening applied (see Linux, lesson 18); roll them with instance refresh or node group updates.
Use placement groups only for specific needs (low-latency clusters or spread for HA).
Tag every instance (owner, environment, cost centre) through launch templates, and enforce it with SCPs or policies.

Recap

Pick instance families by shape; consider Graviton with multi-arch images.
Launch templates + ASGs give self-healing, scalable, immutable fleets; instance refresh rolls updates.
Spot is cheap but interruptible: diversify and drain.
Require IMDSv2 (hop limit 1 for container hosts); prefer SSM Session Manager to SSH.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.