DEV Community

Cover image for Moving Storage from GCP to AWS: Cloud Storage, Disks and File Shares
CobuildX AI profile image Emmanuel R
Emmanuel R for CobuildX AI

Posted on Originally published at cobuildx.ai

Moving Storage from GCP to AWS: Cloud Storage, Disks and File Shares

#devops #cloud #aws #googlecloud

A plain-English guide to moving storage from Google Cloud to AWS: Cloud Storage, Persistent Disk, Filestore, backups and transfer tools. What replaces what, how storage classes and access change, how to copy the data safely, what changes on the bill, and a step-by-step plan.

Every app keeps data somewhere. Photos that users upload. Disks that servers run on. Folders that many machines share. Backups. Records that must be kept for years. All of this is "storage". When you move from Google Cloud (GCP) to AWS, storage is often the biggest thing to carry across.

On GCP, storage means three main things:

  • Cloud Storage keeps files in buckets. A bucket is like a big folder in the cloud. Each file in it is called an object.
  • Persistent Disk and Hyperdisk are the hard drives attached to virtual machines.
  • Filestore is a shared folder that many machines can use at the same time.

Around these sit backups and tools for copying data.

Storage looks easy to move. A bucket is a bucket. But the details are different. The cheap "cold" storage works in a different way. Access rules are written in a different way. And copying many terabytes takes time and money. On top of that, every file must arrive whole. Not one file can be lost or changed.

"S3 is effectively a living, breathing organism."

— Andy Warfield, VP and Distinguished Engineer at Amazon S3, in Building and operating a pretty big storage system called S3

That is a good way to think about the move. You are not just dropping files into a box. You are moving into a service with its own habits. This guide covers:

  • Which AWS service replaces each GCP storage service
  • What works differently on AWS
  • How to copy the data safely
  • What changes on the bill
  • A simple step-by-step plan

The Quick Map

Here is each GCP storage service and its closest match on AWS. The rest of the post explains each row.

Storage service map from Google Cloud to AWS: Cloud Storage to Amazon S3, Persistent Disk and Hyperdisk to Amazon EBS, Local SSD to EC2 instance store, Filestore to Amazon EFS or FSx, Backup and DR to AWS Backup, and Storage Transfer Service to AWS DataSync

GCP Closest AWS match Watch out for
Cloud Storage Amazon S3 Cold storage works differently
Autoclass S3 Intelligent-Tiering Very small files are not moved to cheaper tiers
Persistent Disk / Hyperdisk Amazon EBS You set disk speed yourself
Regional Persistent Disk No direct match An EBS disk lives in one data center
Local SSD EC2 instance store Data is lost when the machine stops
Filestore Amazon EFS, or Amazon FSx Pick by how the folder is shared
Google Cloud NetApp Volumes Amazon FSx for NetApp ONTAP Same NetApp tools on both sides
Backup and DR Service AWS Backup Backup plans are set up again, not copied
Storage Transfer Service AWS DataSync DataSync can read Cloud Storage directly
Transfer Appliance Copy over the network with DataSync Snowball is closed to new customers

What about Snowball? Snowball was AWS's way to ship large amounts of data on a physical device. But AWS stopped offering Snowball Edge to new customers on November 7, 2025. For a move from one cloud to another, copying over the network is the normal path anyway.

Cloud Storage to Amazon S3

Cloud Storage and Amazon S3 work the same basic way. You make buckets. You put files in them. Each file has a name, its data and a few labels (called metadata). Almost everything you do in one, you can do in the other.

Google even offers an S3-style way to talk to Cloud Storage. That is why many AWS tools can read your GCP buckets directly.

Storage classes

A storage class is a price plan for your files. Files you read often go in a normal class. Files you rarely read go in a cheaper "cold" class. You pay less to keep them, but more to read them.

Both clouds have these classes, and the names roughly line up. But there is one big difference. On GCP, every class gives your file back in milliseconds, even Archive. On AWS, the two coldest classes do not. You must first ask AWS to restore the file, and that can take minutes or hours.

Cloud Storage class S3 class to use Shortest time you pay for How fast you can read it
Standard S3 Standard No minimum Right away
Nearline S3 Standard-IA 30 days Right away
Coldline S3 Glacier Instant Retrieval 90 days Right away
Archive S3 Glacier Instant Retrieval 90 days Right away
Archive (if nobody needs it fast) S3 Glacier Deep Archive 180 days Hours, after a restore
Autoclass S3 Intelligent-Tiering No minimum Right away

These numbers come from the S3 storage class guide. One more thing to know: in S3 Standard-IA and Glacier Instant Retrieval, every file is billed as if it were at least 128 KB. If you have millions of tiny files, a cold class can cost more, not less.

Rule of thumb: if an app still reads old files, move Archive to Glacier Instant Retrieval. Use Deep Archive only for files nobody needs in a hurry, like old backups and legal copies.

Bucket settings

Most bucket settings have a direct match on AWS. They just have new names:

Cloud Storage Amazon S3
Lifecycle rules (move or delete old files) S3 Lifecycle
Object versioning (keep old copies) S3 Versioning
Dual-region and multi-region buckets A bucket in one region, plus S3 Replication if you need a second copy
Retention lock (files can't be deleted) S3 Object Lock
Your own encryption keys (Cloud KMS) Encryption with AWS KMS keys
Pub/Sub notifications when a file changes S3 Event Notifications
Signed URLs (short-lived download links) Pre-signed URLs
gcloud storage command line aws s3 command line

Who can read and write

On GCP, most teams give people and apps a role on the bucket, like "Storage Object Viewer". On AWS, access comes from two places. IAM policies say what a user or app may do. A bucket policy says who may use the bucket.

Leave Block Public Access turned on. It stops a bucket from being opened to the whole internet by mistake. New buckets have it on by default. If files really must be public, like images on a website, serve them through CloudFront instead of opening the bucket.

Disks: Persistent Disk to EBS

Disks for virtual machines move to Amazon EBS. The main change is how speed works.

Disk speed is measured in IOPS: how many reads and writes the disk can do each second. On GCP, a bigger disk is often a faster disk. On AWS, the usual disk type (gp3) lets you choose the speed on its own. Every gp3 disk starts at 3,000 IOPS, and you pay extra to go higher.

GCP disk EBS disk Good for
pd-standard st1 (hard drive), or gp3 Big files read from start to end
pd-balanced gp3 Most apps
pd-ssd gp3 with more IOPS Busy databases
pd-extreme, Hyperdisk Extreme io2 Very busy databases

Two GCP disks have no exact match:

  • Regional Persistent Disk keeps a copy of the disk in two zones (two separate data centers). An EBS disk lives in one zone. On AWS, you get the same safety another way: a database copy in a second zone, or regular snapshots.
  • Local SSD becomes EC2 instance store. The warning is the same on both clouds: the data is gone when the machine stops. Use it only for data you can rebuild.

Disks usually move together with their machines. AWS Application Migration Service copies a running machine and its disks to AWS, and keeps them in sync until you switch.

Shared Folders: Filestore to EFS or FSx

Filestore gives many machines one shared folder. Machines reach it over the network using NFS, a common way to share folders on Linux. AWS has a few choices. Pick by what your apps need:

  • Amazon EFS is the simple match for most Filestore use. It uses NFS. It grows and shrinks on its own, so you never pick a size. It keeps your data in several zones. You pay for what you store.
  • Amazon FSx for NetApp ONTAP fits apps that need both Linux and Windows sharing, or NetApp features like instant copies. It is also the direct match for Google Cloud NetApp Volumes.
  • Amazon FSx for Lustre is for very heavy work, like training AI models. It can read files straight from S3.
  • Amazon FSx for Windows File Server is for Windows apps.

One tip: EFS is fast when many machines read at once, but each small file takes a little time to open. Apps that open thousands of tiny files one by one can feel slower. Test with your real app before you decide.

Moving the Data

How the data moves: Cloud Storage buckets are copied to Amazon S3 by AWS DataSync without an agent; Filestore shares are copied to EFS or FSx by a DataSync agent; disks move with their virtual machines through AWS Application Migration Service; a final sync runs before the switch

For buckets, the best tool is AWS DataSync. It reads Cloud Storage directly. You give it a key from GCP, and it copies files into S3. For bucket to bucket copies, you don't need to install anything on GCP.

DataSync also checks every file after it copies it. On later runs, it only copies what changed. And it writes a report, so you can prove what was moved.

For Filestore, DataSync needs a small helper machine (an "agent") running on GCP, close to the data. For disks, move the whole machine with Application Migration Service.

A safe copy follows the same steps every time:

  1. First full copy while the old system keeps running. For big buckets, this can take days.
  2. Catch-up copies that only move what changed. Each one is shorter than the last.
  3. Final copy. Stop writes for a short time, run one last copy, then point your apps at AWS.
  4. Check everything. Compare the number of files, their sizes and their checksums. A checksum is like a fingerprint of a file. If the fingerprints match, the file arrived unchanged.

"These are simple mechanisms that protect you from a large class of risks."

— Andy Warfield, VP and Distinguished Engineer at Amazon S3, in Building and operating a pretty big storage system called S3

Checks are simple too, and they are what make a move safe. Don't delete anything on GCP until they pass.

Ask about Google's exit offer. Data leaving GCP normally costs money for every GB. Google offers free data transfer for customers who leave Google Cloud. You must apply first, and there are rules. Talk to your Google account team before the big copy starts.

A Simple Way to Decide

Storage decision flow: if it is files in buckets, use Amazon S3 and pick the class by how often data is read; if it is a disk for one machine, use EBS gp3 or io2; if many machines share a folder, use Amazon EFS, or FSx for NetApp ONTAP, Lustre or Windows; if it is backups, use AWS Backup

  1. Is it files in a bucket? Use S3. Pick the class by how often the files are read. If you don't know, use Intelligent-Tiering.
  2. Is it a disk for one machine? Use EBS gp3. Use io2 only for the busiest databases.
  3. Do many machines share one folder? Use EFS. Use FSx if you need Windows sharing, NetApp features or very heavy work.
  4. Is it a backup? Use AWS Backup. Keep a copy in a separate AWS account, so one mistake can't delete both.

What Changes on the Bill

Storage prices look simple: a price for each GB, each month. The surprises come from everything around that:

Cost GCP AWS
Keeping files Per GB per month, by class S3: per GB per month, by class
Reading and writing A fee per 1,000 actions A fee per 1,000 requests; higher for cold classes
Reading cold files A fee per GB A fee per GB, and a wait for Glacier
Deleting too early You pay the minimum time You pay the minimum time, and for at least 128 KB per file
Disks Per GB; speed comes with size EBS: per GB, plus extra speed if you want it
Shared folders Filestore: for the size you set aside EFS: for what you actually store
Data leaving the cloud Per GB Per GB

Three things catch teams out:

  • Lots of tiny files. Request fees and the 128 KB minimum add up fast. Bundle small files together, or keep them in S3 Standard.
  • Copying lifecycle rules as they are. A rule that moves files to a cold class is cheap on GCP. On AWS, moving millions of small files into Glacier costs a fee for each one.
  • NAT gateways. Machines in a private network often reach S3 through a NAT gateway, which charges for every GB. Add a free S3 gateway endpoint instead.

Turn on S3 Storage Lens early. It shows which buckets are growing, which files nobody reads, and where a lifecycle rule would save money.

What It Looks Like in Code

Uploading a file and making a one-hour download link, on GCP and on AWS:

# GCP: Cloud Storage (Python)
from datetime import timedelta
from google.cloud import storage

bucket = storage.Client().bucket("shop-invoices")
blob = bucket.blob("2026/10/inv-1042.pdf")
blob.upload_from_filename("inv-1042.pdf")
url = blob.generate_signed_url(expiration=timedelta(hours=1))

# AWS: Amazon S3 (Python)
import boto3

s3 = boto3.client("s3")
s3.upload_file("inv-1042.pdf", "shop-invoices", "2026/10/inv-1042.pdf")
url = s3.generate_presigned_url(
    "get_object",
    Params={"Bucket": "shop-invoices", "Key": "2026/10/inv-1042.pdf"},
    ExpiresIn=3600,
)
Enter fullscreen mode Exit fullscreen mode

And a bucket that keeps old versions and moves files to a cold class after 90 days, in Terraform:

# GCP: a Cloud Storage bucket
resource "google_storage_bucket" "invoices" {
  name                        = "shop-invoices"
  location                    = "US-CENTRAL1"
  uniform_bucket_level_access = true
  versioning { enabled = true }
  lifecycle_rule {
    condition { age = 90 }
    action {
      type          = "SetStorageClass"
      storage_class = "COLDLINE"
    }
  }
}

# AWS: the same bucket in S3 (each setting is its own resource)
resource "aws_s3_bucket" "invoices" {
  bucket = "shop-invoices"   # names are global; it may be taken
}

resource "aws_s3_bucket_versioning" "invoices" {
  bucket = aws_s3_bucket.invoices.id
  versioning_configuration { status = "Enabled" }
}

resource "aws_s3_bucket_lifecycle_configuration" "invoices" {
  bucket = aws_s3_bucket.invoices.id
  rule {
    id     = "cold-after-90-days"
    status = "Enabled"
    filter {}
    transition {
      days          = 90
      storage_class = "GLACIER_IR"   # was COLDLINE
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

These snippets show the shape, not every setting. Check the current docs before you copy them.

Things That Bite Later

"Failures are a given and everything will eventually fail over time."

— Werner Vogels, CTO of Amazon, in 10 Lessons from 10 Years of AWS

These are the small things that tend to break after the move:

  • Old file paths. Paths like gs://bucket/file and links to storage.googleapis.com hide in code, settings, scripts and database rows. Search for all of them, including links you have already sent to customers.
  • Bucket names. Bucket names must be unique across all of AWS. The name you used on GCP may already be taken. Choose names early.
  • File labels. Labels like Content-Type tell a browser what a file is. If they are not copied, a browser may download a picture instead of showing it.
  • Cold files that need a restore. Code that reads from Archive on GCP will fail on Glacier Deep Archive until the file is restored.
  • Sudden heavy traffic. S3 handles thousands of requests per second and grows over time. But a brand-new bucket hit hard on day one can slow down at first. Ramp up traffic step by step.
  • File change alerts. If apps react when a file is added, those alerts move to S3 Event Notifications. The alert looks different, so the code that reads it needs a small change.

Doing the Move, Step by Step

  1. List everything. Every bucket, disk, shared folder and backup, with its size, number of files, class, cost, owner and the apps that use it.
  2. Pick the AWS service and storage class for each one, using the questions above. Write down why.
  3. Set up the base: AWS accounts, networks, S3 gateway endpoints, encryption keys in AWS KMS, access rules and backup plans.
  4. Apply for Google's exit offer before the big copy starts.
  5. Start with one bucket. Copy it with DataSync, check it, and point one app at it.
  6. Move the rest in waves. For each wave: full copy, catch-up copies, a short freeze, a final copy, then checks.
  7. Clean up. Keep the GCP data read-only for a while, then delete it. Remove old keys and accounts. Review the AWS bill after the first full month.

Storage is the heaviest part of a cloud move, but it is also the most predictable. The services match closely. The work is in the details: cold classes, access rules, tiny files and a careful final copy. Get those right, and your data arrives whole.

Common Questions

How do I transfer data from GCS to S3?

Use AWS DataSync. It reads Google Cloud Storage directly with a GCP key, so bucket-to-bucket copies need nothing installed on GCP. It checks every file, copies only what changed on later runs, and writes a report. Run a full copy, catch-up copies, then a short freeze and a final copy.

Is Google Cloud Storage S3 compatible?

Partly. Cloud Storage has an S3-style XML API, which is why DataSync, rclone and many S3 tools can read GCS buckets directly. Your apps still need small changes once they move to real S3, such as signed URLs becoming pre-signed URLs.

Can I use rclone instead of DataSync for GCS to S3?

For small buckets, yes. For large moves, DataSync is safer: it checks every file, retries, runs incremental syncs and gives you a report you can show auditors.

What is the GCP Filestore equivalent in AWS?

Amazon EFS for most NFS shares. Use FSx for NetApp ONTAP for mixed Linux and Windows sharing or NetApp features, FSx for Lustre for heavy AI and HPC work, and FSx for Windows File Server for Windows apps.

Persistent Disk vs EBS: what is different?

On GCP a bigger disk is a faster disk. On EBS gp3 you set speed on its own: every disk starts at 3,000 IOPS and you pay for more. pd-balanced maps to gp3, pd-ssd to gp3 with more IOPS, and pd-extreme to io2. Regional Persistent Disk has no direct match.

Coldline vs Glacier: which S3 class replaces it?

Coldline and Archive map to S3 Glacier Instant Retrieval if apps still read the files. Use Glacier Deep Archive only for files nobody needs fast, because it needs a restore that can take hours.

How do I avoid GCP egress fees when moving to AWS?

Apply for Google's free data transfer for customers leaving Google Cloud before the big copy starts. Talk to your Google account team, since there are rules to follow.

About MigrateX

MigrateX

MigrateX is our platform and service for moving software, data and infrastructure from one technology to another. It combines automation with experienced engineers. The automation does the repetitive work quickly, and the engineers make the tricky decisions.

Here's how we run a GCP to AWS storage move with MigrateX:

  1. Assessment. We list every bucket, disk, shared folder and backup, with its size, file count, class, cost and owner. You see where the work is before anyone agrees on a timeline.
  2. Plan. We work with your team to pick the AWS service and storage class for each one, set up access and encryption, and plan the copy waves.
  3. Migration, step by step. Automation does the repetitive parts: setting up DataSync copies, turning lifecycle rules and bucket settings into their AWS versions, and updating gs:// paths and Terraform. Our engineers handle the parts that need thought: cold data, very large buckets, shared folders and the final switch.
  4. Proof that it works. Every wave ends with checks on file counts, sizes and checksums. Apps are tested against the new storage before the switch.
  5. Handover and clean-up. We retire GCP storage one wave at a time, tune storage classes once real usage is known, and leave your team with a setup they understand and own.

What you get along the way:

  • No lost data. Every file is checked after it is copied. Nothing is deleted until the checks pass.
  • Short freezes. Catch-up copies keep the final switch down to minutes or hours, not days.
  • A smaller bill, not a bigger one. The right storage classes, lifecycle rules and endpoints are part of the move, not an afterthought.
  • One team from start to end. The same people plan the move, copy the data and hand it over.

Planning a move from GCP to AWS? We'd love to hear about it. Tell us a little about your setup through Contact Us, and we'll start with a free chat about where the work is likely to be.

References

AWS

Expert sources

Google Cloud

CobuildX helps teams migrate legacy applications and cloud infrastructure with MigrateX.

Originally published on the CobuildX blog.

Top comments (0)