Storage in AWS versus GCP

AWS vs GCP Storage: What Actually Matters When You're Picking One

Cloud storage sounds like a solved problem until you're three hours into comparing pricing pages and realized somewhere around hour two that you've been reading the same egress fee footnote on a loop. Both AWS and GCP offer genuinely excellent infrastructure. They've also both managed to make a decision that should take an afternoon feel like preparing for a comprehensive exam.

So here's what actually separates them, where each one is the obvious call, and why some teams have quietly stopped deliberating entirely.

AWS Storage: The Everything Store

AWS didn't become the default cloud by accident. It has storage services for nearly every scenario imaginable, which is simultaneously its greatest strength and why the onboarding documentation runs to dozens of pages that don't always agree with each other.

S3 is still the benchmark. Its API became so dominant that "S3-compatible" is now just shorthand for "this works the way object storage should." Storage classes run from Standard through Intelligent-Tiering, which automatically shuffles objects based on access patterns, down to Glacier for archival. Glacier retrieval times range from milliseconds to hours depending on how much you're willing to pay, which sounds flexible until you're explaining to a product manager why accessing your own data has a tiered pricing model.

EBS handles block storage for EC2 instances. The gp3 volume type is the current workhorse: solid IOPS, reasonable cost, and you can tune performance independently of capacity, which is a genuine improvement over the older gp2 behavior. io2 exists for workloads that need high IOPS without compromise.

EFS gives you managed NFS that scales without provisioning. It's convenient. It's also not cheap, which surprises nobody who's ever opened a bill from it.

FSx covers a family of managed file systems: Windows File Server, Lustre for high-performance compute, NetApp ONTAP for enterprises that have existing NetApp workflows they're not ready to abandon, and OpenZFS for teams already invested in that environment.

Storage Gateway bridges on-premises infrastructure to S3. That sounds niche until you're the one migrating a company that still has a data center and a CTO who says "hybrid cloud" with a kind of reverence that discourages follow-up questions.

The pattern with AWS is breadth. There's a service for almost everything, and sometimes there are three services for the same thing with slightly different tradeoffs. The cost is that you'll spend real time figuring out which one is right, configuring it correctly, building a mental model of how the pricing interacts across all the moving parts, and wondering whether you've actually found the right service or just the first one that looked close enough. AWS doesn't make this easy. It makes it possible.

GCP Storage: Cleaner, But With Opinions

Google's storage lineup is more streamlined. Whether that reads as focused or limited depends on what you're building.

Google Cloud Storage is the object storage equivalent of S3, with four tiers (Standard, Nearline, Coldline, Archive) and strong consistency baked in from the start. That last part is less boring than it sounds. AWS didn't fully commit to strong read-after-write consistency for S3 until late 2020. GCS had it for years before that, which actually mattered for applications that couldn't tolerate the subtle weirdness of eventual consistency. The gap has closed, but GCS has the longer track record of just behaving correctly.

Persistent Disk is GCP's block storage equivalent. SSD and HDD options cover most use cases, Extreme PD handles latency-sensitive databases, and multi-attach works natively on some configurations in ways that AWS added to EBS later with more restrictions than GCP ever had.

Filestore covers managed NFS in Basic, Enterprise, and High Scale tiers. Less configurable than EFS in some respects, but more predictable in pricing at scale, which is a real thing to value rather than dismiss.

Google Cloud NetApp Volumes addresses enterprises with complex data management needs tied to NetApp workflows, because apparently escaping NetApp is harder than escaping a timeshare.

Where GCP has a genuine edge is analytics and ML tooling. If your storage strategy is inseparable from BigQuery, Vertex AI, or Dataflow, GCS sits inside that environment natively in a way AWS can only approximate with additional wiring. Google also runs its own private global fiber network, which affects transfer speeds and reliability in ways that are less theoretical when latency is actually part of your problem statement.

The Differences That Actually Matter

Consistency used to be a clear GCS win. It's close now. GCS still has the longer track record of not surprising you at inconvenient moments.

Egress pricing is where GCP has a real and sustained advantage. AWS egress costs have generated enough engineer complaints to constitute their own genre of blog post. GCP's pricing is more predictable and lower for inter-region and internet traffic. Both providers charge for egress. GCP just charges less and makes it easier to estimate before the bill arrives.

Archival pricing is where AWS's flexibility starts working against it. Glacier has more pricing variables than GCS Archive, which mostly charges per retrieval volume. Simpler models are easier to budget against, even when they're occasionally less optimizable.

Block storage comparisons are close enough that the averages don't tell you much. EBS gp3 and Persistent Disk SSD are competitive on IOPS and throughput at comparable price points. The edge cases matter more than the midpoints here, so benchmark against your actual workload before committing to either.

Security and compliance are both strong. AWS KMS and Google Cloud KMS are functionally similar for most teams. AWS has a wider range of compliance certifications, which matters specifically in regulated industries and very much not at all in others.

Developer experience favors AWS in tooling depth. More third-party integrations, more Stack Overflow answers, more institutional knowledge already sitting somewhere in your organization. GCP's console has improved significantly, but AWS has a decade's head start on community knowledge, and that compounds in ways that aren't obvious until someone on your team gets stuck at 11pm and starts searching.

The Pricing Traps

Neither platform's pricing page will tell you what you'll actually pay. Both require you to model your specific access patterns before committing to anything, and both seem to understand that most people won't.

On AWS, the surprises tend to come from egress fees, S3 request pricing under heavy read workloads, the quiet compounding costs of versioning and replication, and the way multiple services interact in ways you didn't initially sketch out. Versioning enabled across a large bucket means you're storing more data than you're consciously managing, and the bucket doesn't volunteer that information. S3 Storage Lens can help identify the waste, but it's a diagnostic tool for a problem that was already growing before you knew to look.

On GCP, the surprises are usually more specific. Nearline and Coldline both have minimum storage durations; retrieve an object before it hits that threshold and you pay for the full duration anyway. Filestore at scale can also outpace expectations if nobody's watching it closely.

The practical advice is the same for both: run your actual numbers, not the vendor's "typical workload" estimates, which describe a workload that exists primarily in the vendor's documentation.

Where Each One Is the Obvious Call

AWS is the obvious call when your organization is already deep in that environment, when your team has the expertise to navigate the service catalog without it becoming a project, or when you need compliance certifications that GCP hasn't prioritized. It's also the obvious call when you're building something that touches other AWS services heavily enough that moving storage elsewhere creates more complexity than it saves.

GCP earns serious consideration when your architecture is genuinely inseparable from BigQuery, Vertex AI, or Dataflow, and you'd rather have storage that sits natively inside that environment than one you're stitching into it. It's also worth looking at when egress predictability is a real variable in your architecture, not just a theoretical concern, and when you've compared the actual egress numbers on your current spend.

Neither is automatically wrong. The teams that get into trouble are usually the ones that defaulted to AWS because it's the default, then discovered three months later that their workload would have been cheaper and simpler on GCP, or vice versa. The decision isn't hard to make correctly; it's just easy to skip.