Who patches what in the cloud?

Short answer

Moving a system to the cloud does not automatically transfer all patching to the cloud provider.

The provider patches the infrastructure it operates. You remain responsible for the parts of the system that you operate. Where that boundary lies depends on the service you choose.

If you rent a virtual server, the provider maintains the physical data center, hardware and virtualization platform. You normally remain responsible for the operating system inside the virtual server, the software you install and your application.

If you use a managed database, application platform or serverless service, the provider operates more of the software stack. That can remove operating system or database-engine patching from your routine work. You may still need to select maintenance windows, approve or schedule updates, move away from unsupported versions, update application dependencies and verify that your application continues to work.

There is therefore no useful general answer that “the cloud provider patches it.” The answer must be established for each service and each layer of the application.

A cloud server is still your server above the provider’s boundary

A virtual machine can look much like a server in your own environment. You choose an operating system, install software, configure services and deploy an application. The physical machine is no longer yours, but the guest operating system usually is.

The provider operates	You normally operate
Physical facilities, hardware, network and virtualization layer	Guest operating system, installed software, application code and configuration

Your responsibility therefore commonly includes security updates for the operating system, packages, web or application servers, database software installed on the machine, and the frameworks and libraries used by the application. It also includes any necessary restart or replacement, testing that the service still works, and evidence that required updates were applied.

The provider may supply images, patch-management tools, vulnerability findings and automation. Using those capabilities is still a customer decision. A patch being available in a repository or management console does not mean it has been applied successfully to every relevant system.

Managed services move the boundary

A managed service transfers more operational responsibility to the provider. A managed database, for example, can remove the need to maintain the underlying server and install database-engine patches yourself. An application platform can similarly place operating system and runtime maintenance with the provider.

That does not make every managed service maintenance-free.

With a virtual machine, you normally maintain the operating system and everything above it. With a managed database, the provider also maintains the operating system and database platform. With a serverless service, still more of the runtime moves behind the provider’s boundary.

What remains is different rather than necessarily absent:

Provider action: maintaining the infrastructure and the parts of the service platform it operates.
Customer decision: selecting supported versions, choosing or approving maintenance timing, planning major upgrades and maintaining extensions or software outside the managed service.
Customer verification: testing application compatibility and confirming that the application still behaves correctly after maintenance.

The exact division varies by service. An update may be applied automatically, offered for scheduling or require the customer to take action before an older version reaches the end of support.

Some highly managed services apply infrastructure and platform patches without customer action. The customer still owns application behavior, data, access and configuration. A provider can keep its service software current without knowing whether your code contains a vulnerable library or whether an update changes behavior your application depends on.

The practical question is not whether a service is called “managed.” It is which exact layers the provider operates and which decisions or actions remain with you.

Automatic patching still needs an owner

Automatic updates can reduce delay and routine effort. They do not remove the need for operational ownership.

There is also a simpler question that automation must answer: is anything waiting to be patched? An environment needs a reliable way to show available updates and other pending actions. Those actions may include applying a patch, restarting a system, rebuilding an image, replacing an instance or choosing a newer supported version. A process that describes how updates are installed but cannot show what is currently outstanding is incomplete.

Someone still needs to know:

whether any updates or related actions are currently pending;
which resources are covered by automation;
which updates are included and excluded;
whether failed updates are retried or reported;
whether a restart is required;
what happens to systems that were stopped or disconnected;
how exceptions are handled;
whether newly created instances use an up-to-date image;
how application health is checked after an update; and
where evidence of patch status can be found.

Without these answers, “automatic” may mean that most routine updates usually happen. That is not the same as knowing that every relevant system is protected.

Automation also needs a deployment strategy. Updating a running server in place may be appropriate for some environments. Others replace instances with newly built and tested images. Containers introduce another distinction: the platform may patch the hosts while you remain responsible for rebuilding and redeploying container images that contain vulnerable operating system packages or application dependencies.

Patches and upgrades are not the same thing

Routine security patches often stay within a supported operating system, runtime or database version. A major upgrade can change interfaces, behavior or compatibility and may require application work.

A provider may keep the infrastructure beneath an old service version secure while requiring you to move to a newer supported version. It may also announce a date after which an older runtime, operating system or database engine is no longer available or fully supported.

End of support does not mean that no further vulnerabilities will be discovered. It means that fixes may no longer be produced or supplied for that version. Operating systems, runtimes and application platforms should therefore remain within an actively supported product lifecycle, even when no known vulnerability is currently demanding attention.

This creates two different questions:

Are current supported versions receiving and applying security fixes?
Are we still running versions that the provider or software vendor supports?

An environment can appear fully patched while still depending on software that is approaching end of support. Version lifecycle therefore belongs in the same operating process as patch status, even though the resulting work may be much larger than applying a patch.

Cloud infrastructure can make that larger change less destructive. Instead of upgrading an existing instance in place, it may be possible to build a new instance or environment with the newer version alongside the one currently serving users. The new environment can be configured, loaded or connected with the required data, tested and either brought into service or discarded without first dismantling the working environment.

This approach can provide three useful opportunities:

The upgrade can be tested before deciding to direct production traffic to it.
The existing environment can remain available while the replacement is built and tested.
The replacement can incorporate what has been learned about capacity, instance type, storage or other infrastructure requirements.

The data needs separate consideration. Copying, restoring or replicating data may take time, and a database or schema upgrade can make rollback more complicated than replacing an instance. Building beside the existing environment reduces infrastructure risk; it does not by itself make every data migration non-destructive.

How do you know that something needs patching?

The answer should not depend on one administrator remembering to visit several vendor websites.

A workable process normally combines several sources:

the cloud provider’s service notifications and health messages;
operating system and software-vendor advisories;
an inventory of systems, images, runtimes and dependencies;
vulnerability scanning or provider findings;
patch-compliance reporting;
application dependency and container-image scanning; and
explicit ownership for reviewing and acting on the results.

Different sources see different layers. A cloud platform can report that a virtual machine is missing operating system updates while remaining unaware of a vulnerable library packaged inside your application. An application scanner can find that library without knowing whether the server beneath it has a vulnerable kernel.

Inventory is what connects an advisory to the systems that may be affected. If you do not know which versions are running and where, every serious vulnerability begins with a search for the possible exposure.

What happens when an urgent vulnerability appears?

An urgent vulnerability should not force the organization to invent its decision process while the clock is running.

Before that happens, establish:

who receives provider and vendor advisories;
who determines whether the environment is affected;
who can authorize emergency work;
what testing is proportionate to the risk;
how updates are deployed without losing every working instance at once;
what can be rolled back and what cannot;
how temporary mitigations are approved and tracked;
who verifies that the vulnerability is no longer present; and
what evidence must be retained.

“Patch immediately” can be an understandable reaction, but an update that interrupts a critical application is also an incident. The objective is a process that can move quickly without turning urgency into uncontrolled change.

Cloud capabilities can help. Images can be rebuilt, instances can be replaced, updates can be deployed gradually and health checks can prevent traffic from reaching failed components. These options work only when they were incorporated into the way the application is operated before the emergency.

Make the responsibility visible

The most useful patching document is not a generic statement that security is shared. It is a short inventory that identifies the actual boundary for the services you use.

For each component, record:

what it is;
who operates the underlying infrastructure;
who patches the operating system;
who patches the runtime or engine;
who updates installed software and application dependencies;
whether updates are automatic, scheduled or manual;
who selects maintenance windows or versions;
where notifications and compliance evidence appear; and
who acts when routine automation is not sufficient.

This inventory may show that the same application contains several responsibility models. Its virtual machines, managed database, container registry, serverless functions and external software service can each place the boundary somewhere different.

That is normal. What creates risk is not the existence of different boundaries, but leaving them implicit.

Questions to ask about your environment

Which parts of the infrastructure does the provider patch without customer action?
Which guest operating systems are still our responsibility?
Which managed services require us to approve, schedule or facilitate maintenance?
Who tracks runtime, database and operating system support dates?
How are application libraries and container images checked?
Which systems are excluded from automatic patching, and why?
What happens when an automated update fails?
How do we verify application health after maintenance?
Can we show which updates were applied and when?
Who can make and execute an emergency patching decision?

If the answer to several of these questions is “the provider probably handles it,” the division of responsibility has not yet been established.

What cloud changes

Cloud services can remove substantial patching work. Providers maintain physical infrastructure and service platforms at a scale that individual organizations would find difficult to reproduce. Managed services can also reduce the number of operating systems, databases and middleware components your team must maintain directly.

But cloud does not turn patching into one provider-owned task. It changes the boundary. The more infrastructure you operate yourself, the more patching remains yours. The more managed services you use, the more responsibility moves to the provider—but configuration, versions, application code, evidence and operational decisions may still remain with you.

The safe assumption is therefore not “they patch it” or “we patch it.” It is:

For every service we use, we know who patches each layer, what action remains, and how we verify the result.

Sources and further reading

Questions, corrections and contributions

Talk to the author

Have a question, a different experience or something that would make this article more useful? Leave a thought. Your feedback may help improve this page.

← Back to the Library