AWS Basics #1: Account, Region, and Availability Zone

One layer above the infrastructure toolbox of Linux and Docker comes the question of where to run those tools — and the answer is the cloud. This series walks through AWS, the de facto standard of that space, from day one to running it in production.

It’s grouped into four series, 27 posts in total.

• AWS Basics, 7 posts ← this series
• AWS Intermediate, 7 posts — EC2 / VPC / S3 / RDS / Route 53 / ALB / CloudFront
• AWS Advanced, 7 posts — ECS / ECR / Lambda / API Gateway / EventBridge / Secrets Manager / Step Functions
• AWS in Practice, 6 posts — running a real backend on ECS Fargate

This post is the starting point of the series. The map you need before opening the console — what an account is, what regions and AZs are, and where the line between “global services” and “regional services” actually comes from.

Where the cloud and AWS sit #

In the old days a company bought or leased servers, racked them in a data center, installed an OS, and put the application on top. Adding one more box meant quote → purchase order → shipping → install → network → monitoring setup — at best a few days, usually a few weeks.

The cloud compresses that flow into minutes.

AWS (Amazon Web Services) was the first mover and the standard of that flow. It launched in 2006 with S3 and EC2 and now offers more than 200 services under one console. Azure (Microsoft) and GCP (Google) compete in the same market, but AWS leads on market share and the volume of public material. Once you’ve learned it, moving to another cloud is easy.

This series only picks the toolbox you need to run a small backend on AWS. It does not cover all 200 services. What matters more is how to pick the right tool for the job.

The shape of an AWS account #

You need one AWS account to start. Sign up with an email, a payment method (usually a credit card), and a phone number.

The root user #

The account you receive right after signup has one root user. The signup email is that user.

The root user holds every permission — billing, account closure, creating other users, accessing every resource. As powerful as it is, it’s dangerous. AWS’s first piece of advice is: don’t use the root user for daily work. Keep this in mind:

• Use root only for the post-signup setup, billing checks, and account closure
• Real work runs through the IAM user you’ll create in #2 IAM
• Root must have MFA (covered in #6)
• Don’t create access keys for root, and if there’s an existing one, delete it immediately

Account ID #

Every account has a 12-digit numeric ID (e.g., 123456789012). It shows up everywhere — IAM policies, ARNs (resource identifiers), and so on. You can find it in the user menu at the top right of the console.

arn:aws:s3:::my-bucket/path/to/object
arn:aws:iam::123456789012:role/MyRole
arn:aws:lambda:ap-northeast-2:123456789012:function:my-fn

The form is arn:aws:<service>:<region>:<account-id>:<resource>. For global services (S3, IAM, etc.) the region slot is empty.

Multi-account and AWS Organizations #

Once the scope grows a little, you don’t run on a single account. A typical split:

The tool that bundles these accounts and applies billing and policies in bulk is AWS Organizations. Starting with a single account is fine. You’ll meet Organizations naturally when you need a second account.

This series proceeds with a single-account assumption. Organizations is a story for after operations have grown.

Region #

A Region is the unit of AWS’s physical location. Around the world there are clusters of data centers, and each cluster is one region.

Each region carries a short code. The ones you’ll see most often:

As of 2026, more than 33 regions are running. You can switch via the region selector at the top right of the console.

How to pick a region #

If most of your users are in Korea, Seoul (ap-northeast-2) is the first candidate. But the answer can change for these reasons:

1) User location and latency. If users are distributed across Japan / SE Asia / the US, pick a closer region. For genuinely global services, you can also distribute via CloudFront (edge distribution).

2) Regulation and data sovereignty. Some Korean industries (finance, healthcare) are required to keep data inside Korea, which forces the Seoul region. Europe’s GDPR has similar effects.

3) Service availability. Not every service is in every region. New services and features usually launch in us-east-1 first and roll out to other regions later. Check the AWS Regional Services List before choosing.

4) Price. Pricing varies by region for the same service. us-east-1 is generally cheapest. For batch workloads where latency doesn’t matter, consider a cheaper region.

5) New service betas / features. The flip side of 3) — if you always want to try the newest features, us-east-1.

Regions are isolated #

Regions are physically and logically isolated from each other. EC2 / S3 / RDS you create in Seoul won’t show up in the Tokyo console. Cross-region traffic must be set up explicitly (VPC peering, S3 cross-region replication, and so on).

Why this matters:

• An outage in one region doesn’t take down another (the foundation of disaster recovery)
• Resource IDs / ARNs encode the region
• “Why can’t I see my EC2?” in the IAM console → nine times out of ten it’s the wrong region

Availability Zone (AZ) #

Step one level inside a region and you find Availability Zones (AZs). A region has three to six AZs. Each AZ is a physically separate data center — usually tens of kilometers apart, with independent power and networking.

The AZs in the Seoul region (ap-northeast-2):

ap-northeast-2a
ap-northeast-2b
ap-northeast-2c
ap-northeast-2d

The a/b/c/d letters in AZ codes are mapped differently per account. Your ap-northeast-2a may not be the same physical AZ as someone else’s ap-northeast-2a. AWS shuffles the mapping for load balancing. So when collaborating, you also use AZ IDs like apne2-az1. You can check them on the EC2 → Availability Zones page.

What Multi-AZ means #

If one AZ goes down, every EC2 / RDS in that AZ goes down with it. Production systems need to be designed Multi-AZ to survive a single AZ failure.

The typical pattern:

                  Route 53
                     │
                     ▼
              Application Load Balancer
                  ╱        ╲
                 ╱          ╲
        ┌───────▼──┐    ┌──▼──────┐
        │   AZ a   │    │   AZ b  │
        │  EC2 #1  │    │ EC2 #2  │
        │  EC2 #2  │    │ EC2 #3  │
        └─────┬────┘    └────┬────┘
              ╲              ╱
               ╲            ╱
                ▼          ▼
            RDS Primary  RDS Standby
              (AZ a)       (AZ b)

• ALB automatically distributes across AZs (covered in Intermediate #6)
• EC2 is deployed across AZs via an ASG (Auto Scaling Group)
• Turning on RDS Multi-AZ creates a standby in another AZ and fails over automatically on outage

Multi-AZ costs money. A single AZ is fine for learning and side projects. Turn it on only where real production traffic is flowing.

Edge locations and friends #

Beyond regions and AZs, AWS has more physical sites.

In this series we only meet Edge Locations again, in Intermediate #7 CloudFront. The rest barely show up in typical backend operations.

Global vs regional services #

AWS’s 200+ services split into two kinds.

Global services #

Services that don’t pick a region — the console shows the same data no matter which region you look at.

When you open a global service in the console, the region selector at the top right automatically switches to “Global”.

Regional services #

Services that live separately in each region. Most things fall here.

• EC2 / RDS / VPC / Lambda / ECS / DynamoDB — visible and runnable only in the region they were created
• CloudWatch — metrics and logs are per region (a global dashboard is a separate construct)

S3 is slightly confusing. The bucket itself lives in one region, but the name is globally unique. So the S3 console looks global while the data is regional.

Getting started — a console tour #

Items you’ll touch a lot on the console home after signing in:

• Top search bar — jump straight to a service by name (e.g., EC2, S3)
• Top region selector — always be aware of it. Working in the wrong region is the most common mistake
• Top-right user menu — account ID, billing info, security credentials
• Favorites (the star icon) — pin the services you use a lot
• CloudShell icon — a terminal inside the browser (#5)

First-setup checklist #

Right after signup, walk through the next posts in order.

1. #2 IAM — create the IAM user for daily work. Stop using root.
2. #3 Cost management — set billing alerts and a Free Tier ceiling. Avoid first-bill shock.
3. #6 Security basics — MFA on root and the IAM user.

These three must finish before any real work starts.

Common pitfalls #

1) “Why can’t I see my resource?” #

You created an EC2 in the console but it’s nowhere to be seen. 99% of the time it’s wrong region. Check the top right.

2) Root key leak #

Right after signup someone says “let’s try the API,” creates a root access key, and pushes the code to GitHub — within minutes a bot finds it and starts crypto mining. The next day’s bill is in the tens of thousands of dollars.

Never do this:

• Create root access keys
• Put access keys in code or git
• Paste access keys into READMEs, Slack, or email

#6 covers this in detail.

3) Stale resources in a wrong region #

You think the EC2 you created is in Seoul but it’s actually in N. Virginia. You only notice it when it shows up on the bill — a month’s worth of costs has already accumulated. Audit resources across all regions periodically (or catch it early via the billing alerts in #3).

4) Cross-region data transfer cost #

Traffic inside the same region is usually free, but cross-region or internet egress is billed per GB. In multi-region designs this cost is unexpectedly large.

5) Single-AZ in production #

Even small systems should consider Multi-AZ once they go to production. One EC2 + single-AZ RDS → an AZ outage takes everything down. Make the cost / availability trade-off explicit.

Wrap-up #

What we covered:

• Where the cloud and AWS sit — the infrastructure you used to buy or lease shifts to minutes. AWS is the standard of that space
• Account — root only for setup and billing, daily work via IAM (#2)
• Account ID is embedded in ARNs. Multi-account is Organizations
• Region — 33+ regions worldwide. Pick by user location / regulation / service availability / price / new features
• AZ — the data center unit inside a region. Multi-AZ is the operational baseline
• Edge Location is the site CloudFront uses (Intermediate #7)
• Global vs regional services — only IAM / S3 (name) / Route 53 / CloudFront are global
• Pitfalls — wrong region, root key leak, stale resources in another region, egress cost, single AZ

Next — IAM #

The console tour is done. Now it’s time to step away from root and create an IAM user for daily work.

#2 IAM — Users, Groups, Roles, Policies threads IAM’s four elements (users / groups / roles / policies) onto a single line and lays out permission patterns that hold up in production.