Amazon

Amazon is the company my entire career rests on, so I can’t write about it with any pretense of distance. I have been drinking the AWS Kool-Aid since 2006, I was an early adopter, and I built API Evangelist on the foundation that Amazon laid. More than any other company, Amazon proved that APIs were not a developer novelty but the operating system of a real business. Every major thread in the modern API story — infrastructure as a programmable resource, the internal service mandate, metered pay-as-you-go pricing, the API-first console — runs back through Amazon. And like everything that gets big enough, Amazon eventually became some of what it originally disrupted, which is part of the history too.

The origin of Amazon’s API story is older than AWS. Amazon launched e-commerce APIs in 2002 — third-party sites could search and display Amazon products via XML and SOAP, tied into the Affiliate Program so that integrators earned commission on what they sold. Tim O’Reilly called it a significant leap forward in the programmable internet, and he was right. But the e-commerce API was a preview. The thing that changed everything came in 2006.

In March 2006, Amazon launched S3 — simple storage as a RESTful web service, priced at fifteen cents per gigabyte per month. In August 2006, EC2 followed: resizable compute capacity in the cloud, with APIs at its core, billed by the hour. I wrote in my history-of-APIs work that these two launches marked a departure from everything before them. Storage and compute, the most fundamental primitives of computing, were now available as web APIs you could provision programmatically and pay for by usage. That was the beginning of the cloud computing era, and it was built entirely on APIs.

EC2 is also where the lightbulb went on for me personally. I wrote about this in 2016, a decade after the fact: the EC2 launch was the moment I understood that web APIs weren’t just for fun and games anymore. You could now do real-world business things with them — stand up infrastructure, run companies, build products — all through programmatic interfaces. That realization is the direct reason I launched API Evangelist in July 2010. My career exists because Amazon turned infrastructure into an API and made me understand what that meant.

The deepest lesson Amazon taught the API world wasn’t a product, though — it was an internal mandate. Around 2002, Jeff Bezos issued an order to the entire company, which became public years later through Steve Yegge’s accidental platform rant. The mandate, as I’ve quoted it many times: all teams will henceforth expose their data and functionality through service interfaces. Teams must communicate through these interfaces. No direct linking, no shared-memory model, no back-doors — service interfaces over the network, only. It doesn’t matter what technology they use. And the part everyone remembers: all service interfaces must be designed from the ground up to be externalizable. Anyone who doesn’t do this will be fired. Thank you; have a nice day.

I wrote about this in 2012 as the secret to Amazon’s success, and I still believe it’s the single most important organizational decision in API history. Think about what Bezos was actually asking. Every team had to decouple, define exactly what resources they had, and make them available through an API — not just to each other, but designed so they could eventually be exposed to the outside world. The discipline of treating every internal team as if it were an external developer forced Amazon to solve, internally, every hard problem that public APIs face: support, security, monitoring, QA, service discovery, testing. As Yegge put it, organizing into services taught teams not to trust each other in the same ways they weren’t supposed to trust external developers. By 2006, Amazon had spent four years building that internal discipline — and AWS was the result of externalizing it. They optimized their internal APIs, then turned them into a public platform we now call cloud computing.

That mandate is why I’ve argued that in an API-driven company, everyone is effectively an API evangelist. Amazon didn’t hire a department to do APIs. It made APIs the law of how the company communicated with itself, and the cultural shift followed from the architecture. The Bezos mandate is the thing I point at whenever someone asks why their API program isn’t working — usually the answer is that they treated APIs as a project instead of as the fundamental way the organization is structured.

Amazon’s API-first instinct showed up everywhere once you knew to look for it. The AWS console came after the API and the CLI, not before — the programmatic interface was the product, and the graphical interface was a layer built on top of it. AWS maintained a blog dedicated entirely to the command line. This ordering — API first, CLI second, console third — was the opposite of how most enterprise software had always been built, and it became a model for what API-first actually means in practice.

Amazon also wrote the playbook on API pricing. Metered, pay-as-you-go, usage-based billing — per second, per call, per gigabyte — was Amazon’s contribution to how we monetize digital resources. I dug into this in 2017, comparing AWS’s utility pricing to the tiered SaaS plans most API providers still used, and the comparison was not comforting. AWS Marketplace introduced sophisticated metering across many dimensions — users, hosts, data, bandwidth, requests, tiers, units — and effectively set into motion how the industry thinks about monetizing API resources. But I also noted the darker edge: utility-based pricing is a weapon at scale. The cloud giants can suffocate small startups with pricing strategies that smaller players can’t match, while the API consumers themselves increasingly become the product. The same pricing innovation that democratized infrastructure also concentrated power.

The AWS API Gateway launch in 2015 was the moment Amazon’s mandate came full circle and pointed back at the rest of us. I wrote a post titled with the punchline of the Bezos mandate — “anyone who does not do this will be fired” — because that’s what the API Gateway represented. In 2006 Amazon had led by example. In 2015, Bezos was effectively making the mandate to you, in your own business, by selling you the tooling to expose your own resources as APIs. The Gateway had genuinely powerful capabilities — Lambda integration, mapping templates, IAM, lifecycle stages, monitoring, SDK generation. It was real.

But this is also where my ambivalence about Amazon sharpened. I wrote in 2015 that AWS was selling the API solution the enterprise would buy, not necessarily the one it needed. The Gateway, and the serverless Lambda pattern bundled with it, abstracted away exactly the heavy lifting that organizations should be doing themselves to actually learn how APIs work. After twenty-five years of managing infrastructure, I was hyper-aware of lock-in — even the subtle moves that accumulate over time. My farm-to-table approach to deploying APIs kept me in tune with my own supply chain, so I could move off AWS and run anywhere. The danger I saw was that our increased reliance on AWS wasn’t moving us forward; it was slowly sucking us back into the kind of single-vendor dependence we had just escaped. When you rely entirely on one platform, you aren’t evolving — you’re stuck.

The inconsistency across AWS’s own APIs became another instructive lesson. By 2019 I was writing about how AWS, with its 200-plus services, was a patchwork of API design patterns — legacy XML-RPC in the old services like S3 and EC2, RESTful patterns in newer ones, even HAL hypermedia in the API Gateway. The old patterns were dominant and nearly impossible to change because so much depended on them. The lesson for everyone else was to establish API design governance early, before the patchwork sets, because Amazon — the most sophisticated API operator in the world — couldn’t retrofit consistency onto services that had already become foundational. Even Amazon should have published an API design guide the way Microsoft and Google did.

Amazon kept showing up at the frontier of where APIs were going. Mechanical Turk made human labor itself available through an API, raising questions about APIs and labor that connected to Uber and TaskRabbit. Alexa and the Skills Kit, which I explored in depth in 2017, pushed APIs into voice and conversational interfaces, with a hundred-million-dollar Alexa Fund to incentivize developers. EventBridge brought schema registries and event-driven patterns into the AWS fold. Each of these was Amazon doing what it had always done — taking a capability, wrapping it in an API, and letting the ecosystem build on it.

The honest conclusion of Amazon’s API history is a paradox I’ve never fully resolved. Amazon, more than anyone, showed us what APIs could be — the programmable infrastructure, the internal mandate, the API-first culture, the metered pricing, the entire shape of the cloud. And Amazon, more than anyone, demonstrated that when there’s enough scale and money on the table, everything eventually becomes a version of what we set out to disrupt. The company that taught me APIs were real, that built my career, is also the company whose gravitational pull I spend my energy warning people about. Both of those things are true. That’s what it means to write the history of the company that bet its entire platform on APIs and won.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Amazon

References

Guidance Details

Explore more

Discover APIs