Infrastructure Engineering as a Lifecycle

Consider a fictional audit that finds a virtual machine whose operating system stopped receiving vendor security fixes fourteen months ago. The version was chosen six years earlier by someone who has left. Its support deadline was never assigned to an owner, and the team maintaining the application is reluctant to change it because it has no test suite.

Infrastructure engineering continues after an environment is built. Selecting software introduces support deadlines, installing it creates patching work, and undocumented changes make later replacement harder. This article connects those obligations through support planning, images, configuration control, and patching. Check the linked policy for the exact release, package scope, and enabled coverage before planning a transition.

What you own when you own the operating system

Running virtual machines means the layer between the hypervisor and your application is yours. Concretely, that is a list of recurring obligations rather than a one-time build.

• The kernel and the packages, including their security updates and the reboots some of them require.
• The base configuration — users, SSH access, time synchronization, logging, the agents your security team requires.
• The hardening baseline, and evidence that it is still in place on every host rather than on the one you checked.
• The version and its support dates, with an owner responsible for reviewing coverage and planning the next transition.

A machine can keep serving requests after its support window closes, so continued operation is not evidence of continued coverage. Vendor tools may report support or subscription status: Ubuntu Pro, for example, provides coverage and expiration messages. Connect those signals to the inventory and an accountable owner. The shared responsibility model helps identify which operating-system obligations remain with your team.

Support depends on phase and coverage

Enterprise distributions publish a support lifecycle. For RHEL 8, 9, and 10, Red Hat’s detailed policy describes ten years across Full Support and Maintenance Support, followed by an Extended Life Phase. Check the schedule and coverage for the exact release rather than treating the headline duration as one uniform promise.

Phase	What arrives	What it means for planning
Full Support	Updates under the vendor policy, with selected feature and hardware additions	Check whether required capabilities and packages are covered
Maintenance Support	Updates meeting the applicable errata criteria; new features and hardware enablement are not planned	Reduced feature change does not guarantee security or compatibility for every package
Extended Life Phase, base subscription	Previously released content and limited technical assistance; no new fixes or root-cause analysis	Arrange migration or eligible extended coverage if new fixes are required

The last row describes the base subscription. Limited assistance and access to existing content remain, but they do not provide new security fixes. Paid extensions have their own eligibility and coverage terms.

Record the active minor release, relevant Application Streams and packages, and any purchased extension. A component can have a shorter lifecycle than its operating-system major version. A phase name or a valid subscription alone does not establish coverage for the installed software.

Canonical publishes Ubuntu releases every six months. LTS releases arrive every two years and provide five years of standard security maintenance for Main; interim releases receive nine months of updates. Ubuntu Pro extends coverage, with scope and duration depending on the selected services and add-ons. Check repositories and enabled coverage as well as the release name.

Translate that policy into an operating plan:

• Plan from each release’s dates. The nine-month interim window starts at release, not installation. Following that track requires accounting for the six-month release cadence and supported upgrade paths, rather than scheduling a fresh nine months after every move. LTS is a usual starting point for long-lived fleets; short-lived, frequently rebuilt environments may justify interim releases when their transition process keeps them supported.
• Decide on extensions before they become urgent. Compare eligible coverage, its commercial terms, and the migration effort. Early planning preserves options; neither buying coverage nor waiting has a universally lower cost.
• Check component coverage. Packages outside the covered repositories or streams need their own maintenance source or replacement plan. An operating-system version number alone does not establish that coverage.

Maintain an inventory with the exact versions and coverage, phase end dates, and an owner for each transition. Set a decision date early enough for testing, migration, and a contingency margin. A twice-yearly review can suit a stable estate with long support windows; short windows or long migrations need earlier checks. New installations, policy changes, and lost coverage should trigger review between scheduled meetings.

Choose how the fleet receives updates

A fleet can receive patches in place or through tested replacement images. The golden image approach gives replacement hosts a shared starting artifact. AWS Image Builder automates image creation, validation, testing, and distribution; fleet rollout still needs its own controls. Compare the approaches against the workload and the operating process available to maintain it.

	Patch in place	Rebuild and replace
What is tested	Patches on representative current host states, then service behavior during rollout	The built image and its launch configuration, then service behavior during rollout
How state stays consistent	Central patching, configuration convergence, and verification can control differences	A common image provides a baseline; boot configuration, updates, and later changes still need control
Rollback	A supported reversal or tested restore procedure, subject to state compatibility	Redeploy a previous compatible image. External state, schemas, and consumers do not revert with the host
What it requires	Inventory, patch orchestration, tests, restart planning, and recovery procedures	An owned image pipeline, replacement capacity, and a workload with a tested state and recovery plan
Where it fails	Untracked starting states or incomplete rollout make verification and recovery difficult	Replacement loses required state or disrupts work when recovery and traffic handling are untested

For a workload that tolerates replacement, build and validate an image, then launch an instance from it and test the result. Image Builder gates distribution on the configured tests succeeding. That gate checks the selected tests; it does not establish that replacing the production fleet is safe. Exercise the launch configuration and dependencies, then expand rollout only while service checks remain healthy.

Restrict launches to approved images where the platform supports that policy. AWS documents organization-level enforcement for approved AMIs. Pair enforcement with an accessible image catalog and an exception process, and verify which launch paths the policy covers.

Stateful workloads need a plan for preserving, replicating, reattaching, or restoring their data during replacement. Some can use images; others need an in-place patch process. Assign ownership and a review interval based on the risk. Application and operations teams must agree on how interrupted work, state, and recovery behave.

Compare the declaration, image, and running host

Configuration drift is the gap between what a system is supposed to be and what it is. It is worth being precise about where the gap opens, because the three places have different fixes.

1. What is declared — the code, templates, and image recipes in version control. This is what a review looks at and what people believe is true.
2. What the image contains — the artifact actually built, which can differ from the declaration because a base image moved, a package version floated, or a build step silently failed.
3. What is running on the host — including approved boot and external configuration. Manual edits, automatic updates, another controller, or a changed configuration source can make it differ from the intended state.

A fleet can match its images while those images differ from the intended build inputs. Comparing the host with its image and approved launch configuration, then the image with the declaration, can locate that gap. Use incident evidence to choose where to start; the comparison order is a diagnostic option, not a universal rule.

Where drift is discovered, decide first which state is the intended one — the fix differs, and applying the wrong one either leaves a recurring defect or promotes a mistake into the standard.

• The declaration or image is wrong. Correct the declaration if the intended state was specified incorrectly. If the declaration is right but the artifact is wrong, fix the build process, input selection, or validation. Rebuild and redeploy; a host-only repair leaves that defective artifact available for reuse.
• The live host was changed without authorization and the declaration is right. Then the declaration must not be touched: restore the host to it. Copying the live state into the declaration here is how an incident workaround becomes the fleet standard.
• The change was an authorized emergency fix. Record its purpose, owner, and temporary scope. After review, either incorporate the lasting requirement into the declaration or restore the prior intended state. Make the interim decision visible to the next rebuild so it does not silently remove a needed fix.

Compare live state with the declared expectations, including permitted dynamic values, and investigate unexplained changes. Limit both interactive and automated mutation paths through least privilege. An audit log can help trace a change when its collection covers the relevant actor and action; it does not replace state verification.

Making patching survivable

Routine patching depends on how the service tolerates change. The operating process should address capacity, interrupted work, compatibility, prioritization, and evidence that the updated service still works.

• Preserve service during each replacement. Enough remaining capacity is necessary for a rolling change, but not sufficient. Drain traffic or work safely, check readiness, and validate mixed-version compatibility, sessions, and any quorum requirements. If those conditions cannot be maintained, plan added capacity, a different transition, or an agreed maintenance window.
• Keep an inventory you can reconcile. Include short-lived instances and workload images as well as long-lived hosts, and detect resources that are missing from the maintenance process.
• A severity rule decided in advance. What gets applied within days, what waits for the next cycle. Deciding this per vulnerability, under pressure, produces both unnecessary emergencies and genuine ones handled too slowly — and the decision belongs with the people who understand exposure, which is the threat and vulnerability distinction applied to scheduling.
• Verify operation during and after rollout. Check installed versions and active components after any required restart, then observe health, error rates, latency, and representative workflows. Start with limited exposure, expand in stages, and stop or recover when agreed thresholds fail. A version check alone does not establish service health.

With these controls, suitable workloads can use unattended rebuild and rollout procedures. Keep alerts and an accountable responder for failures, and exercise the stop and recovery paths. Workloads that cannot yet meet the conditions need a documented patch procedure while their constraints are addressed.

Operating-system patching does not cover every application dependency. A three-year-old library may have been reviewed and deliberately retained, and its distribution may carry backported fixes. Age alone establishes neither a vulnerability nor the absence of review. Check advisories for the actual installed distribution and revision, the affected paths in use, and the latest assessment date, owner, and retention or upgrade decision. Make host and application maintenance visible in the inventory even when different teams own them.

How much variety you can afford

Each supported combination of operating system, version, architecture, and base configuration adds patching, testing, documentation, and operating work. Shared automation may reduce the additional effort, while incompatible requirements can increase it. Compare that work with the benefit each variant provides.

An expanding support matrix can exceed the team’s maintenance capacity. A narrow matrix can also miss legitimate workload needs, leading to exceptions or unmanaged alternatives. Review why each variant exists and whether its maintenance commitment can be met.

Maintain a small supported set that fits the required operating-system versions, architectures, runtimes, and licensing constraints. Provide a documented exception process with an owner, reason, and review or expiration date. One image per OS family is not sufficient when those requirements differ.

A golden path makes the supported image convenient to obtain and maintain. Use feedback on setup time, missing capabilities, and failures to improve it. Treating the images and patch pipeline as services with users applies platform engineering to the operating-system layer.

Staff time, on-call load, and upgrade projects belong in total cost of ownership. Compare those duties with the remaining work, constraints, and charges of a service where the provider maintains the operating system.

Where to start

For an existing estate, start with the systems and deadlines that create the most immediate exposure, then build a repeatable process:

1. Inventory versions and coverage. Record phase dates, package or stream exceptions, actual extensions, and the owner and lead time for each transition.
2. Decide how to handle gaps. Evaluate upgrade, eligible extended coverage, or temporary risk acceptance by the authorized owner, subject to mandatory requirements. Record mitigation, review dates, and the intended exit from the exception.
3. Build and test a representative image. Choose a common workload whose replacement and recovery behavior can be exercised, and document the supported launch configuration.
4. Control new launches. Enforce the approved image set where supported and retain a visible exception path while existing variants are addressed.
5. Automate the validated process. Schedule rebuilds and staged rollout, with service checks, stop conditions, recovery procedures, and an owner for failures.

Where state prevents replacement, assess whether it can be separated, replicated, or restored within the service’s recovery requirements. If it cannot, maintain a tested in-place process with explicit ownership. Project-scale dependency records need the same boundary check: a virtual environment with recorded dependencies separates package installation paths but does not reproduce the host operating system. Its reproducibility therefore complements, rather than replaces, the host maintenance and recovery process. Where software cannot currently be kept supported, workload isolation can reduce exposure; it does not restore vendor coverage or remove the need for a transition plan.

References

• Red Hat, Red Hat Enterprise Linux Life Cycle
• Canonical, Ubuntu release cycle
• AWS, What is EC2 Image Builder?
• Canonical — Ubuntu releases
• AWS Builders’ Library — Automating safe, hands-off deployments
• Red Hat — Backporting Security Fixes
• AWS CloudFormation — Detect unmanaged configuration changes
• Canonical — Ubuntu Pro-related MOTD messages