AWS EC2 Support
EC2 AMI pipeline and patching with Image Builder and Patch Manager.
Patching live servers by hand drifts and breaks. A better pattern is to build hardened AMIs on a schedule, roll them out through Auto Scaling, and use Systems Manager Patch Manager for the instances that must stay up. We set up both and wire in testing.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Instances were patched manually and no two look the same
- A new CVE means weeks of work to update the fleet
- New Auto Scaling instances launch from an outdated AMI
- An audit asks for patch compliance evidence
- You want a hardened baseline image for every new server
What you get
- Image Builder pipeline defined as code
- Patch baselines, maintenance windows and compliance reporting
- Instance refresh process with a tested rollback
- AMI and snapshot cleanup policy
How we do it
A clear, safe process you can follow along with.
1. Check Systems Manager coverage
We make sure every instance is a managed node: SSM Agent running, an instance profile with AmazonSSMManagedInstanceCore, and a network path to the SSM endpoints or VPC endpoints. Fleet Manager shows which instances are missing.
2. Define the image recipe
In EC2 Image Builder we create a recipe with a parent image, build components for your agents and hardening, and test components that fail the build when something is wrong. We add an infrastructure configuration for the build instance in a private subnet.
3. Schedule and distribute
The pipeline runs on a schedule or when the parent image updates, and distributes the AMI to the Regions and accounts you need with launch permissions and tags. We can also publish the new AMI ID to an SSM parameter for launch templates to read.
4. Roll out through Auto Scaling
We point the launch template at the new AMI and run an instance refresh with a minimum healthy percentage, so instances are replaced gradually behind the load balancer. Rollback is pointing the template to the previous AMI.
5. Patch long-lived instances with Patch Manager
For servers that cannot be replaced, we create patch baselines per OS, assign instances by a Patch Group tag or a patching policy, and use a maintenance window running AWS-RunPatchBaseline with the Install operation. Scan only mode reports without changing anything.
6. Report and scan
We review compliance in Patch Manager, and connect Amazon Inspector for vulnerability findings so you can see what is still exposed after patching.
7. Test before production
We run the pipeline output and the baselines in a staging group first, with smoke tests, and keep old AMIs for rollback before deregistering them and deleting their snapshots.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Patching production first
Patches can break applications. We always test in staging and stagger groups.
Baking secrets into AMIs
Anyone with launch access sees them. We fetch secrets at boot from Secrets Manager or Parameter Store.
Never deleting old AMIs
Snapshots behind them keep costing money. We automate cleanup after a retention period.
Skipping reboot planning
Many patches need a reboot. Windows and maintenance windows must account for it.
Frequently Asked Questions
What is EC2 Image Builder?
It is an AWS service that automates building, testing and distributing AMIs and container images from a recipe, on a schedule, with no build servers to manage.
Image Builder or Patch Manager?
They complement each other. Image Builder suits immutable fleets where instances are replaced with a new image, while Patch Manager suits long-lived servers patched in place.
Does Patch Manager work on Windows and Linux?
Yes, it supports common Windows Server and Linux distributions. Check the current supported OS list for your versions.
Want Help With EC2 AMI pipeline and patching with Image Builder and Patch Manager?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required