20 Years of Amazon S3: The Golden Cage of the Cloud Era
On March 14, 2006, Amazon S3 launched with two operations. Today, the service stores 500 trillion objects and is the industry standard – controlled by AWS.
(Image: heise medien)
Amazon S3 solved a real problem in 2006. Storage procurement was expensive, slow, and risky: ordering hardware, configuring RAID, planning capacities, designing backup strategies – all months before the first application went live. S3 reduced that to an HTTP request. PUT, GET, done. No high capital outlay, no advance planning, pay-as-you-go billing.
This simplified the start for young companies and was a welcome way for corporations to convert capital expenditures into operating expenses. But it was also a trade-off: control for convenience. And as with most trade-offs in the tech industry, many only realized late what they had given up.
The numbers impress – and obscure
AWS proudly presents key figures for its anniversary, which are undoubtedly impressive: over 200 million requests per second, hundreds of exabytes of data, 123 Availability Zones, 39 regions. The maximum object size has grown from 5 GByte to 50 TByte, the price per gigabyte has fallen from 15 to a good 2 US cents – a decrease of 85 percent.
What AWS doesn't mention: Hardware costs per gigabyte have decreased by well over 85 percent in the same period. The price reductions therefore largely reflect the general cost development for storage media, but not generous margin sacrifices. According to analyst reports, AWS as a whole operates with profit margins of over 30 percent – which is likely to apply to S3 as well.
The claim that customers have collectively saved well over 6 billion US dollars through S3 Intelligent-Tiering also deserves a second look. Saved compared to what? Compared to their own S3 standard tariff, AWS means. That's like a car manufacturer advertising that customers save money when they buy the cheaper model. The actual question – whether the same workloads would have run cheaper with alternative infrastructure or with regional cloud providers – remains unanswered.
The API standard that only AWS controls
Perhaps the most far-reaching impact of S3, however, is standardization. The S3 API has established itself as the lingua franca for object storage. MinIO, Ceph, Cloudflare R2, Wasabi, Backblaze B2 – they all implement S3-compatible interfaces for object storage. At first glance, this looks like an open ecosystem. On second glance, it's the opposite.
Because the S3 API is not an open standard. There is no standardization body, no RFC, no governance model. AWS defines the specification, AWS extends it, AWS decides which features are added. Compatible providers are structurally lagging behind – they can replicate the core API, but cannot replicate proprietary extensions like S3 Tables, S3 Vectors, S3 Metadata, Object Lambda, or Event Notifications in their full integration.
The result is a standard that suggests portability but does not fully deliver it. Simple PUT/GET workloads can indeed be migrated well. But anyone who processes S3 events in Lambda functions, combines lifecycle policies with Glacier tiering, and controls access via IAM policies doesn't have a storage problem – they have a platform problem. And that is precisely the intention.
Egress: The invisible wall
Hardly any topic is complained about more and acted upon less in cloud economics than egress fees. AWS still charges fees for data transfer out of S3 that are not in any comprehensible proportion to the actual transit costs. While AWS has selectively lowered prices and has offered free egress for provider switching since 2024 – but only once and only for complete withdrawal.
For companies with hundreds of terabytes or petabytes in S3, the calculation is quick: The transfer costs alone for a migration can reach six figures – before the first byte is on the new platform. This is not a bug, it's a business model. Data flows in cheaply – and out expensively.
Videos by heise
The platform bet: S3 as a data monopoly
The latest extensions make the strategic direction unmistakable. S3 Tables brings managed Apache Iceberg tables directly into the storage service. S3 Vectors provides native vector storage for RAG applications – according to AWS, over 250,000 indices have been created and more than one billion queries have been executed in just four months. S3 Metadata eliminates the need to list buckets recursively.
The message is clear: data should be stored in S3, queried in S3, analyzed in S3, and provided from S3 for AI models. Without copies, without intermediate systems, without detours – and without reason to leave the AWS platform. What AWS sells as simplification is a vertical integration that systematically undermines competition at the analysis layer. Why should a company still evaluate a separate vector store when S3 Vectors is included at the S3 price?
Conclusion: Technically brilliant, strategically calculated
20 years of S3 are a technical success story that is hard to fault. The service has democratized storage for start-ups, made an API an industry standard, and proven that backward compatibility can work even over two decades. The durability guarantees are real, the scaling is unprecedented, the engineering is first-class.
But the success story has a flip side that AWS understandably doesn't talk about. S3 is not just a storage service – it's an economic gravitational field that attracts data and doesn't let go. The open API standard is not one. The price reductions follow the hardware curve, not generosity. And every new function – Tables, Vectors, Metadata – makes the platform more useful and exiting pricier.
The IT industry has entered this dependency with open eyes over the past 20 years. Often, this was the rational decision – the alternative was own infrastructure with all the costs and significantly higher risks. But rational and without alternative are two different things. Anyone building their data and AI strategy on S3 today should at least know that they are not just booking a storage service. They are booking a relationship from which one cannot easily exit.
(fo)