Why AWS? Regions, Availability Zones, and IAM
AWS (Amazon Web Services) rents out compute, storage, networking, and dozens of higher-level services on demand, instead of buying and racking your own servers, you provision what you need in minutes and pay for what you use.
Regions and Availability Zones
AWS infrastructure is organized geographically:
| Concept | What it is |
|---|---|
| Region | A geographic area (e.g. us-east-1, eu-north-1), fully independent of other regions |
| Availability Zone (AZ) | One or more physically separate data centers within a region |
A region typically has 3+ AZs. Spreading resources across multiple AZs is the standard way to survive a single data center failure without any downtime, if one AZ has a power outage, your app keeps running in the others.
IAM: Identity and Access Management
IAM controls who (or what) can do what in your AWS account. Getting this right is one of the most important skills in AWS, misconfigured IAM is behind a huge share of real-world cloud security incidents.
- Users: an identity for a person, with long-lived credentials.
- Roles: a set of permissions that something can assume temporarily, EC2 instances, Lambda functions, and even users from another AWS account can assume a role instead of using long-lived credentials.
- Policies: JSON documents that actually define permissions, attached to users, roles, or groups.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}This policy allows reading objects from one specific S3 bucket, nothing else. This is the principle of least privilege: grant exactly the permissions something needs, and nothing more.
WARNING
Never use your AWS account's root user for everyday work, and never hardcode long-lived access keys into application code. Create an IAM user (or better, a role) with only the permissions a task actually needs.