AWS architecture

This section covers how AWS workloads are put together — the decisions that are made once, early, and are expensive to revisit.

Best practices collects the positions we take by default on recurring questions: where instances belong on the network, how security groups and network ACLs differ and what that means for the rules you write, which controls should be account-wide defaults, and how to choose between compute and data-movement models.

High availability deals with surviving the failures that happen routinely — a failed instance, an impaired Availability Zone — across the compute, database and network tiers. It also defines the vocabulary the rest of the section depends on: RTO, RPO, and the difference between high availability and fault tolerance.

Disaster recovery deals with the rarer, larger events, and with choosing between the four AWS recovery strategies on the basis of what the business will actually commit to losing.

Scaling covers loose coupling, event-driven design, the three services confusingly all named “Auto Scaling”, and rightsizing what you ended up with.

Non-functional requirements is where the adjectives become numbers: current service quotas for the main integration mechanisms, and the availability arithmetic that a target like five nines actually implies.

Example architectures works through designs where these combine against a specific requirement.