AWS Outposts, Azure Local and Google Distributed Cloud Security Guide: Shared Responsibility, Physical Security and Control Plane Links

When a cloud provider's hardware or control plane runs in your building, the security boundary moves: the provider still runs the software, but the rack, the cage, the uplink and the people who touch them are yours. AWS Outposts, Azure Local and Google Distributed Cloud each extend a public cloud into customer data centres and edge sites, and each documents a split of duties that differs from the same provider's regions. This guide covers that split for on-site infrastructure: physical security and tamper handling, hardware roots of trust and encryption keys, the link back to the provider's control plane, behaviour when that link fails, maintenance visits and hardware return, and how to monitor all of it. It is written for cloud, infrastructure and data centre security teams. Directory sync, federation and general hybrid networking are covered in the Hybrid Cloud Security guide; this page goes deeper on the hardware and control plane layer. Platforms are listed alphabetically; order is never a ranking. Product details are from each provider's public documentation as of November 2026.

Key takeaways

• Physical security returns to you. AWS states that customers own physical security and access controls around an Outpost, Google lists physical security of Distributed Cloud connected hardware as a customer duty, and Azure Local runs on machines in customer-owned environments.
• Keys are tied to on-site hardware. Outposts wraps data keys to a removable Nitro Security Key, Google Distributed Cloud connected uses the TPM as its key root, and Azure Local encrypts volumes with BitLocker with recovery keys stored outside the system.
• The control plane link is a security dependency. Each platform needs an encrypted path to its provider for management, updates and telemetry, so its firewall rules, redundancy and monitoring belong in your threat model.
• Disconnected time has limits. Workloads keep running during an outage, but management actions, updates and some logging pause, and Google documents a 7-day survivability window for connected clusters.
• Maintenance visits and returns are security events. Escort provider engineers, log the visit, and control what happens to keys and media when parts or racks leave the site.

Who is responsible for what on site

The provider's region-level shared responsibility model still applies, but each platform adds on-site duties. The table records what each provider's documentation assigns, in the provider's own terms. See the Shared Responsibility Models Guide for the general model and the Shared Responsibility Matrix Template to record your own split.

AWS Outposts

Outposts racks extend an AWS Region into your facility, and AWS states that once the service link is established the Outpost is operational and managed by AWS.

• Physical and tamper: the rack FAQ places physical security and access control with the customer, who also attests to facility, networking and power requirements. The infrastructure security page says equipment may include tamper monitoring. Put the rack in a locked cage or room with badge and camera coverage, and treat any tamper notice as an incident.
• Nitro Security Key: all Outposts data is encrypted at rest with key material wrapped to the removable Nitro Security Key, and destroying the key cryptographically shreds the data. Keep a custody record for the key and confirm its handling in writing before any return. Use Amazon EBS encryption with KMS keys where you need customer control over volume keys; see the AWS KMS Security Guide.
• Service link: the service link documentation describes an encrypted set of VPN connections to the home Region carrying VPC traffic and management traffic, including firmware and software updates. AWS requires redundant connectivity of at least 500 Mbps per compute rack, a maximum round trip of 175 ms and a 1500-byte MTU, and the link is always initiated from the Outpost. Public or private connectivity is chosen before ordering and cannot be changed after the order completes, so decide on AWS Direct Connect or internet early.
• Local traffic: AWS encrypts traffic to the Region; for local gateway traffic to your network it recommends an encryption protocol such as TLS for sensitive data.
• When the link drops: the rack FAQ says running EC2 instances and attached EBS volumes keep running and are reachable through the local gateway, control plane operations such as launching or stopping instances pause, instance metrics and logs are cached locally for up to 7 days, and EBS cannot rebuild volume redundancy if storage hardware fails during the outage. AWS recommends testing workloads for disconnected behaviour.
• Logging: VPC Flow Logs work as in a Region but are sent back to the Region first, so they are not visible in CloudWatch Logs, Amazon S3 or GuardDuty while the Outpost is disconnected. Apply the same IAM guardrails as your Regional accounts; see the AWS Security Guide.

Azure Local

Microsoft describes Azure Local as distributed infrastructure that extends Azure to customer-owned environments, with Azure Arc as the unifying control plane, in connected and disconnected deployments.

• Security baseline: Microsoft documents more than 300 security settings enabled from the start, disabling legacy protocols and ciphers, with drift control that refreshes settings every 90 minutes and remediates automatically. Drift control can be disabled at deployment; keep it on and record any exception.
• Encryption and application control: BitLocker protects infrastructure and workload data volumes, and Microsoft states recovery keys must be stored outside the system. Application Control (WDAC) is on by default, with enforcement mode recommended over audit mode. Store BitLocker recovery keys in a separate, access-controlled vault; see the Azure Key Vault Security Guide.
• Local accounts and secrets: the built-in administrator account (ASBuiltInAdmin) is enabled, the guest account is disabled, and an account lockout applies after 3 failed sign-ins for 15 minutes. Azure Local creates certificates at deployment and rotates them automatically before expiry. Vault the built-in administrator credential and alert on its use.
• Control plane connection: the firewall requirements call for outbound TCP 80 and 443 to Azure and Microsoft Update, with Arc endpoints such as *.his.arc.azure.com resolving to public IP addresses. HTTPS inspection is not supported on this path, so exclude it from inspection and compensate with destination allow-listing per region.
• Disconnected operations: available in Azure Local 2602 or later, this runs a local control plane on a dedicated management cluster you provide, with the Azure portal and CLI experience locally. Microsoft lists eligibility requirements, including an eligible agreement, a Standard or higher support plan and a valid business need, and supports system-assigned managed identities in this mode. See the Identity in DDIL and Disconnected Environments Guide for the identity side.
• Logging: syslog forwarding sends security events as RFC 3164 syslog with CEF payloads to your SIEM once configured. Microsoft Defender for Cloud integration is listed as preview. For the Arc agent model, see the Azure Arc Security Guide.

Google Distributed Cloud

Google Distributed Cloud connected runs GKE clusters on Google-certified hardware on your premises, managed centrally through Google Cloud over a Cloud VPN connection. Google Distributed Cloud air-gapped is a separate product for isolated environments.

• Physical and tamper: the security documentation assigns physical security to the customer. An intrusion sensor notifies you and Google immediately if a machine is opened, and ports other than Ethernet, such as USB and RS-232 console, are disabled in firmware and enabled only for servicing. Route intrusion notices into your incident queue, not just email.
• Root of trust and keys: the TPM generates and stores encryption keys, and a platform certificate records manufacturing and TPM identity for supply chain integrity. Drives are self-encrypting with LUKS on each node's logical volumes; the LUKS key is wrapped with a Google-managed key by default or with a customer-managed key in Cloud KMS, settable per node pool. Revoking the Cloud KMS CryptoKey Encrypter/Decrypter role from the service account removes access to the data, so protect that binding with change control. See the Cloud KMS and Cloud HSM Guide.
• Control plane connection: traffic to Google Cloud uses MASQUE tunnels or TLS with per-machine certificates that rotate automatically. Google recommends allowing inbound traffic only to the load balancer virtual IP pools and Distributed Cloud subnetworks, and blocking external inbound traffic to the system management and service management subnetworks and local control plane endpoints.
• Survivability mode: the survivability documentation says workloads continue for up to 7 days on the local control plane, while control through gcloud, kubectl and the Edge Container API, software updates and hardware repair stop. By default a node that reboots while disconnected cannot rejoin because its authentication key cannot be refreshed, unless you set an offline reboot window. After reconnection, audit log sync is capped at 10 GB and workload logs at 4 hours.
• Air-gapped deployments: the air-gapped overview states it needs no connection to Google Cloud or the internet; the distribution is downloaded, moved on a portable drive and verified by checksum, and a FIPS 140-2 certified operating system image is provided. Treat the transfer media and checksum step as a controlled software supply chain process.
• Repairs and returns: during on-site repairs by Google or a certified Systems Integrator, storage media is removed and returned to you or wiped and destroyed, and you export data and keep backups before returning hardware. See the Google Cloud Security Guide.

Where identity fits

Three identity layers meet on site. Cloud administrators who can manage the platform through the provider's control plane hold power over hardware in your building, so put those roles under the same privileged access controls as production cloud admins. Machine identities, such as the per-machine certificates in Google Distributed Cloud and the certificates Azure Local rotates, need inventory and owners like any other non-human identity. Local break-glass accounts, such as the Azure Local built-in administrator and offline cluster credentials, must be vaulted and monitored because they are what works when the cloud does not. See the Identity in DDIL and Disconnected Environments Guide.

Implementing on-site cloud security

1. Agree the split before ordering: record physical, network, key custody, maintenance and return duties per platform in a responsibility matrix, signed off by facilities, network and security. Connectivity choices such as the Outposts public or private service link are fixed at order time.
2. Prepare the space: a locked room or cage with badge logging, cameras covering the rack face, and a visitor process that escorts provider engineers and Systems Integrators. See the Data Centre Security Guide.
3. Design the uplink: redundant, diverse paths for the control plane link, firewall rules limited to the documented endpoints, and inbound blocks on management subnetworks. Test the rules in a staging site or maintenance window first; roll back by restoring the previous rule set.
4. Set key ownership: decide on provider-managed or customer-managed keys, store recovery material outside the system, and document who can revoke key access and what that does to the data.
5. Connect telemetry: forward platform security events, provider audit logs and physical access logs to the SIEM, and alarm on link state, intrusion and tamper notices.
6. Rehearse disconnection: pull the uplink in a planned test, confirm workloads keep running, measure how long local logs are retained, and verify break-glass access works. Record the maximum tolerable outage against each provider's documented limits.
7. Plan the exit: write the return and decommissioning runbook now, including key destruction or removal, data export and media handling. See the Media Sanitisation Guide.

Decision guidance

• Provider-managed or customer-managed keys: customer-managed keys give a revocation lever and an audit trail you own, at the cost of a new failure mode where a removed role binding makes data unreadable. Choose them where regulation or contracts demand customer key control, and pair them with change approval on the key policy.
• Connected or disconnected: choose disconnected or air-gapped modes only where connectivity or regulation genuinely rules out a link. They remove the provider's remote management path but move patching, monitoring and identity entirely onto your team.
• Single site or several: a single rack or cluster is a single physical failure domain. Where availability matters, spread across sites or across racks attached to different parent zones, as AWS recommends for Outposts.
• Small or large organisations: a small team with one edge site should lean on the provider's managed patching and focus on physical control and the uplink. A large estate needs a central register of sites, keys, link states and maintenance visits.

Detection and measurement

Metrics that show the programme is working:

• Percentage of provider maintenance visits matched to a ticket and an escort record.
• Control plane link availability per site, and the longest outage this quarter against the documented limit.
• Time from intrusion or tamper notice to SOC triage.
• Percentage of sites where a disconnection test was run in the last 12 months.
• Number of key policy or role binding changes made without an approved change.

Framework mapping

Common failure patterns

• Treating the rack as the provider's problem: the provider manages the software, but each provider assigns physical security to the customer. An unlocked comms room undoes the encryption design.
• Unescorted maintenance: engineers and Systems Integrators arrive with legitimate tickets; without matching and escorting, a social engineering visit looks identical.
• Single uplink: one circuit or one provider for the control plane link turns a routine fibre cut into a long management outage and a logging gap.
• Key custody left undefined: nobody owns the Nitro Security Key, the BitLocker recovery keys or the Cloud KMS role binding, so either data is lost on a mistaken change or keys leave with returned hardware.
• Never testing disconnection: teams discover node rejoin limits, local log retention caps and missing break-glass credentials during a real outage.
• Telemetry stranded on site: platform events not forwarded to the SIEM, so attacks during an outage are invisible after reconnection when sync caps apply.

Practitioner checklist

• Sign off a per-site responsibility matrix covering physical, network, keys, maintenance and return.
• House on-site cloud hardware in a locked, badge-logged and camera-covered space.
• Route intrusion and tamper notifications into the SOC queue.
• Build redundant, diverse control plane uplinks with firewall rules limited to documented endpoints.
• Record key custody and store recovery material outside the system.
• Put key policies and KMS role bindings under change approval and alerting.
• Forward platform security events and provider audit logs to the SIEM.
• Vault local break-glass accounts and alert on their use.
• Run a planned disconnection test at least yearly and record the results.
• Maintain a return and decommissioning runbook with key and media steps.

Standards and references

• AWS: Security in AWS Outposts
• AWS: AWS Outposts rack FAQs
• Microsoft Learn: Security features for Azure Local
• Microsoft Learn: Disconnected operations for Azure Local
• Google Cloud: Distributed Cloud connected security
• Google Cloud: Distributed Cloud connected overview
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Hybrid Cloud Security · Edge Computing Security Guide · Identity in DDIL and Disconnected Environments Guide · Data Centre Security Guide · Physical Intrusion Response Playbook