Tổng quan & Hạ tầng toàn cầuOverview & Global Infrastructure

Part of the Cloud knowledge base — AWS deep dive. Complements DevOps Roadmap.

Overview

Amazon Web Services (AWS) is the largest cloud provider by market share, offering ~200 services spanning compute, storage, networking, databases, analytics, machine learning, and developer tooling. Launched in 2006 with S3 and EC2, AWS pioneered the pay-as-you-go infrastructure model and remains the reference implementation most other clouds are measured against.

This page is the map you keep open while learning the rest of AWS. It covers the pieces that sit underneath every service: the physical footprint (Regions, Availability Zones, edge locations), the account and organization model that isolates your workloads, the shared responsibility model that defines who secures what, the Well-Architected Framework that names the trade-offs, the ways you actually talk to the API (Console, CLI, SDK, CloudShell), and the pricing levers that decide your bill. Master these and every individual service — EC2, Lambda, RDS — becomes a variation on themes you already understand.

The single most important mental shift for AWS is that everything is an API call authorized by IAM, running in a Region, billed by usage. The console is just a website that makes those API calls for you. Once that clicks, the platform stops feeling like 200 unrelated products and starts feeling like one consistent system with a very large service catalog.

Why the global infrastructure matters before anything else

Where your resources physically live determines your latency, your data-residency compliance, your resilience story, and a surprisingly large share of your bill. A workload in us-east-1 behaves differently from the same workload in ap-southeast-1 — different price, different service availability, different failure blast radius. You cannot design a reliable or cost-effective system without first understanding the geography it runs on, which is why this is the first topic, not an afterthought.

Fundamentals

Regions, Availability Zones, and edge

AWS organizes its physical infrastructure into a strict hierarchy:

Key rules that flow from this hierarchy:

• A Region name is a prefix; AZ names append a letter — us-east-1a, us-east-1b, us-east-1c. Critically, AZ letters are randomized per account: your us-east-1a may be a different physical data center than another account’s us-east-1a. AWS scrambles them so customers don’t all pile into the “first” zone. Use AZ IDs (use1-az1) when you need a stable cross-account reference.
• AZs are the unit of resilience. Deploy across ≥2 AZs and a data-center failure is a non-event. This is the cheapest reliability you will ever buy — most AWS managed services (RDS Multi-AZ, ELB, EKS) are AZ-aware by default.
• Data transfer within an AZ is free; cross-AZ and cross-region traffic is metered. A chatty microservice mesh spread carelessly across AZs can generate a surprising data-transfer bill.
• us-east-1 (N. Virginia) is special. It is the oldest, largest, and cheapest region; many global services have their control plane there (IAM, CloudFront, Route 53, Organizations, ACM for CloudFront certs). A us-east-1 outage has historically had outsized blast radius because so much global machinery lives there.

Global vs Regional services

This distinction trips up newcomers constantly. Some AWS services are global (one namespace shared across all regions), others are regional (isolated per region, and you must pick where they run).

Practical consequences: an IAM role works in every region, but an EC2 security group only exists in the region you created it. S3 is a subtle case — the bucket namespace is global (bucket names are globally unique), but the bucket data lives in one region you choose. AMIs, snapshots, and key pairs are regional and must be copied to use them elsewhere.

The account model and AWS Organizations

An AWS account is the fundamental unit of isolation, billing, and security in AWS. Everything — resources, IAM, quotas, billing — is scoped to an account. Modern best practice is emphatically multi-account: you do not run dev, staging, and prod in one account.

AWS Organizations lets you centrally manage many accounts:

• Organizational Units (OUs) — hierarchical groupings of accounts (e.g., Prod OU, NonProd OU, Security OU, Sandbox OU). You attach policies at the OU level and they cascade to member accounts.
• Service Control Policies (SCPs) — organization-wide guardrails that set the maximum permissions any account (or its IAM users/roles) can ever have. An SCP is a filter, not a grant: it can only remove permissions, never add them. Even the account root user is bound by SCPs. Classic uses: deny disabling CloudTrail, deny leaving the org, restrict to approved regions, block deletion of security resources.
• Consolidated billing — all member accounts roll up to one payer account with a single bill. Volume discounts and Reserved Instance/Savings Plan benefits are pooled and shared across the whole org, which often saves money versus separate accounts.
• Management (payer) account — the account that created the org. Keep it nearly empty: no workloads, tightly locked down, used only for org administration and billing. It is the one account SCPs cannot restrict, so it is your highest-value target.

AWS Control Tower automates setting up a well-architected multi-account environment — a landing zone — with sensible defaults: a management account, a Log Archive account (centralized CloudTrail/Config logs), an Audit account (security tooling), pre-built OUs, and “guardrails” (managed SCPs + Config rules). It is the fastest path to an org that follows AWS’s own recommendations rather than hand-rolling one.

The shared responsibility model

AWS secures the cloud; you secure what you put in it. The dividing line shifts with how managed the service is.

For IaaS (EC2) you patch the OS and configure the firewall; AWS only guarantees the hardware and hypervisor. For managed services (RDS, ECS) AWS patches the engine/runtime, but data, access control, and network exposure are still yours. For fully serverless (S3, Lambda, DynamoDB) AWS runs almost everything, yet you still own who has access and what you store. The vast majority of AWS security incidents are customer-side misconfigurations — a public S3 bucket, an over-broad IAM policy, a leaked access key — not AWS failures.

The Well-Architected Framework — 6 pillars

AWS’s framework for evaluating architectures against a consistent set of trade-offs. Knowing the pillars gives you the vocabulary to reason about any design.

The Well-Architected Tool (free, in the console) walks you through a questionnaire per pillar and flags high-risk gaps. Sustainability was added in 2021 as the sixth pillar. The framework’s real value is as a review lens — before shipping, ask one hard question from each pillar and you will catch most architectural sins.

Key Concepts

How you access AWS

There is one control plane (the AWS API); everything below is a client that calls it.

# Configure credentials once (for CLI/SDK). Prefer SSO over long-lived keys.
aws configure sso                 # modern: IAM Identity Center
# or, legacy long-lived keys (avoid for humans):
aws configure                     # prompts for Access Key, Secret, region

# Who am I? — the single most useful debugging command in AWS.
aws sts get-caller-identity
# {
#   "UserId": "AROA...:alice",
#   "Account": "123456789012",
#   "Arn": "arn:aws:sts::123456789012:assumed-role/Admin/alice"
# }

# List S3 buckets, EC2 instances in a region
aws s3 ls
aws ec2 describe-instances --region ap-southeast-1 \
  --query 'Reservations[].Instances[].[InstanceId,State.Name,InstanceType]' \
  --output table

aws sts get-caller-identity answers “which account and identity am I actually operating as right now?” — the first thing to check when a command mysteriously returns Access Denied or touches the wrong environment.

ARNs — the universal resource address

Every AWS resource has an Amazon Resource Name (ARN), a globally unique identifier with a fixed grammar:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:s3:::my-bucket/data/file.txt            # S3: no region/account in ARN
arn:aws:iam::123456789012:role/DeployRole        # IAM: global, so region is empty
arn:aws:ec2:ap-southeast-1:123456789012:instance/i-0abc123
arn:aws:lambda:us-east-1:123456789012:function:my-fn

You reference resources by ARN throughout IAM policies, so reading an ARN fluently — spotting the service, region, and account — is a core skill. Note how global services (IAM, S3) leave the region field empty.

Pricing fundamentals

AWS pricing is pay-per-use, but how you commit changes the rate dramatically:

Guidance that saves real money:

• Compute Savings Plans are usually the best default commitment — they apply automatically across EC2, Fargate, and Lambda by dollar-spend, so you don’t lock yourself to one instance family the way standard RIs do.
• Buy commitments only after usage stabilizes (2–3 months of steady state). Commit to your baseline, leave the spiky top on on-demand or spot.
• Spot needs architecture, not just a checkbox — handle the 2-minute interruption notice, spread across instance types and AZs, never run a stateful primary on spot.
• Data egress is the classic bill shock. Ingress is free; egress to the internet and cross-region traffic is metered. “Cheap to check in, expensive to check out.”
• The Free Tier has three flavors: 12-month free (750 hrs/mo of t2/t3.micro EC2, 5 GB S3), always-free (1M Lambda requests/mo, 25 GB DynamoDB), and short trials. Set a billing alarm the day you open an account — the free tier has limits, and exceeding them silently is the #1 newcomer surprise.

The mental model for blast radius

• A single instance can fail → deploy ≥2 behind a load balancer.
• An AZ can fail → spread across ≥2 AZs (default for prod).
• A Region can fail → multi-region for tier-0 systems (expensive, complex).
• A global control plane (IAM, Route 53) can rarely fail → this is why true global redundancy sometimes means multi-cloud, and why us-east-1 dependencies deserve scrutiny.

Best Practices

1. Never use the root account for daily work. The root user can close the account and bypass most controls. Enable a hardware or virtual MFA on it, remove its access keys entirely, store its credentials in a physical safe, and use it only for the handful of tasks that genuinely require root (changing the account’s payment method, closing the account). Everything else goes through IAM Identity Center or IAM roles.

2. Adopt a multi-account strategy from the start. Separate accounts per environment (dev/staging/prod) and often per team give you hard blast-radius isolation, clean cost attribution, and independent security boundaries. One account for everything is a foot-gun that turns a dev mistake into a prod incident.

3. Use AWS Organizations with SCPs as guardrails. SCPs enforce org-wide invariants nobody — not even an account admin — can violate: deny leaving the org, deny disabling CloudTrail/Config, restrict to approved regions. Guardrails prevent whole classes of mistakes rather than catching them after the fact.

4. Bootstrap with Control Tower or a landing-zone blueprint. Hand-rolling a compliant multi-account setup is error-prone; Control Tower gives you a Log Archive account, an Audit account, baseline OUs, and managed guardrails out of the box that match AWS’s own recommendations.

5. Set billing alarms and budgets on day one. Surprise bills are the most common newcomer pain. Configure AWS Budgets with alerts at 50/80/100% of expected spend and enable Cost Anomaly Detection so a runaway resource pages you in hours, not at month-end.

6. Tag everything, and enforce tagging with policy. A consistent tag schema (Environment, Owner, CostCenter, Service) powers cost allocation, automated cleanup, and security policy. Use Tag Policies and SCPs so untagged resources are flagged or blocked — retroactive tagging never happens.

7. Prefer IAM Identity Center (SSO) over long-lived IAM users. Human access should be short-lived, federated, and centrally governed. Long-lived access keys leak, don’t expire, and are the root cause of a huge share of breaches. Reserve IAM users for legacy or programmatic edge cases that genuinely can’t federate.

8. Choose regions deliberately on four axes: latency to users, data-residency law, service/feature availability (new features and services land in us-east-1 first and lag elsewhere), and price (regions vary 20–50% for the same resource). Don’t default to us-east-1 just because tutorials do.

9. Design for Availability Zone failure by default. Spread every production workload across ≥2 AZs — it is the single cheapest reliability investment in AWS. Reserve the far greater cost and complexity of multi-region for genuinely tier-0 systems.

10. Run everything through Infrastructure as Code. Console-created “snowflake” resources are undocumented, unreproducible, and un-reviewable. Declare infrastructure in CloudFormation, CDK, or Terraform so it is version-controlled, peer-reviewed, and rebuildable after a disaster. Use the console and CLI for inspection and break-glass, not for standing up production.

11. Centralize logs in a dedicated, locked-down account. Aggregate CloudTrail, Config, and VPC Flow Logs into a write-once Log Archive account that even admins in other accounts cannot tamper with. This immutable audit trail is indispensable during incidents and compliance audits.

12. Encrypt by default and manage keys with KMS. Enable encryption at rest and in transit everywhere (it’s usually free and often on by default). Use AWS KMS, and adopt customer-managed keys where compliance requires control over the key lifecycle and an audit trail of every use.

13. Right-size and buy commitments after measuring. The biggest line item in most AWS bills is oversized, under-utilized compute bought “to be safe.” Review utilization with Compute Optimizer and Cost Explorer, shrink monthly, then commit Savings Plans to the stable baseline you’ve measured.

14. Review architectures against the Well-Architected pillars before shipping. Ask one hard question from each of the six pillars — operational excellence, security, reliability, performance, cost, sustainability. Use the free Well-Architected Tool to surface high-risk gaps early, when they’re cheap to fix.

15. Enable GuardDuty, Security Hub, and Config org-wide. These managed services continuously detect threats, misconfigurations, and drift from best practice across all accounts. Turning them on early is far cheaper than discovering a compromised key or a public database after the fact.

References

• AWS Documentation home
• AWS Global Infrastructure — Regions and AZs
• AWS Global Infrastructure map
• Regional and global AWS services (fault isolation whitepaper)
• AWS Organizations User Guide
• Service Control Policies (SCPs)
• AWS Control Tower User Guide
• Organizing your AWS environment using multiple accounts (whitepaper)
• AWS Shared Responsibility Model
• AWS Well-Architected Framework
• Well-Architected Framework — the six pillars
• AWS CLI documentation
• AWS CloudShell
• Amazon Resource Names (ARNs)
• AWS Pricing overview · Savings Plans · Spot Instances
• AWS Free Tier
• AWS Pricing Calculator
• AWS Architecture Center