When Marta created MercadoFresco's account in the previous lesson, we left one decision noted down without fully justifying it: the region will be eu-west-1. This lesson explains why, and to do that we have to open the bonnet and see how AWS is built inside.

Understanding the global infrastructure is not general knowledge: it is the foundation of high availability. MercadoFresco's server goes down on Fridays because it is one. The way to stop that from happening is to spread the application across physically separated facilities that do not fail at the same time. To design that spread you need to know what a region is, what an Availability Zone really is, which services are global and which are not, and what it costs to move data around.

1. The three layers of AWS infrastructure
2. Regions: what they are, how they are named and why they are isolated
3. Availability Zones: what an AZ really is
4. Why AZ letters are shuffled between accounts
5. The edge network: edge locations, PoPs and regional edge caches
6. Specialised infrastructure: Local Zones, Wavelength and Outposts
7. Global, regional and zonal services
8. How to choose a region: the five criteria
9. Multi-AZ design: what fails and what survives
10. Region decision for MercadoFresco
11. The cost of traffic between AZs and between regions

AWS infrastructure is organised into a three-level hierarchy. Internalise it, because almost everything else derives from it.

An AWS region is a geographic area of the world where AWS has built a group of data centres. Examples: Ireland, Frankfurt, Paris, Spain, North Virginia, Tokyo, São Paulo.

The identifiers follow a fixed pattern, and it is worth knowing how to read it because you will write them hundreds of times in the CLI and in templates:

European regions that matter to you as a professional based in Spain:

Watch out for us-east-1 (North Virginia): it is the oldest and largest region, where AWS launches almost every service, and where some global things necessarily live (such as the billing metric we saw in 01-02, or CloudFront certificates). Do not use it as your main region if your customers are in Europe.

This is the most important conceptual point: regions are independent of one another. That is not a marketing line, it is a design property with very concrete practical consequences:

• A resource created in eu-west-1 does not exist in eu-west-3. If you look for your instance in the wrong region, the console will tell you there is nothing there.
• Data does not leave a region unless you explicitly ask it to (cross-region replication, copying a snapshot, a transfer). This is the basis of GDPR compliance.
• A serious failure in one region does not propagate to the others. It is the largest unit of failure isolation that exists.
• Prices vary by region. The same server can cost 20 % more in São Paulo than it does in Ireland.
• Some new services are not available in every region.

Mental rule: think of each region as a complete, separate cloud that happens to share the console, the API and your account with the others.

An Availability Zone (AZ) is a group of one or more data centres inside a region, which has:

• Independent power supply: its own feed and its own generators.
• Independent cooling.
• Independent network connectivity.
• Real physical separation: they are kilometres apart from each other, far enough that a flood, a fire or a power cut cannot affect two at once, and close enough that the latency between them stays minimal.

That double condition —far for risk, close for latency— is the key to the entire design:

That the latency between AZs is 1-2 milliseconds is what makes it possible for an RDS database in Multi-AZ mode to write synchronously to two AZs at once: every transaction is committed in both before returning OK, and if one AZ disappears, not a single order is lost. At 40 ms this would be unworkable.

AZs are named by adding a letter to the region identifier: eu-west-1a, eu-west-1b, eu-west-1c.

There is a detail here that confuses a lot of people and is worth understanding properly.

eu-west-1a is not the same data centre for every AWS account. AWS assigns the letters randomly and independently for each account. MercadoFresco's eu-west-1a may physically be the same facility as another company's eu-west-1c.

Why? To spread the load. If the letters were fixed, most customers would pick "the a" out of habit and that zone would get congested while the others sat empty. Randomisation distributes usage evenly.

Practical consequences:

• Do not compare AZ letters between accounts. Telling a colleague at another company "deploy in 1a" means nothing at all.
• To identify the real physical zone there is the AZ ID, which is stable and global: euw1-az1, euw1-az2, euw1-az3. This identifier is the same for every account.

You can see the mapping for your own account with this command (the CLI is installed and configured in lesson 01-05; here we only show the result so that you recognise it):

Explained line by line:

• aws ec2 describe-availability-zones: the ec2 service, the operation that lists zones.
• --region eu-west-1: which region we are asking about.
• --query '...': a JMESPath filter that keeps only three fields and gives them names.
• --output table: readable table format instead of JSON.

Approximate output:

Notice: in this account, eu-west-1a corresponds physically to euw1-az2. In another account the mapping would be different.

Besides regions and AZs, AWS has a third layer that is far more numerous and spread out: the edge network.

The flow is a hierarchy of caches:

For MercadoFresco this has a direct effect: the product photos (thousands of images that barely change) can be served from the Madrid edge in a few milliseconds, without touching the origin in Ireland. That improves the customer experience and reduces both load and outbound cost.

The services that use this network are CloudFront (content delivery network), Route 53 (DNS), AWS Shield and AWS WAF (protection) and Global Accelerator. How CloudFront is configured is lesson 03-04; Route 53 is 03-05; Shield and WAF are 04-04 and 04-05. Here you only need to know that this layer exists and that it sits outside the regions.

Beyond the above, AWS offers three extensions that you probably will not use at first, but that are worth recognising by name.

MercadoFresco does not need any of the three. Its latency target (a web shop) is comfortably met with a European region plus CloudFront.

This is one of the points where beginners go wrong most often: not all AWS services have the same scope.

Cases worth clarifying because they cause confusion:

• Amazon S3: the bucket is regional and its data is automatically replicated across several AZs, but the bucket name is globally unique. Nobody else in the world can name their bucket the same as yours.
• Amazon RDS: an individual instance is zonal. In Multi-AZ mode there is a replica in another AZ, with automatic failover. The connection endpoint does not change on failover.
• AWS Lambda: you deploy the function into a region and AWS takes care of running it across several AZs. It is regional and you do not have to worry about redundancy.
• VPC: the VPC is regional, but each subnet belongs to a single AZ. This is the piece you will use to spread your servers out (lesson 03-01).

Practical rule: if the resource is zonal, it is your job to have another like it in another AZ.

Choosing a region is not a matter of taste. These are the five criteria, in their usual order of importance.

Every 1,000 km adds roughly 10 ms of round trip because of the speed of light in fibre, plus the delay of the network hops. Approximate references from Madrid:

For an online shop, the difference between 35 ms and 100 ms is perfectly noticeable: a page that makes 20 chained requests accumulates more than a second of extra delay.

MercadoFresco handles personal data of Spanish customers: name, address, phone, purchase history. The GDPR does not forbid taking data out of the EU, but it demands additional safeguards and documentation when it is transferred to third countries. The simplest way to comply without lawyers is not to take it out at all: choose a European Union region.

That rules out us-east-1 straight away and, in practice, eu-west-2 (London) too, which fell outside the EU after Brexit.

Not every region offers every service, nor every instance type. The oldest and largest regions (us-east-1, eu-west-1, eu-central-1) have the most complete catalogue; the more recent ones (such as eu-south-2) take services on progressively.

Before committing to a region, check on the AWS regional availability page that every service in your architecture is there. Discovering halfway through a project that a service is missing is very expensive.

The same resource costs a different amount depending on the region. Taking us-east-1 as index 100, the approximate orders of magnitude are:

The difference between European regions is a single-digit percentage: it is not worth sacrificing latency or compliance to save 5 %.

If your application depends on a system that is already somewhere else (an ERP, an external supplier, a legacy database), placing yourself nearby reduces latency and transfer cost. In MercadoFresco's case, the office server will disappear once the migration is finished, so this criterion carries no weight.

Now for the important part. What exactly happens when an AZ goes down, and how do you survive it?

If eu-west-1a suffers a power cut, MercadoFresco is 100 % down. It is exactly the same fragility as the office server, only in a nicer building. Plenty of people migrate to the cloud and stop here, without realising that they have not gained any availability.

Now let us simulate the complete loss of eu-west-1a:

The result: instead of a total outage of hours, MercadoFresco has a degradation of one or two minutes. That is the difference between losing Friday afternoon and not even noticing.

1. Size for N-1. If you need 4 servers to handle the peak and you split them 2 and 2, when one AZ goes down you are left with 2 and you do not make it. Split 3 and 3, or use auto scaling.
2. Do not put state on an instance's local disk. The product photos cannot live on an EC2's disk: if that instance disappears, they disappear. They go to S3 (lesson 02-03).
3. Test the failure. A multi-AZ architecture that has never been tested is a hypothesis. Deliberately switching off an instance and checking the service stays up is a healthy drill.

Spreading across two regions protects against the failure of an entire region, but it multiplies the complexity: data replication at tens of milliseconds, DNS with failover, transfer costs and twice the infrastructure. For MercadoFresco it is unnecessary today. The general rule in the industry is: multi-AZ from the very start, multi-region only when the business justifies it.

Marta compares the three realistic candidates against the five criteria:

Decision: eu-west-1 (Ireland), with this explicit reasoning:

• The 35-45 ms latency is perfectly acceptable for a web shop, and besides, most of the weight of the page (the product photos) will be served from the Madrid edge via CloudFront, so the perceived latency will be far lower than the latency to the origin.
• The complete catalogue removes the risk of finding halfway through the project that a service is missing, critical when the course works through eleven modules of different services.
• It is in the EU, so the GDPR is met with no international transfers.
• It is the region with the most documentation and examples, which matters a great deal in a team of three people with no AWS specialist.

Marta also notes down a future review: when eu-south-2 completes its catalogue, and if latency becomes a competitive factor, it will be reassessed. Documenting the decision and its review date is good architectural practice.

The price of moving data within AWS surprises many teams. These are the orders of magnitude you should keep in your head:

A concrete example for MercadoFresco: if the application servers in eu-west-1a query the database in eu-west-1b, every gigabyte of results crosses an AZ boundary and gets billed. With 500 GB a month of traffic between tiers, that would be about $10/month. Not dramatic, but:

• Design so that hot traffic stays inside the AZ wherever you can.
• Do not do it at the expense of availability. Paying $10 a month to survive the loss of a data centre is one of the best purchases MercadoFresco can make.

And one important warning: the cost between AZs must not push you into putting everything in a single AZ. That saving is exactly the one that will cost you Friday afternoon.

• Creating resources in the wrong region. It is the number one beginner mistake: you create an instance, close the browser, come back the next day with a different region selected and it "has disappeared". It has not disappeared: it is still billing in the other region. We will look at this in detail in lesson 01-04.
• Believing that "it is on AWS" implies high availability. A single EC2 instance in a single AZ has roughly the same availability as a well-maintained server in the office. Redundancy has to be designed.
• Assuming that eu-west-1a is the same in every account. Use the AZ ID (euw1-az1) when you need to talk about the physical zone, for example when sharing subnets between accounts.
• Choosing us-east-1 because "it is the one in all the tutorials". If your users and your data are in Europe, it is a bad choice on latency and on compliance.
• Splitting across two AZs but sizing only for the total. If losing one AZ leaves you below the capacity you need, your multi-AZ design only stops you going down completely, it does not keep you serving.
• Forgetting that there are zonal resources with no replica. An EBS volume lives in one AZ. Its snapshot, on the other hand, is stored in S3 and is regional: that is why snapshots are the way to move a disk from one AZ to another.
• Tip: document in writing the region you chose, the reasons and the review date. Changing region later is a full migration project, not a configuration tweak.
• Tip: when you design, always ask yourself "what happens if this AZ disappears right now?". If the answer is "the shop goes down", you have work to do.

Answer with your reasoning:

1. A colleague tells you: "I have deployed in eu-west-1a, deploy there too so we are together". You work in different AWS accounts. What do you tell them and what piece of data do you ask for?
2. Classify as global, regional or zonal: an IAM user, an S3 bucket, an EC2 instance, a Lambda function, an EBS volume, a CloudFront distribution, a subnet.
3. Why is it possible for a database to replicate synchronously between two AZs but not between two regions?

For each scenario, choose a region and justify it with at least three of the five criteria:

Scenario A. MercadoFresco decides to open a subsidiary in Mexico with exclusively Mexican customers and its own catalogue. Mexican customer data is not mixed with Spanish data.

Scenario B. Sara needs an environment in which to process historical sales reports overnight, with no interactive users, with already anonymised data and no personal data. Cost is the dominant criterion.

MercadoFresco deploys in eu-west-1 with this configuration:

• 2 EC2 shop instances: one in eu-west-1a, the other in eu-west-1b. Each one supports a maximum of 600 orders per hour.
• 1 RDS database in Multi-AZ mode, with the primary in eu-west-1a.
• The product photos in S3.
• An Application Load Balancer in front of the instances.
• The Friday peak is 900 orders per hour.

Answer:

1. What exactly happens if eu-west-1a goes down on a Tuesday at 10:00 (200 orders/hour)?
2. And if it goes down on a Friday at 19:00, in the middle of the peak?
3. Propose two concrete changes so that the Friday scenario does not degrade the service, and say which of the two you would prefer on cost grounds.

Solution 1

1. You tell them that AZ letters do not match between accounts: their eu-west-1a may be a different physical facility from yours. You ask them for the AZ ID (for example euw1-az2), which is stable and global, and you look up in your own account which letter corresponds to it with aws ec2 describe-availability-zones.

2. Resource	Scope
   IAM user	Global
   S3 bucket	Regional (with a globally unique name)
   EC2 instance	Zonal
   Lambda function	Regional
   EBS volume	Zonal
   CloudFront distribution	Global
   Subnet	Zonal

3. Because synchronous replication requires waiting for the destination to confirm before the transaction is considered good. Between AZs, that trip costs 1-2 ms, an acceptable overhead per operation. Between regions it costs 30-40 ms or more, which would cut write performance by an order of magnitude and make the application unworkable. That is why replication between regions is asynchronous, accepting a small window of possible data loss.

Solution 2

Scenario A: mx-central-1 (Mexico) or, failing that, us-east-1/us-west-2.

• Latency: a region in Mexico or in the southern United States is much closer to Mexican customers than any European region (which would be more than 150 ms away).
• Compliance and data residency: Mexican customer data stays in its own jurisdiction and, since it is not mixed with European data, no unnecessary international transfer is created.
• Service availability: you have to verify that the chosen region offers every service in the architecture; if pieces are missing, an established US region with good latency to Mexico is the reasonable alternative.
• Price: sa-east-1 (São Paulo) would be ruled out for being noticeably more expensive without offering any latency advantage over the North American options.

Scenario B: eu-north-1 (Stockholm).

• Price: it is habitually one of the cheapest regions in Europe, and cost is the dominant criterion in the brief.
• Latency: irrelevant, because this is an overnight batch process with no interactive users.
• Compliance: it is in the EU and, on top of that, the data is already anonymised, so the requirement is doubly comfortable.
• Service availability: you have to check that it offers the analytics services needed; if any were missing, eu-west-1 would be the alternative for very little difference in price.

One caveat: if that data has to be moved from eu-west-1, the cross-region transfer cost could cancel out the saving. It would have to be calculated before deciding.

Solution 3

1. Tuesday at 10:00 (200 orders/hour). The ALB detects that the 1a instance is not responding and stops sending it traffic within seconds. RDS fails the primary over to eu-west-1b in 1-2 minutes, with no data loss, and the connection endpoint does not change. The 1b instance can handle the 200 orders/hour (its limit is 600). The photos in S3 are unaffected. Impact for the customer: one or two minutes of errors on write operations, and then normal service.

2. Friday at 19:00 (900 orders/hour). The same 1-2 minute outage from the RDS failover, but after that you are left with a single instance with capacity for 600 orders/hour against a demand of 900. The system is saturated: queues, high response times and errors. Roughly a third of the orders are lost for the duration of the incident. The design avoids a total outage, but not severe degradation, because it is not sized for N-1.

3. Two possible changes:

   • Option A: three fixed instances (one in 1a, one in 1b and a third spread across), so that losing one AZ leaves 2 × 600 = 1,200 orders/hour of capacity, enough for the peak of 900. Cost: one more instance running 24/7 all month.
   • Option B: an auto scaling group spread across the two AZs, with a minimum of 2 instances and a maximum of 4, scaling on CPU or on request count. At the Friday peak there would be 3 or 4 instances; when an AZ goes down, the group launches replacements in the healthy AZ.

   Preferable: option B, on cost. You only pay for the extra capacity during the peak hours (a few a day) instead of keeping an additional instance up for all 730 hours of the month, and it also reacts automatically to unforeseen spikes. Its only drawback is the start-up time of the new instances, mitigated by a prepared image and by a sufficiently early scaling threshold. Auto scaling is covered in module 2 and load balancing in module 3.

You now know how AWS is built inside and, above all, why that structure matters for your own architecture. You have seen the three layers —regions, Availability Zones and the edge network—, the eu-west-1 naming convention, the isolation between regions that underpins GDPR compliance, and what an AZ really is: facilities with independent power, cooling and network, kilometres apart but joined by fibre at 1-2 ms, which is exactly what makes synchronous replication of databases possible.

You have learned to tell global, regional and zonal services apart —the key to knowing which redundancy AWS gives you for free and which you have to design yourself—, to reason about the choice of region with five criteria (latency, compliance, catalogue, price and proximity), and to estimate the cost of traffic between AZs and between regions. And MercadoFresco already has its decision taken and documented: eu-west-1, with the deployment spread across two Availability Zones.

In the next lesson, 01-04 "The AWS Management Console", we come down to ground level: we go through the console you will work with every day, we will learn not to fall into the region selector trap we have just mentioned, we will see how to tag and locate scattered resources with Tag Editor, and you will create your first real resource in MercadoFresco's account.