Background
The client had spent years building a mature SaaS platform on AWS. It worked well—until growth started revealing its limits. Enterprise prospects in regulated industries were asking for GCP deployments. Regional expansion targets required cloud presence in zones where AWS pricing or compliance wasn't favorable. And the finance team was increasingly uncomfortable with single-vendor dependency at scale.
The strategic ask was clear: become a multi-cloud platform without rebuilding the product. We designed and implemented the transition in a way that kept AWS customers unaffected, brought GCP to parity without code duplication, and unified operations so the engineering team wasn't managing two separate infrastructure stacks.
The Challenges
- •The platform used AWS-native services (RDS, S3, Lambda, SQS) throughout—tight coupling made direct portability impossible without significant re-architecture
- •Enterprise deals were stalling because the platform couldn't deploy to GCP—representing material revenue at risk
- •Operating two independent cloud stacks would have doubled infrastructure complexity and engineering overhead
- •Data residency and compliance requirements varied by region, making a naive 'replicate everything everywhere' approach untenable
- •Existing AWS customers needed zero disruption during the transition—any migration risk was unacceptable
“We were growing fast, but our AWS-only architecture was becoming a constraint. Enterprise deals that should have been easy were stalling because we couldn't say yes to GCP.”
Our Approach
We designed the expansion in three phases: introduce cloud-agnostic abstractions over AWS-native services, replicate the production stack on GCP with equivalent services, and unify operations so both clouds are managed through a single control plane.
Phase 01: Cloud-Agnostic Abstraction Layer
Before writing a single line of GCP configuration, we introduced abstraction layers over the AWS-specific parts of the platform. Storage calls went through a provider-agnostic interface. Queue publishing abstracted SQS and Pub/Sub behind a common API. Terraform modules were refactored to be cloud-parameterized, not AWS-specific. This was the unglamorous work that made everything else possible—without it, every GCP deployment would have been a fork.
- •Storage provider interface: S3 and GCS behind a unified storage API
- •Queue abstraction: SQS and GCP Pub/Sub behind a common messaging layer
- •Terraform modules parameterized for cloud target—one codebase, two clouds
Phase 02: GCP Stack Deployment & Data Parity
With abstractions in place, we mapped every AWS service to its GCP equivalent and deployed the full production stack on GCP: GKE for Kubernetes workloads, Cloud SQL for managed databases, GCS for object storage, Pub/Sub for messaging, and Cloud Armor for security. We built cross-cloud data sync for accounts that needed to exist on both clouds, with conflict resolution and consistency guarantees.
- •AWS → GCP service mapping: EC2/EKS → GKE, RDS → Cloud SQL, S3 → GCS, SQS → Pub/Sub
- •Cross-cloud data sync with eventual consistency and conflict resolution for shared accounts
- •Unified identity management via federated identity provider—single login across both clouds
Phase 03: Unified Operations & Observability
We built a single operations plane that covers both AWS and GCP: centralized logging to Datadog, unified alerting, and a multi-cloud CI/CD pipeline that deploys to either or both clouds based on routing configuration. Cost dashboards aggregate spend across both clouds. Oncall runbooks were updated to be cloud-agnostic—engineers don't need separate playbooks for AWS and GCP incidents.
- •Centralized observability via Datadog: logs, metrics, and traces from both clouds in one view
- •Multi-cloud CI/CD: GitHub Actions pipelines with cloud-targeted deployment stages
- •Unified cost dashboard aggregating AWS and GCP spend by product, team, and region
The Results
- •Platform now runs production workloads on both GCP and AWS—enterprise customers choose their cloud at onboarding
- •Stalled enterprise deals closed after GCP deployment option became available
- •AWS vendor dependency reduced—the team now has real negotiating leverage on pricing
- •Engineering overhead did not double: one Terraform codebase, one CI/CD pipeline, one observability stack
- •Faster regional expansion: the team can now deploy to the cloud with the best presence in each market
“We went from 'AWS only' to 'your cloud, your choice.' Enterprise deals that were stuck opened up within weeks of the GCP launch.”
Final Takeaway
Multi-cloud is an architecture problem before it's a deployment problem. The key is introducing the right abstractions early so you're not maintaining two divergent codebases. With Kubernetes for workload portability, Terraform for consistent infrastructure-as-code, and a unified operations plane, a mature AWS platform can expand to GCP without fragmenting the engineering team or creating a maintenance nightmare.
Technologies We Use
Modern, proven technologies to build robust applications
Kubernetes
Terraform
AWS (EKS, RDS, S3, SQS)
GCP (GKE, Cloud SQL, GCS, Pub/Sub)
Docker
GitHub Actions
Datadog
Helm
See More Work
Engineering Partners for Products That Ship
From applied AI and resilient cloud platforms to full-stack delivery—we help you scope with clarity, build with rigor, and release with confidence.