About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
On infrastructure as a service, the provider runs the facilities, physical hosts, physical network and virtualisation layer. You own the guest operating system and everything above it, plus network rules, identities and data. Patching the guest, collecting its logs and backing it up are your work, and the provider's tools for those jobs generally need someone to configure them. Some defaults are active regardless, as Azure's patch modes show.
A responsibility diagram does not show that. A control list does: one row per control, with the owner, the state it is in until you act, and the evidence that proves it is running.
The vendor statements below were checked on 10 November 2026. The commands come from vendor CLI references and were written up for this article. None was run in a lab.
Why it matters
The Australian Signals Directorate (ASD) says the risk work is shared between tenant and provider, but organisations "are ultimately responsible for protecting their data" and its confidentiality, integrity and availability.
The Information Security Manual (ISM) control ISM-1569 requires a shared responsibility model to be "created, documented and shared between suppliers and their customers". A vendor's web page is an input to that document. It is not the document.
Microsoft says its own matrix is illustrative guidance and not intended to convey legal conclusions or to change any agreement. The contract governs, so a control list built from public pages still has to be checked against yours.
Google states: "Many cloud security breaches are the direct result of misconfiguration". Most of the rows below are configuration items.
How the boundary is drawn
The three providers put the line in nearly the same place for virtual machines.
| Provider | Provider side | Customer side |
|---|---|---|
| AWS | "From the host operating system and virtualization layer down to the physical security of the facilities" | Guest OS "including updates and security patches", application software, security group configuration. For EC2, also credentials and the IAM roles attached to instances |
| Microsoft Azure | Physical hosts, physical network, physical datacentre, hypervisor | Data, configuration, identities, client devices, applications, network controls, operating system |
| Google Cloud | Underlying infrastructure and physical security | "The bulk of the security responsibilities", and always access policies and data |
AWS also sorts controls into three classes. Inherited controls, such as physical and environmental protection, come entirely from the provider. Shared controls, such as patch management, have a part on each side. Customer-specific controls, such as zone security, are yours alone.
ASD's October 2026 Essentials for cloud uses a similar set of markers: Customer, Supplied and Provider-inherited. Supplied means the provider supplies the capability, but the customer "must enable, configure and operate it".
That publication is written for software and platform services, and ASD points organisations with direct control over compute and networking towards Essentials for enterprise IT. Borrowing the Supplied marker for IaaS is an editorial choice here. It is useful because it names the state where most of the rows below sit: the feature exists, and nothing happens until you turn it on.
The control list
This table is an editorial synthesis of the vendor pages linked in the sections that follow. "State until you act" describes what those pages say about the default.
| Control | Provider does | You do | State until you act | Evidence that proves it |
|---|---|---|---|---|
| Physical and host security | All of it | Collect the provider's assurance reports | Inherited | Current third-party report, read for scope |
| Host maintenance | Performs it and gives notice | Watch notices, design for restarts | Happens regardless | Notice route tested, restart runbook |
| Guest OS patching | Publishes tools | Choose scope, schedule, reboot rules | Not your provider's job; a default may already be patching | Actual patch mode and per-VM patch state, by date |
| Application patching | Nothing | All of it | Yours alone | Version inventory against vendor advisories |
| Control-plane audit | Records it | Extend retention, protect, review | Retention varies by provider | Trail or sink status, retained copy |
| Resource and data-access logs | Offers the feature | Enable per service | Mostly off | Diagnostic settings, event selectors, audit config |
| Guest OS logs | Offers an agent | Install, configure, ship | Not collected | Agent status, recent entries at destination |
| Backup | Offers the service | Policy, scope, retention, protection | Not configured | Last good recovery point per VM |
| Restore testing | Offers tooling on some platforms | Run and record it | Not done | Dated test with result and duration |
| Network rules | Enforces them | Write them | Your configuration | Rule export, reviewed |
| Identity and access | Provides the service | Accounts, roles, multi-factor sign-in | Your configuration | Role review, privileged access logs |
| Data classification and encryption decisions | Offers mechanisms | Decide and apply | Your decision | Register entry per data set |
| Zone and region resilience | Runs the zones and regions | Deploy across them | Single location unless designed otherwise | Failover test record |
Provider resilience follows the same line. AWS says EC2 "requires the customer to perform all of the necessary resiliency configuration and management tasks". Microsoft says that with IaaS "you typically need to plan and implement many reliability capabilities yourself".
Host maintenance: the provider's action, your outage
Host maintenance is the row teams leave off. You do not perform it, but your service absorbs it.
- AWS can schedule events that reboot, stop or retire instances and notifies by email to the address on the account. That mailbox is therefore part of the control.
- Azure's memory-preserving maintenance works for more than 90 percent of VMs but not the G, L, N and H series. Inside a VM, Scheduled Events gives notice of upcoming maintenance.
- Google Cloud live migrates most instances by default, but some machine types do not support it. Check your type rather than assume.
Patching: three tools, one gap
The provider's tools decide how patches reach a VM. They do not decide whether your timing is good enough.
AWS. AWS recommends you regularly patch and update instances, and Patch Manager automates it for managed nodes through patch baselines. The command below reports on managed nodes, so an instance that Systems Manager does not manage needs checking another way.
aws ssm describe-instance-patch-states --instance-ids i-0123456789abcdef0
The output gives MissingCount, FailedCount, CriticalNonCompliantCount and InstalledPendingRebootCount. Editorial reading: a non-zero pending-reboot count means a patch is installed but may not yet be in effect.
Azure. Automatic VM guest patching applies patches classified Critical or Security during off-peak hours, and it includes rebooting as configured. It has to be enabled, by setting the patch mode to AutomaticByPlatform, and only on supported platform images. With no patch mode specified, a Windows VM is set to AutomaticByOS, which installs patches through Automatic Updates, and a Linux VM to ImageDefault, which honours the image's patching configuration. An untouched Windows VM can therefore already be installing updates. Record each VM's actual patch mode.
Timing is the catch: "Patches are installed within 30 days of the monthly patch releases". Azure Update Manager adds optional assessments every 24 hours and scheduling. Results of assessments and installations are stored in Azure Resource Graph.
az vm assess-patches -g MyResourceGroup -n MyVm
This command assesses patches on the VM.
Google Cloud. VM Manager needs the OS Config API enabled, the OS Config agent installed on each VM, and instance metadata set to activate it. Patch deployments then schedule patch jobs.
gcloud compute os-config patch-jobs list
gcloud compute os-config patch-jobs list-instance-details PATCH_JOB
These are from the patch-jobs list and list-instance-details references.
The timeframe the tool does not set
The Essential Eight maturity model (November 2023 release) gives timeframes for operating systems.
| Operating system on | Critical, or working exploit exists | Non-critical, no working exploit |
|---|---|---|
| Internet-facing servers and network devices, all levels | Within 48 hours of release | Within two weeks |
| Non-internet-facing servers, network devices and workstations, Levels One and Two | Within one month | Within one month |
| Non-internet-facing servers, network devices and workstations, Level Three | Within 48 hours | Within one month |
The same model expects a vulnerability scanner at least daily for operating systems of internet-facing servers and network devices, and at least fortnightly for the others.
Editorial reading: a 30-day installation window, on its own, cannot meet a 48-hour requirement. If an internet-facing VM is in scope, it needs an out-of-cycle route such as an on-demand patch job. A monthly schedule does not provide one.
Logging: three layers, three different defaults
Treat these as separate controls. Each has a different owner action.
Control-plane audit. This records who did what to cloud resources.
- AWS event history keeps the past 90 days of management events per Region. A trail delivers them onward, and AWS recommends a multi-Region trail.
- The Azure activity log is kept for 90 days and then deleted, unless a diagnostic setting sends it elsewhere.
- Google Cloud Admin Activity audit logs are always written and cannot be disabled. They land in the
_Requiredbucket, which has a fixed 400-day retention. The_Defaultbucket defaults to 30 days.
Resource and data-access logs. These are the reads and writes against the data, and they are the ones an investigation asks for.
- By default, AWS trails do not log data events, and additional charges apply when you enable them.
- Azure resource logs are not collected by default. They need a diagnostic setting.
- Google Cloud Data Access audit logs are disabled by default for most services.
Guest OS logs. The provider cannot see inside your VM without help. Microsoft states that without the agent "you can collect data only from the host machine". AWS uses the CloudWatch agent and Google the Ops Agent. Each has to be installed and configured.
These read-only commands show the state of the first two layers.
# AWS: trails, whether each is logging, and what it selects
aws cloudtrail describe-trails
aws cloudtrail get-trail-status --name my-trail
aws cloudtrail get-event-selectors --trail-name my-trail
# Azure: subscription-level and per-resource diagnostic settings
az monitor diagnostic-settings subscription list
az monitor diagnostic-settings list --resource RESOURCE_ID
# Google Cloud: audit configuration and log routing
gcloud projects get-iam-policy PROJECT_ID
gcloud logging sinks list
Reference for the last command.
| Output | Editorial reading |
|---|---|
get-trail-status shows IsLogging false |
The trail exists but is not recording |
describe-trails shows IsMultiRegionTrail false |
Events in other Regions are not captured by this trail |
get-event-selectors shows an empty DataResources |
No data events are selected by that classic selector. Advanced selectors, if used, appear separately |
diagnostic-settings list returns nothing for a resource |
No resource logs are leaving that resource |
get-iam-policy has no auditConfigs section |
No project-level Data Access configuration exists, and settings inherited from a folder or organisation still need checking |
What the Australian baseline adds
The Essential Eight's requirements on event log protection and analysis start at Maturity Level Two, and are not in Level One. There, event logs are "protected from unauthorised modification and deletion" and logs from internet-facing servers are analysed in a timely manner to detect cyber security events. Those lines sit inside named strategies and follow named event types: multi-factor authentication, privileged access, privileged account and security group management, application control, PowerShell, and command line process creation events. Our reading: this is not a general rule for all cloud logs.
ASD's tenant guidance asks for "detailed time-synchronised logs and real-time alerts", covering both the accounts that administer the service and what runs in it, such as operating system, web server and application logs.
So a retained copy in a place the workload's administrators cannot alter is a design requirement, not a nice-to-have. That inference is editorial.
Backup: the feature exists, the outcome is yours
AWS is plain about the customer's resiliency tasks on EC2: "Failure management requires backing up data". Microsoft notes that backups "might be automatic, manual, or both", so a service's own page has to be read, not assumed.
| Platform feature | What the page states | What it leaves to you |
|---|---|---|
| EBS snapshots | Incremental; replicated across Availability Zones in the Region | Schedule, retention, a copy outside the Region |
| AWS Backup Vault Lock | In Compliance mode after grace time, cannot be altered or deleted by customer, account owner or AWS while it holds recovery points | Choosing the mode and the retention |
| Azure VM Backup | Agent-based application or file-consistent, or agentless crash-consistent, chosen in the policy. Azure Backup also takes crash-consistent backups if the VM is not running or application/file-consistent backups fail | Whether crash consistency is enough, and each recovery point's actual type |
| Azure soft delete | 14 days by default, extendable to 180; default enforcement described as in preview for Recovery Services vaults | Confirming the state on your vault |
| Google Backup and DR vaults | Backup vault enforces write once, read many immutability and indelibility | Enrolling workloads and setting retention |
| Google snapshot schedules | Google describes them as a best practice for backing up Compute Engine workloads | Creating and attaching the schedule |
The inventory commands below answer "what is covered", which is a different question from "will it restore".
aws backup list-protected-resources
aws backup list-restore-jobs --by-status COMPLETED
az backup item list --resource-group MyResourceGroup --vault-name MyVault --backup-management-type AzureIaasVM
gcloud compute snapshots list
These come from the list-restore-jobs, az backup item and gcloud compute snapshots list references.
Note the wording on list-protected-resources: it returns resources with recovery points "regardless of the recovery point's status". Appearing in that list does not prove a recovery point is usable.
Evidence of restoration has to come from a restore. AWS Backup offers restore testing, with automated and periodic evaluation of restore viability and job duration.
The Essential Eight requires, from Level One, that restoration to a common point in time is "tested as part of disaster recovery exercises" (also ISM-1515).
ASD's tenant guidance goes further. Against data becoming unavailable through corruption, deletion or the provider terminating the account, it recommends up-to-date encrypted backups, in a format avoiding provider lock-in, stored offline at the tenant's premises or at a second provider requiring multi-factor authentication to modify or delete data, with the recovery process tested annually. A snapshot in the same account does not meet that description.
What to choose and why
These are editorial recommendations.
| Situation | Choice | Reason |
|---|---|---|
| Starting from a vendor diagram | One row per control, with owner, default, evidence and review date | A diagram cannot be audited |
| Control marked as inherited | Keep the provider's report and read its scope | AWS points to third-party attestations to determine inherited controls, and Google says inherited controls can serve as audit evidence |
| Internet-facing VM | Automated cycle plus a tested on-demand patch route | The 48-hour window is shorter than a monthly cycle |
| Long-lived investigation needs | Send control-plane logs to storage the workload administrators cannot change | Default retention varies by provider, and logs can be needed after it ends |
| Enabling data-level logging | Enable by data sensitivity and estimate volume first | AWS charges extra, and every extra log has to be stored and reviewed |
| Database or transactional VM | Application-consistent backup, with a tested restore | Crash consistency leaves recovery to the application |
| Critical data | A copy outside the provider account, tested | Matches ASD's tenant guidance on account loss |
Work in this order: build the row list, record the current state using read-only queries, fix the rows with no evidence, then assign a named owner and a review date to each.
Risks and limits
Warning: Turning on automatic patching can reboot VMs. Azure's automatic guest patching includes rebooting as configured, and a Google patch job's default reboot setting lets the agent decide, and multiple reboots may occur. Test on a non-production VM and agree a window first.
Warning: AWS Backup Vault Lock in Compliance mode is deliberately irreversible after the grace time. A mistaken retention setting cannot be undone by you or AWS while the vault holds recovery points. Rehearse with a test vault.
Warning: Enabling data-level audit logs can raise volume and cost quickly. Estimate before enabling across an account, and apply it by data sensitivity.
az vm assess-patchesis not a passive read. The reference describes it as assessing patches on the VM, withaz vm install-patchesas the separate install command. It is still an operation against the VM, so treat it as a change-window item on sensitive systems.- Public pages are not your contract. Microsoft's note applies generally, so confirm the split against your agreement and any regulatory obligations. AWS itself says responsibility varies with the services used, their integration and applicable laws.
- Maturity levels are not a legal standard for every reader. Whether the Essential Eight or ISM applies to you depends on your organisation. They are used here as a concrete Australian yardstick.
- Managed services move the line. This article covers virtual machines. Each managed service has its own split.
- Default states change. Azure's soft delete enforcement was in preview when checked, for example. Query the real state rather than relying on a table.
- Not tested here. Commands and readings come from vendor documentation only.
Sources
Opened 10 November 2026. Sources behind the corrections reopened 10 November 2026.
- AWS: Shared responsibility model
- AWS: Security in Amazon EC2
- AWS: Shared responsibility model for resiliency
- AWS: CloudTrail concepts
- AWS: Logging data events
- AWS: Patch Manager
- AWS Backup: Restore testing
- Microsoft: Shared responsibility in the cloud
- Microsoft: Shared responsibility for reliability
- Microsoft: Automatic VM guest patching
- Microsoft: Activity log
- Microsoft: Diagnostic settings
- Google Cloud: Shared responsibilities and shared fate
- Google Cloud: Cloud Audit Logs
- Google Cloud: Configure Data Access audit logs
- Google Cloud: Logging quotas and limits
- Google Cloud: VM Manager setup
- ASD: Essential Eight maturity model
- ASD: Cloud computing security for tenants
- ASD: Essentials for cloud
- ASD: ISM, Guidelines for procurement and outsourcing, September 2026
- ASD: ISM, Guidelines for system management, September 2026
- Google Cloud: Backup and DR Service
- Google Cloud: Snapshot schedules
- Google Cloud: Host maintenance overview
- Google Cloud: OS patch management
- Google Cloud: Create patch jobs
- Google Cloud: Ops Agent overview
- gcloud: patch-jobs list
- gcloud: patch-jobs list-instance-details
- AWS: Scheduled events for Amazon EC2 instances
- AWS: Update management for Amazon EC2 instances
- AWS: Collect metrics, logs and traces using the CloudWatch agent
- AWS Backup: Vault Lock
- AWS CLI: list-protected-resources
- AWS CLI: describe-trails
- AWS CLI: get-event-selectors
- AWS CLI: get-trail-status
- AWS CLI: describe-instance-patch-states
- AWS CLI: list-restore-jobs
- Azure CLI: az backup item
- gcloud: compute snapshots list
- gcloud: logging sinks list
- AWS: Amazon EBS snapshots
- Microsoft: Azure Monitor Agent overview
- Microsoft: Soft delete for Azure Backup
- Microsoft: Azure VM backup overview
- Microsoft: Azure Update Manager overview
- Microsoft: Azure Update Manager data in Azure Resource Graph
- Microsoft: Maintenance and updates for virtual machines
- Microsoft CLI: az monitor diagnostic-settings
- Microsoft CLI: az vm
- ASD: Essentials for enterprise IT
This article was originally published on .