Scaling concepts and services
Two architectural patterns underpin scaling on AWS: loosely coupled architecture, which lets parts of a system scale independently, and event-driven architecture, which is the asynchronous form of the same idea. Everything else on this page follows from them.
Loose coupling
Section titled “Loose coupling”A loosely coupled architecture is one where components work independently, knowing as little as possible about each other’s internals. What that buys:
- Layers of abstraction, so a change on one side of a boundary does not propagate across it.
- Freedom to add or modify functionality without a coordinated release.
- Interchangeable components — a replacement need only honour the same contract.
- Atomic functional units that can be reasoned about and tested on their own.
- Independent scaling, which is the property that matters here.
Why independent scaling is the point
Section titled “Why independent scaling is the point”Consider a three-step workflow with a 15-second budget:
- Step 1: 5 seconds
- Step 2: 20 seconds
- Step 3: 5 seconds
Thirty seconds total, twice the budget, and step 2 is the reason.
Scale the whole thing up. Give the machine more CPU and memory until step 2 finishes in 5 seconds. The workflow now meets its budget — and steps 1 and 3, which were never the problem, run on four times the hardware they need, all the time.
Decouple and scale the part that needs it. Put each step on its own compute, connected by messages. Step 2 runs four instances in parallel, each handling a quarter of the work, and finishes in 5 seconds. Steps 1 and 3 stay on the resources they always needed. The budget is met and nothing is over-provisioned.
The second design also degrades better: when step 2’s workload doubles, you add step 2 capacity rather than resizing everything.
Scaling up and scaling out
Section titled “Scaling up and scaling out”| Scaling up (vertical) | Scaling out (horizontal) | |
|---|---|---|
| Mechanism | Add CPU or RAM to an existing instance | Add more instances |
| Downtime | Requires a restart | None |
| Automation | Scripted; not built in for most services | Built into most AWS services |
| Ceiling | The largest instance type available | Effectively unbounded |
| Failure domain | One instance holds everything | Failure of one instance is a fraction of capacity |
Prefer scaling out. Scaling up is the right answer in a narrow set of cases — a database engine that cannot shard, a licensed product priced per node, a workload with a large in-memory working set — and in those cases it is worth knowing you have chosen it rather than defaulted to it.
Choosing what to scale on
Section titled “Choosing what to scale on”Two decisions, and the second is the one that goes wrong.
Service selection. Weigh cost, performance requirements and operational overhead together. The cheapest option that meets the requirement is rarely the one with the lowest unit price; it is usually the one with the least operational work attached.
Metric selection. The metric an Auto Scaling policy tracks must correlate with the thing users experience. CPU utilisation is the default and is frequently the wrong choice: an I/O-bound worker saturates its queue at 30% CPU, and a scaling policy watching CPU will never fire. Better candidates, depending on the workload:
- Requests per target, or target response time, for web tiers behind a load balancer.
- Backlog per instance — queue depth divided by instance count — for worker fleets.
- Concurrent executions or throttle counts for serverless components.
- A custom business metric where none of the infrastructure metrics track load faithfully.
Event-driven architecture
Section titled “Event-driven architecture”Event-driven architecture is loose coupling made asynchronous: event producers, an event router, and event consumers, none of which blocks on the others. It gives independent scaling per component, atomic units that fail in isolation, and support for workflows too complex to express as a call chain — Lambda functions communicating through EventBridge is the canonical shape.
It suits cloud environments precisely because the properties it provides — elasticity, flexibility and resilience — are the ones the platform charges for and the ones a fixed-capacity design cannot exploit.
See event-driven architecture on AWS for the services, the orchestration-versus-choreography distinction and a worked flow, and the integration pattern comparison matrix for the quotas that decide between the messaging services.