AWS

Amazon Web Services is the platform that turned infrastructure into an API, and in doing so reset the entire industry’s expectations of what computing should be. Before AWS, infrastructure was something you bought, racked, and managed. After AWS, infrastructure was something you called — a request to an endpoint that returned a running server, a storage bucket, a queue, a database. I have been drinking the AWS Kool-Aid since 2006, was an early adopter, and built my career as the API Evangelist on the work Amazon did to make compute and storage programmable. The broader Amazon company story — the Bezos mandate, the e-commerce APIs, the paradox of becoming what it disrupted — lives elsewhere. This is the story of AWS specifically as the API-driven cloud.

The foundation was two services launched in 2006: S3 for storage and EC2 for compute. I reviewed the EC2 API in 2010 and described it exactly as what it was — virtualized servers on demand with pay-as-you-go pricing, available through both a RESTful API and a SOAP API, with SDKs across Java, PHP, Python, Ruby, and .NET. S3 was the same model for storage. What made these revolutionary wasn’t the virtualization underneath; it was that the interface to that virtualization was a web API. You could provision a server or a storage bucket with an HTTP request. The most fundamental primitives of computing — compute and storage — had become programmable resources you called rather than hardware you owned. That was the moment infrastructure became an API primitive, and everything AWS built afterward was an extension of that one idea: take a capability, wrap it in an API, meter it, and let people provision it on demand.

From those two primitives, AWS sprawled into one of the largest API surfaces in existence. By the time I sat down in 2017 to craft API definitions for sixty-six AWS services, I was mapping over two thousand API paths — and that was a fraction of what AWS would become on its way past two hundred services. Every service AWS launched came with an API, because the API was the product; the service was just what the API provisioned. Route 53 for DNS, CloudFront for CDN, DynamoDB for NoSQL, RDS for relational databases, SQS for queues, Lambda for functions — each one a programmable primitive, each one composable with the others. AWS reference architectures showed how these pieces snapped together into e-commerce checkout pipelines, recommendation engines, and complete applications. The composability was the point. AWS gave you a kit of API-accessible building blocks and let you assemble whatever you needed.

That sprawl came at a cost, and I documented it honestly: AWS API design consistency is a genuine problem. When you bounce from service to service across the AWS ecosystem, you can feel that consistency is a challenge for Amazon. The older services use the ?Action= query-based pattern and are documented similarly to each other. The newer services are often better designed individually but deviate from the older conventions and scatter their documentation all over the place. I noted in 2017 that this was actually getting worse with some of their newer projects, not better. Even the naming is inconsistent — some services are branded “Amazon,” some “AWS,” some carry no prefix at all, and while that might seem trivial inside the firewall, it matters enormously when the rest of the world is trying to work with your platform. AWS proved that you can be the most sophisticated API operator on earth and still not be able to retrofit consistency onto services that have already become load-bearing. That’s a lesson in establishing design governance before the patchwork sets.

One thing AWS got profoundly right was the ordering of its interfaces: API first, CLI second, console third. Most companies build the human-facing graphical interface first and bolt on programmatic access later. Amazon delivered the API and the CLI first, and the console came second. I pointed in 2016 to the fact that AWS maintained a blog dedicated entirely to the command line as a signal of how seriously they took the CLI as a first-class interface. AWS invested equally in the API and the CLI, treating both as primary ways to operate the platform, with the console as a convenience layer on top. This ordering is the practical definition of API-first, and AWS lived it more completely than almost anyone. If you wanted to court the enterprise, AWS demonstrated, a CLI alongside your API was not optional.

The 2015 launch of the AWS API Gateway was a pivotal moment, because it turned AWS from a provider of APIs into a provider of API management for everyone else’s APIs. The Gateway was a front door for applications to reach back-end services, with traffic management, authorization, monitoring, and version management, priced at $3.50 per million calls plus data transfer. Almost a decade after S3 and EC2 showed the world that web APIs were more than a hobby, AWS was now selling the tooling to expose your own resources the same way. I had real ambivalence about it. I wrote that AWS was selling the API solution the enterprise would buy, not necessarily the one it needed — that it was crafted to deliver what enterprises would purchase rather than to put them on a meaningful API journey. What I wanted was less gateway and more HTTP, hypermedia, and API literacy. It felt like a vendor journey. And yet, by 2018, the IAM integration and the serverless tie-in had pulled me in far enough that I was running about half my own API infrastructure on the AWS API Gateway, while staying clear-eyed that it was not as portable as Kong or Tyk.

The serverless pattern, anchored by Lambda, was AWS’s next reframing of infrastructure-as-API. The combination of DynamoDB for storage, Lambda for functions, and API Gateway for the API surface let you stand up a complete, automatically scaling API without managing a single server — clean, modular, and metered. AWS even published a serverless developer portal as a reference implementation, built on Lambda, with login, subscription, usage metrics, and AWS Marketplace billing wired in. Lambda also let AWS coin and own the serverless narrative; when Azure Functions arrived, I noted it was matching AWS’s serverless storytelling, because stories are how adoption actually spreads. AWS extended OpenAPI itself to serve this world, defining around twenty x-amazon-apigateway vendor extensions that told the story of what they wanted the Gateway to do — integration, request validation, authorization — all expressed as extensions to the API contract.

AWS’s pricing model was as influential as any of its technology, and I think more consequential than people credit. Pay-as-you-go, usage-based, metered billing — per call, per gigabyte, per message, per second — was AWS’s contribution to how digital resources get monetized. EC2 moved from per-hour to per-second billing. I wrote in 2017 about why AWS charged by usage while most other API providers still clung to monthly SaaS tiers, and my sympathy was entirely with the utility model: I just want to pay for the resources my business needs and nothing more. But I also named the darker dynamic. Usage-based pricing is a weapon at scale. The cloud giants can offer a competing service, drop the price to run smaller competitors off, and once the coast is clear raise it back up. The same pricing innovation that made infrastructure accessible to a solo developer also became a mechanism for suffocating startups. AWS Marketplace extended this into a model for selling APIs wholesale — deploying an API as a machine image inside the customer’s own AWS account rather than proxying calls, enabling white-label and private deployments and decomposing an API platform into small deployable units of value.

By the event-driven era, AWS was still defining the frontier. EventBridge brought a serverless event bus connecting applications, SaaS, and AWS services, with a schema registry that I saw real promise in — auto-generating JSON Schema and, ideally, AsyncAPI for the events flowing through it. I argued the schema registry should become the heartbeat of operations, a complete view of the digital bits moving around the enterprise, with discovery, diffing, code generation, traceability, auditing, and governance built in. That AWS was the one building it was unsurprising. AWS has consistently been where the next reframing of infrastructure-as-API shows up first.

The throughline, and the persistent tension, is lock-in. AWS is so good, so complete, and so tightly integrated that relying on it stops feeling like a choice. I’ve been candid that my own increasing reliance on AWS sometimes felt less like moving forward and more like being slowly sucked back into the single-vendor dependence we’d all just escaped. The convenience and the IAM integration and the serverless elegance are real; so is the portability you surrender to get them. That tension is the honest center of the AWS story. AWS turned infrastructure into programmable API primitives and in doing so created the modern cloud, the metered-billing model, the serverless pattern, and the API-first discipline the whole industry now takes for granted. It also became the gravitational center it warns you about. Both are true, and both are why AWS is the single most important platform in the history of infrastructure as an API.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

References

Guidance Details

Explore more

Discover APIs