Start with the big picture before we meet the details.

The simple definition

Google Distributed Cloud, often shortened to GDC, is a family of products and services that extend Google Cloud’s infrastructure and services to other locations: your own data centres, remote edge sites such as factories, stores, and telecom towers, and fully isolated secure environments. It lets you run modern, container-based applications close to where the data is created or where the law says it must stay, while using the same tools and ways of working as in the public Google Cloud.

Why it exists

The public cloud is wonderful for most work, but some situations do not fit. Laws may require that data never leaves a country or a building. A machine on a factory floor may need an answer in a few milliseconds, which a distant region cannot give. A mine, ship, or remote store may have unreliable internet. A bank may own expensive equipment it cannot move. A defence agency may need a system with no connection to the internet at all. GDC was created for these cases.

Where it is used

Typical users include governments and defence bodies, banks and insurers, telecom operators building fast mobile networks, manufacturers with smart factories, retailers with in-store analytics, hospitals, energy and mining companies, and any organisation with rules or physics that keep work close to home.

A few simple ideas make the whole portfolio easy to understand.

Containers and Kubernetes in two minutes

Modern applications are packaged into containers, which are neat boxes holding a program and everything it needs to run. Kubernetes is the popular system that runs many containers across many machines, starts new ones when needed, restarts broken ones, and keeps everything organised. GDC is built on Kubernetes. This is the big reason an application written for Google Cloud can run, with little change, in a GDC location. The same Kubernetes, the same tools, and the same habits apply everywhere.

Control plane and workers

A Kubernetes cluster has a control plane, which is the brain that decides what should run where, and worker nodes, which are the machines that actually run the containers. Much of the design of GDC is about where the brain lives and what happens when it cannot talk to the wider cloud.

Why not just use the public cloud?

• Law and policy. Some data may not leave a country, a building, or an organisation.
• Speed. Some actions need answers in milliseconds, close to the source.
• Connectivity. Some sites have slow, costly, or unreliable links.
• Data volume. Sending huge video or sensor streams to the cloud can be slow and costly. Processing them nearby is wiser.
• Existing investment. Valuable hardware, special devices, or legacy systems cannot simply move.
• Security. Some environments require physical separation from the internet.

GDC is not one product but a family. Here is a map of the main members.

flowchart TD
  A["Google Distributed Cloud"] --> B["Software only"]
  A --> C["Connected"]
  A --> D["Air-gapped"]
  B --> B1["Runs on your own servers in your data centre"]
  B --> B2["For VMware or for bare metal servers"]
  C --> C1["Google-provided hardware at your edge or site"]
  C --> C2["Managed from Google Cloud with a local control plane"]
  D --> D1["Google-provided hardware and software in an isolated environment"]
  D --> D2["No connection to the public internet or Google Cloud"]
  A --> E["Common thread: Kubernetes, fleet management, and consistent tools"]
    

Names you may meet

• Anthos. The older brand for Google’s hybrid and multi-cloud platform, now largely folded into GKE Enterprise and the software-only GDC offerings.
• GKE Enterprise. The premium edition of Google Kubernetes Engine, which adds fleet management, policy, and service mesh across clusters in many places.
• Google Distributed Cloud Edge. The earlier name for the connected offering, which has been renamed over time.
• Google Distributed Cloud Hosted. The earlier name for the air-gapped offering.
• Sovereign cloud options. A wider set of Google Cloud choices for data control, including local partners, that sit beside GDC. Check current descriptions.

The most flexible option: you bring the servers, Google brings the software and the management tools.

What it is

With the software-only offerings, you install Google’s Kubernetes-based software on your own servers, either on top of a virtualisation layer such as VMware, or directly on bare metal, which means servers with no virtualisation layer in between. The clusters are then registered with Google Cloud so that you can see and manage them from one place, as part of a fleet.

flowchart LR
  A["Google Cloud console and APIs"] --> B["Fleet management"]
  B --> C["Connect gateway and agents"]
  C --> D["Cluster in your data centre one"]
  C --> E["Cluster in your data centre two"]
  C --> F["Cluster in another cloud"]
  C --> G["Cluster in Google Cloud region"]
  B --> H["Policy and configuration pushed to all clusters"]
  B --> I["Logs and metrics flow back to Cloud Operations"]
    

The ideas behind fleets

• Fleet. A group of clusters managed together, wherever they run.
• Connect agents and gateway. A small outbound connection from each cluster lets Google Cloud reach it for management without opening inbound firewall holes.
• Configuration as code. Settings and policies are stored in a Git repository, and tools such as Config Sync apply them to every cluster, keeping them identical.
• Policy controllers. Rules that automatically block unsafe or non-compliant settings before they take effect.
• Service mesh. A layer that manages secure communication between services across clusters.
• Unified observability. Logs and metrics from all clusters in one set of dashboards.

Who does what

When you do not want to buy, build, and run servers at many remote sites, Google can bring a managed package.

What it is

The connected offering places Google-supplied and Google-managed hardware at your site or at a nearby telecom location. The hardware comes as racks or as smaller server units, depending on the option. It connects back to a Google Cloud region for management, and runs Kubernetes workloads, and in many cases virtual machines, close to your users and machines.

The key idea: a local control plane

sequenceDiagram
  participant G as Google Cloud Region
  participant E as Edge Site Control Plane
  participant W as Local Workloads
  participant D as Devices and Users
  G->>E: Send configuration and updates
  E->>W: Run containers and virtual machines
  D->>W: Requests served locally with low delay
  Note over G,E: The wide area link goes down
  D->>W: Requests still served
  W->>W: Workloads keep running on local control plane
  Note over G,E: The link returns
  E->>G: Report status and sync changes
    

In the connected design, the control plane for the edge site runs locally. This means applications already running can continue to serve people and machines even if the link to the wider cloud breaks for a while. While disconnected, you usually cannot make new management changes from the cloud, and some cloud-dependent features pause, but the shop floor, the store, or the radio site keeps going. Check how long and in what ways each option can run disconnected.

Typical uses

Who does what

Google ships, installs, monitors, and maintains the hardware and the platform software. You supply the physical space, power, cooling, and network connections, and you run your applications and look after your data. The exact split of duties, called the shared responsibility model, is defined in the agreement, and you should read it carefully.

For the highest security and sovereignty needs, the cloud itself comes inside the secure room, with no outside connection.

What it is

An air gap is a physical separation between a secure system and every other network, including the internet. The air-gapped offering delivers a complete cloud environment, with hardware and software supplied by Google or its partners, installed in a customer’s or a partner’s secure facility. It runs without any connection to the public internet or to Google Cloud during normal operation. Everything needed to run it lives inside the isolated boundary.

What it offers

• Core infrastructure. Kubernetes clusters, virtual machines, storage, and networking.
• Managed data services. Selected databases and other services delivered inside the environment.
• Artificial intelligence services. Selected machine learning, language, speech, vision, and, in newer releases, generative AI model options that run locally. Check the current list.
• Consistent tools. Familiar Google Cloud style interfaces, programming interfaces, and identity concepts, adapted for the isolated environment.
• Strong controls. Operation by vetted staff, strict audit, and compliance with demanding government and industry standards. Certifications and accreditation levels differ by region and time, so confirm them.

How updates arrive

Since the environment cannot reach the internet, new software versions and security fixes arrive through a controlled, offline update process. Signed packages are brought into the facility through approved media or one-way channels, are scanned and verified, and are applied under change control. This is slower than internet-based updates, so planning for patches is a core skill in air-gapped work.

Operating models

• Customer-operated. The customer’s own cleared staff run the environment, with Google’s training and support within the rules of the isolation.
• Partner-operated. A trusted local company operates it, which helps meet national control requirements.
• Google-supported. Google provides defined support under strict security processes, without needing a live connection to the environment.

The exact model depends on the country, the customer, and the regulations. Always confirm which arrangements are currently available for your region.

Whatever the offering, a few building blocks appear again and again.

Virtual machines and containers together

Not every application is ready for containers. Many companies still have older software that runs in virtual machines. GDC offerings often include a way to run virtual machines on the same Kubernetes platform, so old and new workloads share one set of tools. This eases migration. You can move an old application as it is first, and modernise it step by step later.

Storage and data

Edge and on-premises sites need storage for local data. Choices include local disks, shared storage systems, and storage integrations that your platform supports. Plan which data must stay local, which can sync to the cloud later, and how to back it up. Remember that local storage has a fixed size, since you cannot add capacity in seconds as in a public cloud.

Connectivity options

• VPN. An encrypted tunnel over the internet. Quick to set up, and suitable for many sites.
• Dedicated interconnect. A private physical link to Google. Faster and steadier, and more costly.
• Cellular or satellite links. For remote sites, usually with tight bandwidth and higher delay.
• No link at all. For air-gapped environments, where data and updates move through controlled offline processes.

Distributed projects work best when planned in stages.

flowchart LR
  A["Define the reason: law, latency, or location"] --> B["Choose the offering"]
  B --> C["Design sites, network, and security"]
  C --> D["Pilot at one site"]
  D --> E["Measure delay, reliability, and cost"]
  E --> F{"Meets goals"}
  F -->|"No"| C
  F -->|"Yes"| G["Automate rollout to more sites"]
  G --> H["Operate with fleet tools and monitoring"]
  H --> I["Patch, upgrade, and review regularly"]
  I --> J["Retire or expand sites as needs change"]
    

The flow of data between edge and cloud

A common pattern is process locally, summarise centrally. Raw data, such as video or sensor streams, is analysed at the edge. Only results, alerts, and small summaries travel to the cloud for long-term storage, reporting, and training of better models. The improved models are then sent back to the edge. This loop keeps bandwidth low, reaction fast, and learning continuous.

An honest view of what you gain and what you give up.

The big trade-offs

Control versus convenience. Running work yourself, close to home, gives control and compliance at the price of the easy, pay-as-you-go scale of the public cloud.

Your hardware versus Google’s hardware. Software-only reuses equipment you already own and gives choice, but you carry the hardware duties. Google-managed hardware reduces your effort but adds cost and tighter choices.

Connected versus isolated. Connection brings updates, monitoring, and cloud features. Isolation brings maximum security and sovereignty, and brings slower change and more manual work.

Consistency versus local fit. Standard designs make many sites easy to run. Special local needs may push you to custom solutions that are harder to maintain.

Edge speed versus central power. The edge answers fastest, but central regions have more capacity for heavy training and big analytics. Most designs use both.

Spreading computing across many places means spreading the places to defend. Plan security from day one.

The shared responsibility idea

Security duties are shared between you and Google, and the split is different for each offering. With software-only clusters, you secure the hardware, the buildings, the network, the operating system layers you control, and your applications, while Google secures its software and cloud services. With connected and air-gapped offerings, Google handles more of the hardware and platform, and you handle the site, your data, your identities, and your applications. Read the responsibility table for your offering and assign every duty to a named owner.

Core protections

• Physical security. Locked rooms, cameras, access logs, and tamper checks for edge hardware, which may sit in less protected places such as shops and telecom huts.
• Hardware trust. Secure boot and hardware-based identity, so only approved software runs, with attestation where available.
• Encryption. Encrypt data at rest on local disks, and in transit between sites and to the cloud, with strong key management. Consider keeping keys outside the site, or in a protected module.
• Identity and access. Use central identity, least-privilege roles, strong sign-in, and short-lived credentials for people and programs.
• Workload identity. Give each application its own identity, and allow it to reach only what it needs.
• Network segmentation and policy. Separate workloads with network rules, and use a service mesh for encrypted, authenticated service-to-service communication.
• Policy as code. Use policy controllers to block unsafe settings, such as containers running with excess power or images from unknown sources.
• Supply chain security. Use signed, scanned images from trusted registries, and check what runs at the edge.
• Patching. Keep clusters and software on supported versions, with planned and tested upgrades.
• Audit and monitoring. Collect logs from every site, protect them from tampering, and alert on unusual events.
• Backups and recovery. Protect local data, store copies safely, and rehearse restoring.

Special points for air-gapped sites

• Controlled media. Every item brought in or out is scanned, logged, and approved.
• Cleared staff. Only authorised, vetted people may operate the environment.
• Strict separation of duties. No single person should be able to change critical settings alone.
• Offline verification. Update packages are checked by digital signatures before use.
• Insider risk planning. With no outside monitoring, internal oversight must be strong.

Running many small sites is a different job from running one big data centre.

What to watch

• Link health. Connection status, delay, and bandwidth between the site and the cloud.
• Capacity. CPU, memory, storage, and graphics processor use against the fixed limits of each site.
• Version drift. Sites running different versions of software or settings.
• Policy violations. Clusters that no longer match the approved configuration.
• Local workload health. Errors, restarts, and slow responses of applications.
• Backup success. Make sure local data is protected.
• Physical conditions. Power, temperature, and access events.

Reliability thinking for edge sites

• Plan for disconnection. Decide what each application does when it cannot reach the cloud. Queue data locally and send it later.
• Plan for site failure. Decide which other site or region takes over, and how data is replicated.
• Plan for no staff on site. Make remote repair, replacement, and reinstallation simple and well-documented.
• Plan for power loss. Use backup power, and make sure systems restart cleanly.
• Practise. Test failures on purpose in a pilot, so surprises happen when stakes are low.

Good planning prevents both empty racks and overloaded ones.

Performance points

• Latency gains. The main benefit is a shorter distance. Measure real delay from your devices to the site and to the cloud region, and compare.
• Local compute. Edge sites may include graphics processors or accelerators for artificial intelligence. Check availability and capacity.
• Network bandwidth. Links to the cloud may be a bottleneck for synchronising large data.
• Storage speed. Local storage type and layout affect databases and analytics.
• Fixed capacity. Plan for peaks, since you cannot scale in seconds. Keep headroom, and know the lead time for adding hardware.

What you pay for

Pricing is usually by agreement and changes over time, so ask for the current terms. In general, think about these items:

Helpful habits and harmful habits seen again and again in real projects.

Helpful patterns

Anti-patterns to avoid

More things to steer clear of

• Assuming constant connectivity. Applications that stop when the link drops make edge sites useless.
• No capacity headroom. A fixed site cannot absorb surprise growth.
• Ignoring physical security. Edge hardware may sit in unguarded places.
• Forgetting upgrade planning. Clusters that fall behind lose support and security fixes.
• Treating air-gapped like a normal cloud. Updates, tooling, and troubleshooting work differently when offline.
• Skipping staff training. Operating distributed Kubernetes needs real skills.

A checklist of habits that experienced teams rely on.

Habits that work

• Start with the reason. Law, latency, location, or connectivity, written clearly.
• Pilot first with one workload at one site.
• Standardise. Few hardware types, one site template, one set of policies.
• Use fleet management and policy as code from the start.
• Design for disconnection with local queues and clear fallback behaviour.
• Secure every site equally, including physical access and patching.
• Plan capacity with headroom and known lead times.
• Rehearse failures and recoveries.
• Document the shared responsibility split and name an owner for each duty.
• Watch cost over several years.
• Train people in Kubernetes, security, and operations.
• Track product changes and review the roadmap with Google regularly.

Mistakes beginners often make

Common ways organisations use the portfolio. These are typical scenarios, not claims about any particular company.

The right choice follows from why the workload cannot run in a normal cloud region.

flowchart TD
  A["Why can this workload not run in a normal Google Cloud region"] --> B{"Must it be fully disconnected from the internet"}
  B -->|"Yes"| C["Air-gapped offering"]
  B -->|"No"| D{"Do you already own suitable servers and want to reuse them"}
  D -->|"Yes"| E["Software-only clusters on your hardware"]
  D -->|"No"| F{"Do you need managed hardware close to users or machines at many sites"}
  F -->|"Yes"| G["Connected offering at the edge"]
  F -->|"No"| H{"Is data location the only concern"}
  H -->|"Yes"| I["Consider regional controls and sovereign cloud options in Google Cloud"]
  H -->|"No"| J["Use a normal Google Cloud region"]
    

Comparison with other providers

Other large cloud companies also offer ways to bring their services closer to customers, with their own names and designs. Compare them on the services they bring, the way they manage Kubernetes, the hardware options, the compliance coverage in your country, the skills of your staff, and the total cost. Choose by your own requirements, not by brand.