Getting Started with AWS — Accounts · Regions · AZs

This is the book’s first chapter. From Chapter 2 onward, your hands actually move through the console and CLI, but in this chapter we first draw the map you need in your head before that — what an AWS account is, what Regions and Availability Zones (AZs) are, and where the difference between “global services” and “regional services” comes from.

This book starts in the console, switches to Terraform code from Part 4 onward, and ends with running a fullstack app on ECS Fargate (Part 6 Deploying a fullstack app on AWS). This chapter provides the map for that long flow. The first setup steps you should complete right after sign-up — Chapter 2 IAM · Chapter 3 cost management · Chapter 6 security basics — are also signposted at the end of this chapter.

The rise of the cloud and AWS #

In the past, to run a service a company had to buy or lease servers and install them in a data center. Configuring an operating system on top and deploying applications was the usual way. Even adding one more server wasn’t simple. You had to get a quote, place an order, receive the equipment by delivery, then finish installation, network configuration, and monitoring setup — so it took days at best, usually weeks.

The cloud changed this process. Now you can create the servers, databases, and networks you need with just a few clicks. You don’t have to manage physical equipment yourself, and you pay only for what you use. Where “preparing infrastructure” used to be a big project in itself, in the cloud era you can use infrastructure the instant you need it.

AWS (Amazon Web Services) is the first mover and de facto standard in this space. It started in 2006 with S3 and EC2, and now has more than 200 services inside one console. Azure (Microsoft) and GCP (Google) cover the same space, but AWS leads in market share and in the volume of material. Learn it once, and moving to another cloud becomes easier too.

This book pares down to just the toolbox you need to run a real backend on AWS. It doesn’t cover all 200 services. What matters more is how you pick the right tool for the job.

AWS account structure #

To start with AWS you need one AWS account. You 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 sign-up has one root user. The email you signed up with is that user.

The root user has every permission — billing, closing the account, creating other users, accessing every resource. As powerful as it is dangerous. AWS’s first recommendation is don’t do day-to-day work as the root user.

• As root, do only the post-sign-up setup, checking billing info, and closing the account.
• Do actual work with the IAM user you create in Chapter 2 IAM.
• Always put MFA on root (covered in Chapter 6 security basics).
• Don’t create access keys, and if you already have one, delete it immediately.

Account ID and ARN #

Each account gets a 12-digit numeric ID (e.g., 123456789012). This ID shows up often in places like IAM policies and ARNs (resource identifiers). 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 part is empty. ARNs show up endlessly in Terraform code and IAM policies from Part 4 on, so it’s enough to just get familiar with the shape.

Multi-account and AWS Organizations #

Once you get a bit larger, you don’t use just one account. A common split looks like this.

The tool that bundles these accounts to consolidate billing and apply policies in bulk is AWS Organizations. At first, a single account is plenty. You’ll naturally run into Organizations when you need a second account, and Chapter 29 security governance covers it in earnest alongside SCP and Control Tower.

Parts 1 ~ 4 of this book proceed on the assumption of a single account. Multi-account is treated in Part 5 as the story after operations scale up.

Region #

A Region is AWS’s unit of physical placement. There are clusters of data centers all over the world, and each cluster is one Region. Each Region gets a short code.

As of 2026 more than 36 Regions are in operation. You switch with 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 following criteria can give a different answer.

1. User location and latency — if your users are spread across Japan / Southeast Asia / the US, pick a nearby Region. For a global service you might instead resolve it with the Edge distribution of Chapter 14 CloudFront.
2. Regulations / data sovereignty — some Korean industries (finance, healthcare) have regulations requiring data to stay inside Korea, which effectively forces the Seoul Region. Europe’s GDPR has a similar influence.
3. Service availability — not every service is in every Region. New services / features usually launch first in us-east-1 and spread to other Regions.
4. Price — the same service is priced differently per Region. us-east-1 is generally the cheapest. For batch workloads where latency isn’t an issue, consider a cheaper Region.
5. New-service beta / new features — the inverse of #3: if you always want to try the latest features, it’s us-east-1.

Regions are isolated #

Regions are isolated from each other both physically and logically. An EC2 / S3 / RDS resource created in the Seoul Region isn’t visible in the Tokyo Region console. Cross-Region communication has to be set up explicitly (VPC peering, S3 cross-region replication, etc.). This isolation matters for the following reasons.

• If one Region has an outage, the others are fine (the basis of disaster-recovery design, covered in Chapter 30 disaster recovery & backup).
• The Region is included inside resource IDs and ARNs.
• When you ask in the console “why can’t I see my EC2?”, nine times out of ten you picked the wrong Region.

Availability Zone (AZ) #

Go one level deeper inside a Region and you find Availability Zones (AZs). A single Region has 3 ~ 6 AZs, and each AZ is a physically separated data center. They’re usually tens of km apart with independent power and network links.

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

The a/b/c/d in an AZ code is mapped differently per account. Your account’s ap-northeast-2a and someone else’s ap-northeast-2a may not be the same physical AZ. That’s because AWS shuffles them for load balancing. So when collaborating, you use another identifier called the AZ ID, like apne2-az1.

What Multi-AZ means #

If one AZ goes down, all of that AZ’s EC2 / RDS go down with it. Production systems should be designed Multi-AZ to survive a single-AZ failure.

                  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)

• An ALB automatically distributes across multiple AZs (Chapter 13 ALB / NLB and ACM).
• EC2 is deployed across multiple AZs with an ASG (Auto Scaling Group).
• Turn on RDS’s Multi-AZ option and a standby is created automatically in another AZ, failing over on an outage.

Multi-AZ costs money. For learning or side projects a single AZ is plenty. Turn it on only for services where production traffic actually flows.

Edge Locations and surrounding infrastructure #

Beyond Regions and AZs, AWS has more global-infrastructure points of presence.

In this book you’ll meet only Edge Locations again, in Chapter 14 CloudFront. The rest are rarely used in ordinary backend operations.

Global services vs regional services #

AWS services split into two kinds.

Global services #

Services that don’t take a Region — they show the same data no matter which Region’s console you view them from.

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 per Region. Most belong here.

• EC2 / RDS / VPC / Lambda / ECS / DynamoDB — visible and working only inside the Region you created them in.
• CloudWatch — metrics and logs are separate per Region (Chapter 7 CloudWatch intro).

S3 is the slightly confusing part. The bucket itself lives in one Region, but its name must be globally unique. So the S3 console looks global while the data is per-Region (Chapter 10 S3).

Touring the console and the first setup #

Items you’ll often see on the first login screen (the console home) after sign-up:

• Top search bar — jump straight by service 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.
• CloudShell icon — a terminal inside the browser (Chapter 5 CloudShell and IAM Identity Center).

Right after sign-up, go through the next three chapters in order. These are steps you must finish before starting actual work.

1. Chapter 2 IAM — create an IAM user for day-to-day work and stop working as root.
2. Chapter 3 cost management — set up billing alerts and free-tier limits to prevent first-invoice shock.
3. Chapter 6 security basics — put MFA on both root and the IAM user.

Common pitfalls #

• “Why can’t I see my resource?” — if an EC2 you clearly created isn’t visible in the console, 99% of the time it’s a Region-selection mistake. Check the top right.
• Root key exposure — if right after sign-up you create the root user’s access key and push it to GitHub with your code, within minutes a bot finds it and crypto mining is running. Don’t create root access keys, and don’t put any key in code / git / README / a messenger (Chapter 6 security basics).
• Sleeping resources in the wrong Region — it’s common to find an EC2 you thought was in Seoul actually sitting in Virginia, only discovered after a month’s bill has been charged. Periodically check every Region, or detect it early with the billing alerts in Chapter 3 cost management.
• Cross-Region data transfer cost — traffic within the same Region is usually free, but cross-Region or to-internet egress traffic is charged per GB.
• Single-AZ in production — even a small system, once it goes to production, should consider Multi-AZ. Make the cost-vs-availability trade-off explicit.

Exercises #

1. Write in one sentence where the main users of the service you want to build are located, and note which of the five criteria in §“How to pick a Region” weighs most heavily in your Region choice. When you write provider "aws" { region = ... } in Chapter 25 Terraform intro, this note becomes your first decision.
2. Without looking, write the three first-setup items you must finish right after sign-up (IAM user, billing alert, MFA). For each item, connect it in one sentence to which of this chapter’s “Common pitfalls” it prevents.
3. For the two ARNs arn:aws:s3:::my-bucket and arn:aws:ec2:ap-northeast-2:123456789012:instance/i-0abc, explain in one paragraph, grounded in §“Global services vs regional services,” why the region part is empty on one and filled on the other.

In short: AWS is the de facto cloud standard that turned infrastructure you used to buy or lease into something measured in minutes. The account’s root user is for setup and billing only while day-to-day work goes through an IAM user, and the account ID goes inside ARNs. Regions are 36-plus isolated physical units worldwide chosen by user location, regulations, service availability, and price, and using several AZs inside one region — Multi-AZ — is the basis of operations. Services split into global (IAM, S3 name, Route 53, CloudFront) and regional, and the most common mistakes are picking the wrong Region and exposing the root key.

Next chapter #

In the next Chapter 2 IAM, you break away from the root user and create an IAM user for day-to-day work. We sort out IAM’s four elements (users · groups · roles · policies) in one go, and cover least-privilege design patterns that hold up in operations.