Decoding the Cloud.
This module explains how AWS's global infrastructure (Regions, Availability Zones, and edge locations) is organised, and introduces AWS services and their categories.
Module 3: AWS Global Infrastructure.
AWS organises its physical infrastructure in three layers, each solving a different problem.
The largest layer is the Region, a geographic area of the world where AWS operates clusters of data centres. Ireland, Frankfurt, and Tokyo are examples. Each Region stands completely on its own, and your data stays in the Region you chose unless you decide to move it. That choice has real consequences. A Region close to your users makes your application faster. Some countries require data to stay within their borders, and a Region lets you obey that rule. Prices also differ from one Region to another, so the choice affects cost too.
Inside every Region are several Availability Zones. Each is one or more data centres with its own power, cooling, and networking. They sit far enough apart that a fire, flood, or power cut in one should not touch the others, yet close enough to be joined by very fast connections. This design rests on an honest assumption: things will fail. Servers break and buildings lose power. An application that lives in a single Availability Zone goes down with it, while one spread across two or more keeps running, often without a single user noticing. I found this the most instructive idea in the module, because it shows that reliability is something you plan for. It does not come by luck.
The third layer is the edge location. There are far more of these than Regions, scattered through cities around the world. Their job is to keep copies of popular content, such as videos and web pages, close to the people who want it. Picture a book printed in only one city. Every reader on Earth would wait for it to be shipped from there. Now imagine copies in bookshops everywhere. That is what edge locations do for the internet. A student in Lagos opens a page and receives it from a nearby edge location instead of waiting for a server on another continent.
Put simply, Regions decide where your system lives, Availability Zones keep it standing, and edge locations make it fast.
On top of this infrastructure sits an enormous catalogue of services. AWS groups them into categories such as compute, storage, databases, networking, and security. At first the number of services looked overwhelming, but the categories make it manageable. You do not memorise everything. You identify the kind of problem you have and look in the right place. If you need somewhere to keep files, you look at storage. If you need somewhere to run a program, you look at compute. That is how professionals approach it too.
The largest layer is the Region, a geographic area of the world where AWS operates clusters of data centres. Ireland, Frankfurt, and Tokyo are examples. Each Region stands completely on its own, and your data stays in the Region you chose unless you decide to move it. That choice has real consequences. A Region close to your users makes your application faster. Some countries require data to stay within their borders, and a Region lets you obey that rule. Prices also differ from one Region to another, so the choice affects cost too.
Inside every Region are several Availability Zones. Each is one or more data centres with its own power, cooling, and networking. They sit far enough apart that a fire, flood, or power cut in one should not touch the others, yet close enough to be joined by very fast connections. This design rests on an honest assumption: things will fail. Servers break and buildings lose power. An application that lives in a single Availability Zone goes down with it, while one spread across two or more keeps running, often without a single user noticing. I found this the most instructive idea in the module, because it shows that reliability is something you plan for. It does not come by luck.
The third layer is the edge location. There are far more of these than Regions, scattered through cities around the world. Their job is to keep copies of popular content, such as videos and web pages, close to the people who want it. Picture a book printed in only one city. Every reader on Earth would wait for it to be shipped from there. Now imagine copies in bookshops everywhere. That is what edge locations do for the internet. A student in Lagos opens a page and receives it from a nearby edge location instead of waiting for a server on another continent.
Put simply, Regions decide where your system lives, Availability Zones keep it standing, and edge locations make it fast.
On top of this infrastructure sits an enormous catalogue of services. AWS groups them into categories such as compute, storage, databases, networking, and security. At first the number of services looked overwhelming, but the categories make it manageable. You do not memorise everything. You identify the kind of problem you have and look in the right place. If you need somewhere to keep files, you look at storage. If you need somewhere to run a program, you look at compute. That is how professionals approach it too.
IAM answers two separate questions. The first is who are you?, which is authentication. The second is what are you allowed to do?, which is authorization. A school gate is a good comparison. Showing your ID card to enter is authentication. The fact that students may use classrooms but not the exam office is authorization. IAM does both jobs for everything you build in AWS. It is also global, so it is not tied to a single Region, and it costs nothing to use.
Every AWS account begins with a root user, an identity with unlimited power over everything. Because of that power, it should be treated like a master key kept in a safe: protected by a strong password and multi-factor authentication, and not used for daily work. For everyday tasks you create IAM users, one for each person or application, so that every action can be traced back to someone. When many people need the same access, you place them in a group and give the permissions to the group once, instead of repeating the work for each member.
Then there are roles, which I found the most interesting. A role is a set of permissions that a user, an application, or an AWS service can take on temporarily. The credentials it provides expire on their own, which is much safer than leaving passwords scattered around. A server can be given a role to read from storage, for example, without anyone embedding a secret key in its code.
The permissions themselves are written in policies, documents that state what is allowed or denied and on which resources. One policy might permit reading files from a single storage bucket and nothing else. Two rules keep the system safe. Everything is denied by default, so access must be granted deliberately. And an explicit "deny" always overrides an "allow".
Every AWS account begins with a root user, an identity with unlimited power over everything. Because of that power, it should be treated like a master key kept in a safe: protected by a strong password and multi-factor authentication, and not used for daily work. For everyday tasks you create IAM users, one for each person or application, so that every action can be traced back to someone. When many people need the same access, you place them in a group and give the permissions to the group once, instead of repeating the work for each member.
Then there are roles, which I found the most interesting. A role is a set of permissions that a user, an application, or an AWS service can take on temporarily. The credentials it provides expire on their own, which is much safer than leaving passwords scattered around. A server can be given a role to read from storage, for example, without anyone embedding a secret key in its code.
The permissions themselves are written in policies, documents that state what is allowed or denied and on which resources. One policy might permit reading files from a single storage bucket and nothing else. Two rules keep the system safe. Everything is denied by default, so access must be granted deliberately. And an explicit "deny" always overrides an "allow".
Regions and Availability Zones teach us that things will fail, and that a good system is one that stands anyway. IAM teaches us that power without control is a danger, and that trust is built by deciding, with care, who may do what.
Anyone can make a system work. The harder task is to make it worth depending on.
Anyone can make a system work. The harder task is to make it worth depending on.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article