GCP to AWS Migration: What It Costs and What Breaks
- Egress is the line item nobody budgets and it is the one that arrives first. Google's Standard Tier internet egress from us-central1 is free to 200 GiB a month, then $0.085 per GiB to 10 TiB, $0.065 to 150 TiB and $0.045 above that, per Google's published Network Service Tiers pricing in August 2026.
- The exit-fee waiver is real but conditional: Google waives transfer charges for customers leaving, subject to a formal request and a 60-day window to end the deployment. A phased migration that keeps GCP running does not qualify, which is why most real migrations pay list egress anyway.
- The largest cost of a cloud migration is not transfer or compute. It is the two to four months of dual-running, when you pay for both clouds, plus the managed services on the destination side that have no clean equivalent and have to be rebuilt rather than moved.
- Data egress
- One line, estimated from storage size
- Compute on the destination
- Like-for-like instance mapping
- Engineering time
- The optimistic single-phase estimate
- Downtime
- One maintenance window
- Data egress, repeated
- Initial sync, delta syncs, then the final cutover sync
- Dual-running both clouds
- Two to four months at close to full cost on both sides
- Rebuilt managed services
- Anything without a clean equivalent is a build, not a move
- Destination compute before optimisation
- On-demand until the architecture settles and you can commit
- Observability, twice
- Two agents, two log pipelines, two bills, for the whole overlap
- Rollback capability
- The source stays warm until you trust the destination
How much does a GCP to AWS migration actually cost?
Three costs, in ascending order of size: data egress, which is mechanical and calculable; engineering time, which is the largest single number on most projects; and dual-running both clouds through the overlap, which is the one that surprises finance because it appears as two full invoices for months.
Egress you can compute today. Take your total data footprint, multiply by the applicable per-gigabyte rate, then multiply again by the number of times the data will cross, at least three for any migration that cannot afford extended downtime. That gives you a hard number in an afternoon, and on most mid-size estates it is a four or low five figure sum, which is not usually what kills a project.
Engineering time is the real cost. A migration is not a lift, it is a rewrite of every place your application touched a managed service. Identity and access, secrets, queues, schedulers, object storage clients, database drivers, load balancers, DNS, CI pipelines and the entire observability stack all change. On a mid-size estate that is measured in engineer-months, and the estimate should be built bottom-up from a service inventory rather than top-down from a gut feel.
Dual-running is the cost teams discover rather than plan. You cannot decommission the source until you trust the destination, and trust is earned across business cycles (a month-end close, a peak traffic day, a full backup and restore drill) not across a sprint. Two to four months of near-full spend on both clouds is normal, and on a $15,000-a-month estate that is $30,000 to $60,000 of pure overlap.
I have run this. The migration was GCP to Azure and AWS, executed solo with zero downtime, and it eliminated the need for a dedicated DevOps function afterwards. The full cost picture, including what the credits contributed, is in how I cut a $200K/year cloud bill by more than 70%, and the credit side specifically is in how to get $300K in cloud credits.
What does egress cost when you move data off GCP?
Google publishes Standard Tier internet egress from us-central1 as free for the first 200 GiB per month, then $0.085 per GiB up to 10,240 GiB, $0.065 per GiB up to 153,600 GiB, and $0.045 per GiB above that. Premium Tier egress is billed at Google's general internet egress rates, which are higher. Ingress into AWS is free.
Run the numbers on a realistic estate. Twenty terabytes at the Standard Tier rates is roughly $1,400 for a single pass: the first 200 GiB free, the next ten terabytes at $0.085 and the remainder at $0.065. Move that data three times (bulk sync, delta sync, cutover sync) and you are at roughly $4,200. That is real money and entirely predictable, which makes it the easiest part of the budget to get right and the least interesting to worry about.
The asymmetry that makes this tolerable is that ingress is free on both sides. You are only ever charged on the way out. That has a design implication for the migration itself: pull from the destination rather than push from the source wherever your tooling allows, and make sure whatever you pull with is not itself re-reading data it already has. A resumable, checksummed sync that transfers only changed objects is worth building properly, because a restarted sync that re-transfers everything doubles the largest transfer line in your budget.
Two smaller meters deserve attention because they hide inside the egress conversation. First, if you route the migration traffic through a NAT gateway on the AWS side, you pay AWS data-processing charges on every gigabyte arriving through it: free ingress is not free if it passes through a billed appliance. Second, the network tier you are on materially changes the Google-side rate, so check whether the workload you are draining is on Premium or Standard before you estimate.
The single largest reduction on the egress line is not a rate. It is deleting data before you move it. Most estates carry years of logs, orphaned snapshots, superseded backups and intermediate analytics output nobody has read since it was written. A lifecycle audit before the migration is the cheapest gigabyte you will ever save, because it removes cost from both the transfer bill and the destination storage bill permanently. The same audit is item 8 on the AWS cost optimization checklist, and doing it as a migration precondition is the best timing it will ever have.
Can you get free egress for leaving Google Cloud?
Sometimes, and the conditions matter more than the headline. Google waives data transfer charges for customers migrating away from Google Cloud, but the waiver requires a formal request and gives you a defined window, widely reported as 60 days, to end the deployment. AWS operates a comparable program with a similar 60-day structure.
The catch is structural rather than bureaucratic. These programs are designed for customers who are leaving, not for customers who are rebalancing. Eligibility is tied to terminating the deployment, and in Google's case reporting at the time of the announcement described account termination on completion as part of the requirement. A migration that keeps a Google project alive for analytics, or for one service you decided to leave behind, or simply because you are not confident enough to close the account within sixty days, does not fit the shape the program was designed for.
That shape conflicts with how careful migrations are actually run. The safest migration is phased: move a workload, watch it for a business cycle, keep the source warm as a rollback path, then move the next one. That deliberately spans more than sixty days and deliberately keeps the source alive. So the practical position most teams end up in is that the waiver exists, it is genuinely useful for a clean full exit, and it does not apply to the phased migration they should actually be running.
The regulatory backdrop is moving in customers' favour. The EU Data Act requires cloud providers to remove obstacles to effective switching between their own and competing services, which explicitly reaches commercial and contractual hurdles including transfer charges. The direction of travel is clear even where the current terms are narrow.
The useful action is therefore short: read the current waiver terms for your specific provider and account, ask your account manager directly whether your migration shape qualifies, and budget the full list-price egress anyway. A waiver that comes through is a pleasant variance. A waiver you assumed and did not receive is a budget hole discovered mid-project, and no cost model should have a conditional discount as a load-bearing assumption.
This is the shape the program was designed for. Submit the formal request before you start moving data, not after, and confirm the exact window and conditions in writing.
Keeping a rollback path alive is the correct engineering decision and it is incompatible with a programme that requires you to end the deployment inside 60 days. Pay the egress; it is cheaper than an unrecoverable cutover.
These programs are about switching away, not about rebalancing a multi-cloud estate. Budget full list-price egress and optimise the transfer instead: delete first, compress, and sync only deltas.
Google's published Standard Tier egress from us-central1 includes 200 GiB per month free per account. A small estate can often drain inside the free allowance across two or three months without paying anything.
At this size you are in a commercial conversation on both sides: the destination frequently offers migration assistance or credits, and the source has a retention incentive. The list rate is the worst price available to you.
Which GCP services have no clean AWS equivalent?
Most have a mapping; few have an equivalent. Object storage, virtual machines, managed Postgres and Kubernetes port almost mechanically. Data warehousing, serverless containers, document databases, globally consistent SQL and the identity model all require design decisions, and those decisions are where the schedule goes.
The clean ports first, because they are genuinely easy. Cloud Storage to S3 is an API and client-library change plus a data copy. Compute Engine to EC2 is an image and instance-family mapping. Cloud SQL for Postgres or MySQL to RDS is a well-trodden path with mature replication tooling. GKE to EKS is the same Kubernetes API with different node groups, a different load balancer controller and a different identity integration. Budget these in days and be roughly right.
The expensive ones are expensive for structural reasons. BigQuery has no single AWS product with the same shape. Its serverless, scan-priced execution model maps onto some combination of Athena over S3, Redshift Serverless or an open table format, each a different cost curve and a different operational posture. Firestore's document model and real-time listeners do not map onto DynamoDB without rethinking access patterns, because DynamoDB requires you to design keys around queries in a way Firestore does not. Spanner's globally consistent SQL has no drop-in destination at all.
Then there is the category that looks trivial and is not: the small glue services. Cloud Tasks, Cloud Scheduler, Pub/Sub subscriptions with their particular delivery semantics, Cloud Run's request-scoped concurrency and scale-to-zero behaviour, Secret Manager versioning, Cloud Build triggers. Each one is a day or two of work and there are usually a dozen of them, which is a fortnight nobody put in the plan because none of them individually seemed worth a line item.
The disciplined approach is to inventory every managed service in use with its monthly cost and its migration class (port, rebuild, or replace with something self-hosted) before you commit to a date. The inventory is a day of work and it is the difference between a schedule you can defend and one you will revise three times.
| Closest AWS destination | Migration class | What actually bites | |
|---|---|---|---|
| Cloud Storage | S3 | Port | Storage class mapping and lifecycle rules need rewriting, not copying |
| Compute Engine | EC2 | Port | Instance family and image mapping; check for x86-only dependencies |
| Cloud SQL (Postgres/MySQL) | RDS or Aurora | Port | Replication lag at cutover and extension parity |
| GKE | EKS | Port with rework | Load balancer controller, node identity, storage classes, ingress annotations |
| Cloud Run | App Runner, ECS Fargate or Lambda | Rebuild | Scale-to-zero and request-scoped concurrency semantics differ materially |
| BigQuery | Athena over S3, or Redshift | Rebuild | Different cost model entirely: scan-priced versus provisioned |
| Firestore | DynamoDB | Rebuild | Access patterns must be redesigned around keys; real-time listeners have no direct analogue |
| Spanner | Aurora, or a distributed SQL option | Replace | No drop-in for globally consistent SQL; this is an architecture decision |
| Pub/Sub | SNS plus SQS, or MSK | Rebuild | Delivery and ordering semantics differ; subscription filters do not port |
| Cloud Tasks and Scheduler | SQS with EventBridge Scheduler | Rebuild | Small, numerous, and always missing from the estimate |
| Secret Manager | Secrets Manager or Parameter Store | Port | Versioning and rotation semantics differ; Parameter Store is much cheaper |
| Cloud IAM | AWS IAM | Replace | Fundamentally different model; see the next section |
How different are the GCP and AWS identity models?
Different enough that translating your policies mechanically will produce a broken or dangerously permissive environment. Google organises access around a resource hierarchy with roles granted to principals at a level that inherits downward. AWS attaches policies to identities and, separately, to resources, and evaluates both together with explicit deny always winning.
The practical consequence is that a Google policy granted at the project level, which quietly covers every resource in that project through inheritance, has no single AWS equivalent. Reproducing it means either an over-broad identity policy (how migrations end up with wildcard permissions in production) or a considered set of narrower policies, which is real design work. This is one of the few places in a migration where the fast path is genuinely unsafe, not merely untidy.
Workload identity is the second discontinuity. On GKE, workload identity federation binds a Kubernetes service account to a Google service account. On EKS, the equivalent binds a Kubernetes service account to an IAM role, and every application that acquires credentials does so through a different mechanism with a different failure mode. Every service that talks to a managed resource needs its credential path re-established and re-tested, and the failures are silent until something tries to write.
The third is that AWS gives you resource-based policies (an S3 bucket policy, a KMS key policy, an SQS queue policy) which have no direct Google counterpart. This is genuinely a capability gain, and the migration is the right moment to use it: express least privilege on the resource side where it belongs, rather than porting a permissive project-level grant into a permissive account-level one.
Treat identity as its own workstream with its own owner and its own timeline, starting before any data moves. The teams that get burned are the ones that treat IAM as a translation exercise to be done during cutover week, discover halfway through that a service cannot authenticate, and reach for a wildcard to unblock the deployment. That wildcard is still there two years later.
- Access organised around an organisation, folder, project and resource hierarchy
- Roles granted at a level inherit downward to everything beneath
- Predefined roles cover most common jobs out of the box
- Service accounts are first-class resources you grant access to
- Project-level grants are convenient and quietly very broad
- Identity policies and resource policies evaluated together on every request
- Explicit deny always overrides any allow, anywhere
- Resource-based policies on buckets, keys and queues have no GCP counterpart
- Roles assumed through STS with temporary credentials by default
- Service control policies at the organisation level set outer boundaries
How long does a GCP to AWS migration take, and what does dual-running cost?
For a mid-size estate, three to five months end to end, with two to four of those months running both clouds. Dual-running is usually the largest single line in the budget: on a $15,000-a-month estate, three months of overlap at near-full cost on both sides is roughly $45,000, which typically exceeds the entire transfer bill several times over.
The overlap is not waste and should not be compressed to save money. It exists because you cannot decommission the source until the destination has survived the events that actually stress it: a month-end close, a peak traffic day, a full backup and restore drill, a deploy that goes wrong, an on-call incident handled by someone who was not on the migration team. Those events happen on a calendar, not on a sprint board.
You can, however, reduce the overlap cost without reducing the overlap. Scale the source down rather than off as traffic shifts; the rollback path needs to exist, not to be fully provisioned. Run the destination on on-demand pricing until the architecture stops changing, then buy commitments; committing to an architecture you are still altering is how teams end up with stranded reservations. And decommission the source in stages as each workload passes its confidence bar, rather than holding everything until a single final date.
A realistic phase structure looks like this. Two to four weeks of inventory and design, including the service mapping and the identity workstream. Three to six weeks building the destination environment and pipelines. Two to eight weeks migrating workloads in dependency order, stateless first and the primary datastore last. Two to eight weeks of parallel operation with traffic shifted and the source warm. Then two to four weeks of decommissioning and, finally, the optimisation pass that buys the commitments.
The zero-downtime part is entirely a function of sequencing, not tooling. Move stateless services first behind a traffic-shifting layer, replicate stateful systems and cut over with a short write pause rather than a long outage, and keep the rollback path live until you are past the events you were worried about. That is how I ran the GCP to Azure and AWS migration solo with zero downtime, and none of it required anything exotic: only a strict dependency order and the discipline not to move the database first.
- Weeks 1‑4Inventory, mapping and design
Every managed service listed with its monthly cost and its migration class: port, rebuild or replace. Identity workstream starts here. Data lifecycle audit runs here too, because deleting data before you move it is the cheapest saving available.
- Weeks 3‑8Build the destination
Accounts, networking, IAM roles, secrets, CI/CD pipelines, observability. Nothing user-facing moves yet. This phase overlaps design deliberately, because the design of the rebuild items is refined by building the easy ones.
- Weeks 6‑14Migrate workloads in dependency order
Stateless services first, then queues and schedulers, then caches, then the primary datastore. Initial bulk data sync happens here, followed by ongoing delta syncs. This is where most of the egress is billed.
- Weeks 12‑20Parallel operation with traffic shifted
Both clouds fully lit. Traffic on the destination, source warm as the rollback path. This is the expensive phase and the one that should not be compressed; it has to span a month-end and a peak day.
- Weeks 18‑24Staged decommissioning
Retire source workloads one at a time as each clears its confidence bar. Final data sync and verification. Scale down rather than delete until the last verification passes.
- Weeks 22‑28Optimisation pass and commitments
Only now buy Savings Plans and reserved capacity, because only now has the architecture stopped moving. Run the full cost hygiene loop against the new estate.
- Service identity: workloads cannot authenticate to managed resourcesGKE workload identity and EKS IAM roles for service accounts are different mechanisms with different failure modes
- DNS TTLs still set to hours from a decision made years agoDrop them to seconds a week before cutover, not on the day
- Hardcoded region and endpoint strings buried in configurationGrep the whole repository for the source provider's domains before you start
- Replication lag at the final data syncMeasure it under production write load, not on a quiet afternoon
- Queue delivery semantics differing from the sourceOrdering and at-least-once behaviour are not identical across providers
- Egress through a NAT gateway on the destination sideFree ingress is not free if it passes through a billed appliance
- Observability gaps during the overlapTwo agents, two log pipelines, and no single trace across the boundary
- Scheduled jobs firing on both clouds simultaneouslyThe classic double-charge, double-email, double-write incident
- Storage class mismatches inflating the destination billA lifecycle policy is not copied with the data; it has to be recreated
- Commitments bought too early against an architecture still in motionWait for the optimisation phase
- The rollback path quietly stops working because nobody tested itTest the rollback deliberately, once, before you need it
- Cost attribution tags absent on the new estate from day oneReconstructing ownership afterwards is the most tedious work in cost engineering
Is a GCP to AWS migration actually worth it?
Only for a structural reason: a pricing model that genuinely fits your workload better, a managed service you need that the source does not have, a credit or commitment programme worth more than the migration, or a compliance requirement. Migrating because AWS is more familiar is an expensive way to buy comfort.
Build the payback calculation honestly and it usually answers itself. Add the transfer cost, the engineering time at loaded cost, and the dual-running spend, then divide by the monthly saving you expect. If the payback is under a year, the case is straightforward. Between one and two years it depends on how confident you are in the saving estimate, which in my experience should be discounted by a third. Beyond two years, you are almost certainly better off running the cost hygiene loop on the cloud you are already on.
That last point deserves emphasis because it is the cheaper answer and nobody wants to hear it. Most of the saving people expect from a migration (commitments, removing per-gigabyte network paths, storage lifecycle policies, log retention, right-sized managed services) is available on the source cloud for a fraction of the effort. Do that work first. If the bill is still structurally wrong afterwards, you now have a clean comparison and a much better-understood estate to migrate, which makes the migration itself cheaper.
There is one case where the migration genuinely is the right call regardless of the arithmetic, and it is worth naming: when the credits and commercial terms on the destination are large enough to fund the move several times over. That is the situation I was in, and the reason the multi-cloud split made sense. Each workload went where its pricing and its credit position were best, rather than where an architecture diagram said it should be. The mechanics of securing that position are in how to get $300K in cloud credits.
If you want the payback modelled against your actual bill rather than an example, the cloud cost calculator is the fastest way to get a first number, and a cloud cost optimization engagement starts by answering exactly this question, often with the recommendation not to migrate at all.
GCP to AWS migration: common questions
→How much does it cost to migrate from GCP to AWS?
Three lines: egress, engineering time and dual-running. Egress is calculable: Google publishes Standard Tier internet egress from us-central1 at $0.085 per GiB from 200 GiB to 10 TiB, $0.065 to 150 TiB and $0.045 above, with the first 200 GiB per month free, and ingress into AWS is free. Engineering time is usually the largest number, and dual-running two clouds for two to four months typically exceeds the transfer bill several times over.
→Do you have to pay egress fees to leave Google Cloud?
Google waives transfer charges for customers migrating away, but the waiver requires a formal request and a defined window (widely reported as 60 days) to end the deployment, and it is aimed at customers who are fully leaving. A phased migration that keeps the source warm for rollback generally does not fit that shape. AWS runs a comparable 60-day program. Budget list price and treat a waiver as upside.
→Which GCP services are hardest to migrate to AWS?
BigQuery, Firestore, Spanner, Cloud Run and Pub/Sub. BigQuery's scan-priced serverless model has no single AWS equivalent, so you are choosing between Athena over S3 and Redshift with different cost curves. Firestore access patterns must be redesigned around DynamoDB keys. Spanner's globally consistent SQL has no drop-in. Cloud Run's scale-to-zero and concurrency semantics differ from every AWS option.
→How long does a cloud migration take?
Three to five months end to end for a mid-size estate, of which two to four months are spent running both clouds in parallel. The parallel phase should span at least one month-end close and one peak traffic day, because those are the events that actually test the destination. Compressing it is the most common way a migration turns into an incident.
→How do you migrate clouds with zero downtime?
Sequencing rather than tooling. Move stateless services first behind a traffic-shifting layer, then queues and schedulers, then caches, and the primary datastore last with a short write pause rather than an outage. Keep the source warm as a rollback path until the destination has survived a full business cycle. Drop DNS TTLs to seconds a week ahead, and test the rollback deliberately before you need it.
→Should you migrate clouds to save money?
Usually not on its own. Most of the saving people expect from a migration (commitments, removing per-gigabyte network paths, storage lifecycle policies, log retention) is available on the cloud you are already on for a fraction of the effort. Migrate for a structural reason: a pricing model that genuinely fits your workload, a service you need, a compliance requirement, or commercial terms and credits large enough to fund the move several times over.