Bottlerocket OS

TL;DR: Container hosts usually run a general-purpose Linux (Amazon Linux, Ubuntu) shipping a package manager, full shell, SSH, and dozens of utilities you never touch — all costing memory, CPU, disk, and attack surface. Bottlerocket is AWS's free, immutable, container-only OS that throws that out: no package manager, no SSH by default (SSM or an admin container instead), atomic updates. The payoff is 30–50% less host overhead — usually enough to drop a full instance size cluster-wide — plus a much smaller CVE surface. It's a launch-template AMI swap.

The numbers

• ~100–200 MB less memory per node at idle, fewer background processes, smaller/faster-booting AMI — the difference between packing one more container per node and, more usefully, dropping to a smaller instance.
• Security: fewer packages = fewer CVEs to triage; no SSH = no SSH attacks; immutable OS = no runtime tampering; incidents are "replace the instance," not "patch and hope."
• Free — you pay only for the instances, which get smaller.
• Field examples: a microservices team dropped t3.large → t3.medium cluster-wide (~35% off compute) with no performance change; a regulated team cut its CVE-triage backlog sharply and unblocked quarterly compliance reviews.

Do this

1. Swap in the pre-built ECS- or EKS-optimized Bottlerocket AMI via the launch template — task definitions and container images don't change.
2. Move userdata into Bottlerocket's settings API — anything that assumed cloud-init/systemd or installed packages on boot goes into container images or the typed settings API instead.
3. Set up SSM Session Manager (and the optional admin container) for troubleshooting before you cut over — the ssh in and yum install reflex won't work.
4. Right-size down after migrating — measure the freed per-node headroom in CloudWatch, then drop one instance size across the cluster (the move most teams make).
5. Pilot on a non-critical cluster for a week, document the access patterns for the team, then standardize; the biggest failure mode is "the one person who knew how to debug it left."

Gotchas

• No package manager, no quick fixes — bake debugging tools into a sidecar or admin container; it's a mindset shift, not a blocker.
• Deliberately uncustomizable — no arbitrary kernel parameters or custom kernel modules; fine for 95% of containerized workloads, wrong for the other 5%.
• Team adjustment period — a few weeks of "how do I…?" with SSM-only access, immutable hosts, and atomic updates; documenting access patterns up front shortens it.

Skip this if

• You run legacy apps with host dependencies (specific kernel modules, filesystem drivers, or host-level agents that aren't containers), or you regularly tune kernel parameters / install packages in production — the immutable model will fight you.
• Your team is still learning containers — master the basics on Amazon Linux first. For modern fully-containerized clusters, layer EKS Karpenter on top for right-sized node provisioning, or pair with ECS Fargate Task Rightsizing on smaller hosts.