// Capability Statement — Download PDF
Insights / AWS/Azure to GDC
Cloud Migration

AWS/Azure to GDC: what the migration really involves.

Google Distributed Cloud — including its air-gapped configurations — is pulling government workloads. Service mapping, compliance re-inheritance, and the playbook that keeps a migration from becoming a rewrite.

Google Distributed Cloud (GDC) has become a serious destination for government workloads, including its air-gapped configurations built for classified environments. That has teams running on AWS GovCloud or Azure Government asking a practical question: what does it take to move? Short answer: less than a datacenter migration, more than a repoint — and how you built determines which end of that range you land on.

What GDC is, in one paragraph

GDC is Google's portfolio for running Google Cloud infrastructure outside Google's public regions: connected configurations for sovereign and edge requirements, and air-gapped configurations for classified missions with no external connectivity. It is Kubernetes-native at its core: the platform primitives are GKE-based, which is precisely why containerized workloads migrate cleanly and VM-shaped legacy workloads don't.

The migration, service by service

You run todayYou land onFriction
EKS / AKS clustersGKE / GDC KubernetesLow — manifests mostly port
EC2 / Azure VMsGDC VM runtime or containerize firstMedium-high — refactor pays off
S3 / Blob StorageObject storage (S3-compatible APIs)Low — mind egress and data gravity
IAM policiesGoogle IAM modelMedium — different philosophy, full remap
CloudFormation / ARMTerraform on Google providersLow if you're already Terraform
Managed databasesPlatform equivalents or self-managedMedium — inventory features before committing

The part people underestimate: compliance re-inheritance

Your authorization doesn't travel with your workload. Control inheritance maps rebuild against the new platform's posture, evidence collection re-points at new APIs, and the boundary diagram gets redrawn. This is exactly where accelerated-ATO practices earn their keep: if your evidence is generated by pipelines rather than typed into documents, re-homing it is configuration work, not a rewrite.

The playbook that works

Containerize first, before the move, on your current cloud; it de-risks everything after. Terraform everything so environments are declarative and portable. Move stateless services first, data second, stateful legacy last. Re-map identity early: IAM is where migrations stall. And treat the authorization work as a parallel track from day one, not a phase at the end.

Quick answers

Do we lose our ATO when we migrate to GDC?
Your existing authorization doesn't transfer automatically: the boundary, inheritance, and evidence all change. But a migration is also an opportunity: re-platforming with automated evidence collection typically produces a stronger, faster-to-maintain authorization than the one you left.
Is GDC only for air-gapped classified work?
No. GDC includes connected configurations for sovereignty, latency, and edge requirements as well as air-gapped configurations for classified environments. The air-gapped story is what draws mission programs, but it's one configuration among several.
How long does an AWS/Azure to GDC migration take?
It tracks your architecture more than your size. Containerized, Terraform-managed, Kubernetes-native estates move in months; VM-heavy estates with hand-built IAM and managed-service dependencies take substantially longer; often it's worth modernizing in place first.
Put this to work

Need it done, not just explained?

This is the work we do every day. Tell us where your program stands and we'll give you a straight answer.

Talk to Ausper