Ansible and Chef moved upstream. Most teams never noticed.

Ansible and Chef were built for a world of long-lived servers. Every 30 minutes the Chef client checked that a hundred machines still matched their recipes and nudged them back if they had drifted. That was the job: keep running servers correct.

Most workloads don’t run on servers like that anymore. Containers are rebuilt on every commit. Auto Scaling groups replace instances freely. A server that lives for three days doesn’t need correcting every 30 minutes. It needs to start correct.

The tools didn’t become obsolete. Their best use moved upstream, from running servers to building the image.

The image factory

Instead of configuring each instance after launch, configure an image once and launch many identical copies:

1. Packer (or EC2 Image Builder) starts a temporary instance from a base image.
2. Your existing Ansible playbooks or Chef cookbooks run against it: packages, hardening, agents, users, settings.
3. The result is saved as an AMI, tested, and promoted through environments just like application code.
4. Instances launch from that AMI and do almost nothing at boot except fetch their secrets and start.

Years of playbooks and cookbooks keep their value. They run in one place, against a known starting point, with a test step after them.

What you gain

• Patching becomes a rebuild. A new CVE means building and rolling out a new image, not running a playbook across a fleet and hoping every host succeeds. The image pipeline is the patch pipeline.
• No drift by design. Instances aren’t changed after launch, so there’s nothing to drift. If something needs changing, it changes in the image.
• Fast, boring boots. Scaling out doesn’t wait for a 6-minute configuration run that might fail because a package mirror is slow.
• An audit trail. Every running instance traces back to an image ID, which traces back to a commit.

Where in-place config still belongs

Some things genuinely live a long time and can’t be rebuilt casually:

• Stateful servers: databases on EC2, legacy applications with local state, licensed software tied to a host.
• Network devices and appliances, where Ansible’s agentless model is still the most practical way to manage configuration.
• Fleet-wide emergency changes that can’t wait for a rebuild, followed by the same change in the image so the next launch includes it.

For those, keep the config runs, but run them on a schedule with a report, and alert on hosts that fail or drift. AWS Systems Manager (State Manager and Patch Manager) covers much of this without a separate server.

The 2026 version of the question

The question is no longer “Ansible or Chef?” It’s “where does configuration happen?” Before launch, in a pipeline, tested: that’s where most of it belongs now. After launch, on a live host: only where there’s no alternative, and visible when it fails.

Teams that make this shift tend to find their playbooks get shorter, because a playbook that runs once on a clean machine no longer needs to handle every possible state a server might be in.