We close Part I by bringing together everything we've learned about AWS geography—regions, availability zones, and edge locations—under three concepts that will guide many of your architecture decisions: latency, resilience, and data sovereignty. These are the three questions you'll ask yourself every time you design something in the cloud.

Latency is the time it takes for data to travel from one point to another and back. It is measured in milliseconds (ms). The lower the latency, the faster and smoother your application feels.

Latency depends heavily on physical distance: data travels fast, but not infinitely fast. Crossing an ocean always adds delay.

Example: A user in Madrid accessing a server in Madrid may have ~5 ms latency. The same user accessing a server in Tokyo may have ~250 ms. That difference is noticeable: the website "lags" with the distant option.

How to reduce latency with what you've learned:

• Choose a region close to your users (subchapter 3.1).
• Use CloudFront and edge locations to serve content from the nearest point (subchapter 3.3).

Fact: For services where every millisecond counts (online gaming, financial trading, video calls), latency is the design priority.

Resilience is your system's ability to keep working despite failures. As we've seen, in the cloud it's assumed that hardware will fail, so we design so that this doesn't bring down the service.

How to achieve resilience with what you've learned:

The key word here is redundancy: having spare copies or components distributed, so that the failure of one doesn't mean the failure of everything.

Real example: A payment gateway can never go down. They design it as multi-AZ to survive datacenter failures, and replicate data in a second region in case an entire region has a catastrophic problem. This way, they ensure payments keep working no matter what.

We'll see resilience in depth in Chapter 26 (high availability and disaster recovery), with concepts like RTO and RPO.

Data sovereignty refers to the laws and regulations that determine where certain data can be stored and processed, and which laws apply to them depending on the country where they are located.

It's not a technical issue, but a legal one, but it conditions technical decisions (which region you choose).

Real example — GDPR: The General Data Protection Regulation of the European Union regulates how the personal data of European citizens is handled. Many companies, to comply with it confidently, decide to store their European customers' data in AWS regions within the EU (Spain, Ireland, Frankfurt…).

Other examples of sovereignty requirements:

• Healthcare data that by law must remain in the country.
• Public administration data with localization requirements.
• Financial sectors with strict regulations on where data resides.

How you manage it with what you've learned: by choosing the appropriate region (subchapter 3.1). Since regions are isolated and you know exactly which country each one is in, you can guarantee that data doesn't leave where it should stay.

When designing any system in AWS, these three concepts translate into three questions:

1. Latency: Where are my users? → Choose a nearby region + CloudFront.
2. Resilience: What happens if a datacenter or region fails? → Multi-AZ and, if critical, multi-region.
3. Sovereignty: Are there laws about where my data must be? → Choose a region that complies with regulations.

Sometimes these three forces come into tension and you have to balance them:

Example of compromise: Your fastest users would be served from Virginia (low latency for America), but the law requires you to store European data in the EU (sovereignty). Typical solution: host the data in Europe (comply with the law) and use CloudFront to accelerate delivery globally (mitigate latency).

• Latency: response time; reduced by bringing the region closer and using edge locations/CloudFront.
• Resilience: ability to keep working despite failures; achieved with multi-AZ redundancy and, if critical, multi-region.
• Data sovereignty: legal requirements on where data resides; fulfilled by choosing the appropriate region.
• Almost every geographic architecture decision comes from balancing these three forces.

With this, you finish Part I. You now master the conceptual fundamentals of the cloud. In Part II we leave theory behind and get into practice: the essential AWS services, starting with compute using EC2.