Amazon Linux 2023 (AL2023) uses a deterministic upgrade model: each AMI is locked to a specific versioned repository (the releasever) at build time, and an instance receives no newer packages, including security updates, until that releasever is advanced. Automox patches AL2023 through the instance's own package manager against whatever repository version is currently configured, and it does not change the releasever for you. Understanding that is the key to patching AL2023 EC2 instances predictably with Automox.
Applies to
- Amazon Linux 2023 (AL2023) EC2 instances managed by the Automox agent.
- Administrators planning OS patching or ring-based deployment for AL2023.
The core principle
Automox relies entirely on the native package manager and the update sources currently configured on the device. If the operating system sees an update based on its current configuration, Automox sees it. If the operating system does not, Automox does not. Automox does not compare the instance against the newest AL2023 release, and it does not advance the releasever.
How Automox detects and applies updates on AL2023
On Amazon Linux, the agent detects pending updates with:
repoquery --pkgnarrow=updates -aTo apply updates, the agent invokes yum (for example, yum update for bulk patching, or yum update <package>). On AL2023, yum is a compatibility layer that passes the command through to dnf. Automox does not run dnf upgrade --releasever=latest or otherwise move the release version. It only installs what the currently configured repository offers.
The important consequence for compliance
Because Automox does not advance the releasever, an instance that is locked to an older release will only ever see the updates available within that pinned repository version. Once every package is current for that pinned version, the package manager reports nothing pending, so Automox reports the instance as compliant even though newer security patches exist in a later AL2023 release.
In other words, "compliant" in Automox for AL2023 means "current for the release version the instance is configured to," not "running the newest AL2023 release." Plan your patching with that distinction in mind.
Recommended approach: advance the release with a pre-patch Worklet
Since Automox does not manage the releasever, advance it yourself with a Worklet scheduled to run before your patch policy window. This lets you control exactly which release each group of instances moves to, which is what enables ring-based deterministic patching (for example, a dev group moves to a newer release first, and production follows the same tested release later).
Discover the available release versions:
dnf check-release-updateAdvance to a specific release version:
sudo dnf -y --releasever=<version> updateAmazon recommends pinning to a specific version (for example, 2023.6.20260630) rather than latest for production, so that every instance deploys the same changes you already tested, instead of picking up whatever is newest at run time. After the release is advanced, your normal Automox patch policy will see and apply the updates that are now available for that version.
Verify
- Confirm the running release with
cat /etc/os-releaseordnf check-release-update. - Trigger a scan in Automox and review the device's Software and patch status.
- Confirm that the instance now reports updates for the advanced release, and that they apply on the next policy run.