如何將儲存服務從 GCP 遷移至 AWS：Cloud Storage、磁碟與檔案共享

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.

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.

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:

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.

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

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

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:

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,
)

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
    }
  }
}

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 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

• AWS. What is Amazon S3? https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html
• AWS. Understanding and managing Amazon S3 storage classes. https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html
• AWS. S3 Intelligent-Tiering. https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html
• AWS. Restoring an archived object. https://docs.aws.amazon.com/AmazonS3/latest/userguide/restoring-objects.html
• AWS. Managing the lifecycle of objects. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html
• AWS. Replicating objects. https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html
• AWS. S3 Object Lock. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
• AWS. Using server-side encryption with AWS KMS keys. https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html
• AWS. Amazon S3 Event Notifications. https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.html
• AWS. Blocking public access to your Amazon S3 storage. https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
• AWS. Sharing objects with presigned URLs. https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html
• AWS. Optimizing Amazon S3 performance. https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html
• AWS. Amazon S3 Storage Lens. https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens.html
• AWS. Gateway endpoints for Amazon S3. https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html
• AWS. What is Amazon EBS? https://docs.aws.amazon.com/ebs/latest/userguide/what-is-ebs.html
• AWS. General Purpose SSD volumes. https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html
• AWS. What is Amazon EFS? https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html
• AWS. What is Amazon FSx for NetApp ONTAP? https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html
• AWS. What is Amazon FSx for Lustre? https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html
• AWS. What is Amazon FSx for Windows File Server? https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html
• AWS. What is AWS Backup? https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html
• AWS. AWS Key Management Service. https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
• AWS. What is AWS Application Migration Service? https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html
• AWS. Configuring AWS DataSync transfers with Google Cloud Storage. https://docs.aws.amazon.com/datasync/latest/userguide/tutorial_transfer-google-cloud-storage.html
• AWS. AWS Snowball Edge availability change. https://docs.aws.amazon.com/snowball/latest/developer-guide/snowball-edge-availability-change.html

Expert sources

• Andy Warfield. Building and operating a pretty big storage system called S3. All Things Distributed, 2023. https://www.allthingsdistributed.com/2023/07/building-and-operating-a-pretty-big-storage-system.html
• Werner Vogels. 10 Lessons from 10 Years of Amazon Web Services. All Things Distributed, 2016. https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html

Google Cloud

• Google Cloud. Storage classes. https://cloud.google.com/storage/docs/storage-classes
• Google Cloud. Cloud Storage interoperability. https://cloud.google.com/storage/docs/interoperability
• Google Cloud. Exit Google Cloud. https://cloud.google.com/exit-cloud

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

Originally published on the CobuildX blog.