AWS building blocks, explained with LEGO
AWS builds services as small single-purpose blocks, not finished kits. Here is what that means, why AWS chose it, and how the blocks fit together safely.
Imagine two LEGO boxes. One holds a castle kit with a step-by-step manual. The other is a bin of loose bricks. The kit gives you a castle fast. The bin lets you build a castle, a spaceship, or something nobody has named yet, but you decide how every piece fits.
AWS chose the bin. In AWS terms, the bricks are called building blocks or primitives, and the 2023 shareholder letter from Amazon CEO Andy Jassy (published in April 2024) says AWS has more than 240 of them.
I read five sources to find out what this idea really means: that letter, a report on Werner Vogels' re:Invent 2024 talk, the AWS Well-Architected Framework, the Serverless Applications Lens, and an Amazon Builders' Library article about "constant work." This post explains them in plain words. It also answers one question that bothered me while reading: if more blocks make building harder, how does AWS deal with that?
What a building block is
Jassy's letter quotes AWS's 2003 vision document to define a primitive. In my own words, it is a part that
- is basic and cannot be split further
- does one thing very well
- gets combined with other parts in whatever way the builder wants
Vogels gave the reason for choosing blocks over finished kits. A finished framework can take years to build, and the world may change while you build it. Bricks can be handed out now.
The first bricks were Amazon S3 (March 2006), Amazon EC2 (August 2006), and SimpleDB (2007). The letter says the first few blocks can look random to customers until people see how they fit together. It uses the early confusion around S3 as an example.
The blocks, in school terms
Every comparison in this post (the table below, the locker, the buses, the elevator, the school bell) is mine, except the coffee urn, which comes from the Builders' Library article. AWS does not use them.
| Block | What it really does | School version |
|---|---|---|
| Amazon S3 | Stores files | A huge locker room |
| Amazon EC2 | Rents out virtual computers | A laptop you borrow when needed |
| AWS Lambda | Runs code when something happens | A part-timer who works only when called |
| Amazon SQS | Holds messages in a line | A reception desk with numbered tickets |
| Amazon SNS | Sends one message to many receivers | A class phone tree |
| Amazon EventBridge | Routes events to the right place | The person running the school announcements |
| AWS Step Functions | Runs several tasks in order | A supervisor holding the checklist |
| Amazon DynamoDB | Stores data in table form | A card catalog |
Each block does one job. S3 stores. SQS makes things wait in line. Nothing tries to do everything.
Why more bricks make building harder
A big bin gives you freedom, and freedom has a price.
Vogels himself said that when primitives multiply without being designed to fit together, they bring complexity. Jassy wrote that building primitives guarantees nothing, because there are many you could make and even more ways to combine them. His compass is to pick real customer problems, and he adds that the work takes patience.
So the builder inherits a job: deciding how to connect the blocks. AWS gives guidance for that job.
Rules for connecting blocks
The Well-Architected Framework collects questions and principles from years of reviewing customer designs. AWS describes a review as a conversation about design choices, not an audit.
Use a locker, not a handoff
One best practice is called REL04-BP02, "Implement loosely coupled dependencies." Loose coupling means blocks are tied together gently. Handing a note directly to a friend only works if the friend is at their desk. Dropping it in a locker works whenever the friend comes by.
The page says a block should only need to know the published, versioned interface of the block it depends on, so a change inside one block does not break the other. Where no instant reply is needed, blocks should talk asynchronously through something in the middle, such as Amazon SQS, Amazon Kinesis, AWS Step Functions, Amazon EventBridge, or Amazon SNS.
The page lists four patterns to avoid:
- running everything as one big program (a monolith)
- calling APIs directly between layers with no failover and no asynchronous option
- sharing one database, which ties parts together again
- ignoring back pressure, so a receiver that cannot keep up cannot slow the sender
AWS rates the risk of skipping this practice as High.
Many small buses instead of one big one
The reliability design principles say to replace one large resource with several small ones, so one failure hurts less. If one big bus breaks down, everyone is stuck. If one of five small buses breaks down, four still run.
Seven serverless principles
The Well-Architected Framework has add-on guides called lenses. The Serverless Applications Lens, published on July 14, 2022, lists seven principles. I group them by what they are about. The grouping is my reading.
Three are about building one block. Keep a function fast, small, and single-purpose. Carry nothing over, because the runtime is short-lived and local data is not guaranteed, so durable data goes to persistent storage. Do not depend on specific hardware, because the machines underneath can change.
Three are about connecting blocks. Run workflows with a state machine instead of chaining functions inside code, since chaining makes a tightly coupled monolith. Let events, such as a new file landing in S3, start the work. Expect failures and duplicates, so the same request arriving twice gives the same result. Pressing an elevator button twice still brings one elevator.
One is about sizing. Think in concurrent requests, not total requests, when you compare designs.
The lens also has six scenarios, such as RESTful microservices and mobile backends. I did not read them.
Making the block itself steady
The Amazon Builders' Library article "Reliability, constant work, and a good cup of coffee" covers the inside of a block. The joints are covered elsewhere. Its idea: a system that does the same amount of work no matter what is happening is hard to knock over.
Think of the school bell. It rings at the scheduled time whether the day is busy or quiet, and nobody has to decide to ring it. The article's own picture is a coffee urn that keeps brewing no matter how many people show up.
Amazon Route 53 health checks work this way. Checkers always send results of a fixed, maximum size. DNS servers receive a table of a known size every few seconds and keep it in memory. When answering a query, they check all possible answers whatever the health status is. If an Availability Zone loses power and thousands of checks fail at once, the amount of work does not change, so nothing slows down.
AWS Hyperplane nodes fetch a configuration file from S3 every few seconds and process it every time. The file is padded with dummy slots to its maximum size, so one changed load balancer and hundreds of changed ones cost the same.
If something corrupts, the next cycle fixes it with no special recovery code. Event-driven designs need extra machinery for state and backlogs.
How AWS handles the mess
Back to the opening question. AWS does not try to remove complexity. From what I read, it gathers the complexity at the joints and puts rules there. The three-layer split below is my own summary.
| Layer | What you do | Where I read it |
|---|---|---|
| Choose blocks | Pick small blocks that each do one job | S3, SQS, Lambda |
| Decide the joints | Couple loosely, use state machines, expect duplicates | REL04-BP02, Serverless Lens |
| Steady each block | Do the same work whatever the load | Constant work article |
Loose coupling stops damage at the joint. Constant work makes the inside of a block calm under changing load. They work on different layers, so they fit together.
What I could not check: the 2003 vision document itself (I relied on the letter), Vogels' talk firsthand (I relied on SiliconANGLE's report), and anything in the Serverless Lens added after 2022.
Sources
- Amazon CEO Andy Jassy's 2023 Letter to Shareholders
- AWS re:Invent 2024: Builder ethos embraces simplicity (SiliconANGLE)
- REL04-BP02 Implement loosely coupled dependencies
- Design principles, Reliability Pillar
- Serverless Applications Lens: Design principles
- Reliability, constant work, and a good cup of coffee
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article