| Service model | Managed infrastructure and secure connectivity with responsibilities scoped to the workload.[1] | Compute Engine is IaaS. Google's shared-responsibility guidance says that for IaaS the bulk of security responsibilities are the customer's, while Google focuses on underlying infrastructure and physical security.[3] |
| Provisioning | DC Core maps dependencies, access, data location, backup and operational ownership before building or migrating the environment.[1] | Customers provision Compute Engine resources through Google Cloud interfaces and automation, selecting machine configuration, operating-system image, storage, network and location. Google also documents templates, managed instance groups and autoscaling for repeatable deployments.[10] |
| Management responsibility | DC Core can operate and patch the managed infrastructure, monitor service health and maintain agreed network controls. The customer normally retains its application and data.[1] | The customer selects and configures workload-level security controls, IAM, guest operating systems, applications, data protection and governance for Compute Engine. Google provides tooling and guidance rather than automatically assuming that operating role.[3] |
| Networking architecture | Private addressing, secured ingress and outbound-agent paths can connect workloads through DC Core's tenant-aware relay platform.[2] | Google Cloud VPC supports internal addresses, external addresses, firewall rules, Cloud NAT and load balancing. Compute instances can serve or fetch traffic without their own external IP by using the appropriate network service.[8] |
| Private admin access | Approved customer-side agents normally initiate outbound connections, avoiding general inbound VM management exposure.[2] | Identity-Aware Proxy TCP forwarding provides authenticated and authorised SSH/RDP or other administrative tunnels without a public routable IP on the target VM.[4] |
| Backups and DR | Encrypted backups and recovery controls are operated where agreed, with workload-specific retention and recovery objectives.[1] | Compute Engine offers snapshot schedules, machine images and Backup and DR Service. Google warns that protection must be implemented; the creation flow may preselect a method, but customers can change it or select no backups. Scope and restore testing still need ownership.[5] |
| Location and scale | Standard managed production tenancy data is designed for London, with France DR capacity, unless another arrangement is agreed.[1] | Compute Engine resources are hosted in regions and zones. Buyers choose the locations and distribution model that meet their latency, resilience and data-location requirements, while checking service availability by region.[9] |
| Support | Support can include operational work within the contracted managed boundary, not only advice about the underlying platform. | Basic Support includes billing, documentation, community resources and recommendations. Paid Standard, Enhanced and Premium packages add one-to-one technical support and different response/service levels.[7] |
| Pricing model | Scoped quote for infrastructure plus the selected management, monitoring, backup and support responsibilities. | Usage-based component pricing. Compute Engine uses on-demand rates and offers committed-use, sustained-use and Spot discounts subject to eligibility and workload behaviour; disks, snapshots and networking are separately relevant.[6] |
| Best suited for | Organisations seeking a UK-led managed operator for specific business workloads or transitional infrastructure. | Engineering teams that need Google Cloud's global scale, automation, data services or broader cloud-native ecosystem and can own the platform design. |