What is AWS and why it became the name of the cloud
Published on 2026-09-12 by frfrand
De un experimento interno de una tienda de libros a la infraestructura de medio internet. Qué vende realmente, por qué su factura sorprende, y cuándo conviene y cuándo no.
In 2006 an online bookstore started renting out capacity from its servers. Today that division supports an enormous part of the internet and is one of the most profitable parts of its company.
The story matters because it explains what AWS actually sells.
The product was never the server
Before the cloud, getting a server was a project: choose the hardware, wait weeks for it to arrive, install it in a data center, configure it. If you got the sizing wrong, that mistake lasted years, because the hardware was already bought.
What AWS sold was time: a machine in one minute, paid by the hour, and destroyed when no longer needed.
That turned an architecture decision into a reversible decision. And when a decision is reversible, you can test it.
What is really inside
There are hundreds of services and most you will never use. The ones that support almost everything:
EC2 are virtual machines. It is the original service and the most similar to a VPS.
S3 is object storage: files accessible via HTTP, with very high durability. It is probably the most copied service in recent history: almost all providers have one compatible with its interface.
RDS are managed databases. You use Postgres or MySQL; they take care of backups, replicas, and updates.
Lambda runs functions without you managing servers, and charges per execution.
And around, a huge amount of specialized services: queues, notifications, containers, machine learning, distribution networks.
Why the bill surprises
This is the most common complaint and it's worth understanding where it comes from.
You pay for what you forget to turn off. Since creating resources is easy, test machines, orphaned disks, and unused reserved addresses remain, each one adding up.
Outbound traffic is charged. Bringing data in is free, taking it out is not. For an application that serves many files, that can exceed the compute cost.
Each service has its own pricing model, and composing ten services means understanding ten models.
The practical consequence is that the cloud is cheap when the load is variable (you pay for peaks only when they occur) and expensive when it is constant and predictable. Several well-known companies moved back to their own servers for exactly that reason.
When it makes sense and when it doesn't
It makes sense when the load varies a lot, when you need presence in several regions of the world, when you want managed services so you don't have to operate databases or queues, or when a compliance requirement asks for certifications they already have.
It's not worth it when your load is stable and predictable (a self-hosted server can cost a fraction), when the team is small and operational complexity weighs more than flexibility, or when what you need is a server and you're paying for a catalog of two hundred services you don't use.
The most underestimated point
Vendor lock-in. Not out of malice: out of gravity.
When your application uses five proprietary services, moving means rewriting parts. And the exit cost grows over time, silently.
There is a healthy way to live with that: use standard services (a machine, a Postgres, compatible storage) and be deliberate with each proprietary service you add. Each one is a decision that is costly to undo.
It's the same reason it makes sense to ask yourself, before choosing a provider, how easy it would be to leave.