☁️ AWS Learning Notes · Expanded Edition
Global Infrastructure · Local Zones · IAM · MFA · AWS CLI · SDK · Security Tools — a complete, structured study sheet with 18 core arguments, 10 hands-on steps, 16 quotes and 18 concept cards.
18
Core arguments
10
Applicable steps
16
Valuable quotes
18
Concept cards
The 18 most important conclusions of this module. Each point states the main viewpoint in one line and explains why it matters in practice.
You rent compute, storage and networking instead of buying hardware, and you pay only for what you consume. This converts large capital expenses into small, variable operating costs and removes the need for capacity guessing.
Regions → Availability Zones → Data Centers, extended by Edge Locations and Local Zones. Every architectural decision about latency, cost, compliance and resilience is ultimately a decision about where you deploy.
Each Region contains typically three or more AZs. They are physically separated but connected by low-latency links, so spreading resources across them gives you fault tolerance and high availability.
Each AZ has redundant power, networking and connectivity. Treat an AZ as your basic unit of failure isolation — if you only deploy in one AZ, you have a single point of failure.
Racks, servers, storage and cooling are fully managed by AWS. You interact with them only through APIs, the Console, CLI or SDK — never with physical hardware.
Hundreds of Points of Presence power CloudFront CDN, Route 53 and Global Accelerator. They cache and route traffic near the user, cutting latency for global audiences far away from the Region.
They place compute, storage and select services near large population or industry centers for single-digit-millisecond latency — ideal for media production, gaming, real-time inference and regulated workloads.
Evaluate latency to your users, compliance and data-residency laws, cost (prices differ per Region) and service availability (new services launch in some Regions first).
Identity and Access Management answers one question everywhere: who can do what, on which resource, under which conditions? It is free to use and central to every AWS security decision.
Attach policies to groups, not to individuals. A user can belong to multiple groups and inherits the union of all their policies — one change updates hundreds of users at once.
Understanding this structure separates guesswork from real AWS security work. Policies can be AWS-managed or customer-managed, and inline policies exist too — but reusable managed policies are preferred.
IAM evaluates all applicable policies together. If any policy explicitly denies an action, the request is rejected — even if ten other policies allow it. This is how guardrails are built.
Minimum length, mixed character types, forced rotation and reuse prevention apply account-wide. It costs nothing and blocks the most common credential attacks.
A stolen password should never be enough. AWS supports virtual MFA apps, hardware TOTP tokens and FIDO security keys. Enable it on root immediately, then on every privileged user.
An IAM Role grants temporary, automatically rotated credentials to EC2, Lambda or other AWS services. This removes long-lived access keys from your code and is the recommended pattern for machine access.
The Console is for humans and exploration, the CLI for repeatable scripting and automation, and the SDK for embedding AWS calls directly into application code. All three use the same IAM permissions.
Credential Reports, IAM Access Analyzer and last-accessed information show you which users, keys and permissions are actually used — so you can remove what is not.
Grant the minimum, monitor what is used, then tighten further. Combine with root-account protection, MFA and group-based permissions to form the complete IAM best-practice set.
A practical, ordered checklist: from securing the root account to auditing permissions. Follow the numbers in order — each step builds on the previous one.
The root user has unrestricted power over billing and every resource. Enable a virtual MFA device on day one and stop using root for daily work.
# 1. Console: Account menu → Security credentials → Assign MFA device
# 2. Verify that MFA is enforced on the account
aws iam get-account-summary \
--query "SummaryMap.AccountMFAEnabled" \
--output textEnforce minimum length, mixed character types, forced rotation and reuse prevention for every IAM user in the account.
aws iam update-account-password-policy \
--minimum-password-length 14 \
--require-symbols \
--require-numbers \
--require-uppercase-characters \
--require-lowercase-characters \
--allow-users-to-change-password \
--max-password-age 90 \
--password-reuse-prevention 5Always attach permissions to a group, then put users inside it. This is the single biggest maintainability win in IAM.
aws iam create-group --group-name Admins
aws iam attach-group-policy \
--group-name Admins \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
# Verify the attachment
aws iam list-attached-group-policies --group-name AdminsCreate a dedicated admin user (never share root), assign it to the group, and have the user enable their own MFA on first login.
aws iam create-user --user-name alice
aws iam add-user-to-group \
--user-name alice \
--group-name Admins
# Give console access with a forced reset on first login
aws iam create-login-profile \
--user-name alice \
--password 'ChangeMe-2024!Strong' \
--password-reset-requiredThe CLI turns every console click into a repeatable command. Configure it with an access key, a default Region and JSON output.
# macOS / Linux installation
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip && sudo ./aws/install
# Configure once
aws configure
# AWS Access Key ID : AKIA...
# AWS Secret Access Key : ****
# Default region name : eu-west-1
# Default output format : json
aws --versionA one-line sanity check that prevents the classic “I deployed to the wrong account” incident. Run it in every new shell session.
aws sts get-caller-identity
# {
# "UserId": "AIDAEXAMPLE",
# "Account": "123456789012",
# "Arn": "arn:aws:iam::123456789012:user/alice"
# }Grant only the exact actions on the exact resources. Start small and add permissions only when something actually fails.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ReadOnlyAppBucket",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-app-bucket",
"arn:aws:s3:::my-app-bucket/*"
]
},
{
"Sid": "BlockBucketDeletion",
"Effect": "Deny",
"Action": "s3:DeleteBucket",
"Resource": "*"
}
]
}Customer-managed policies are versioned and reusable. Attach them to groups (humans) or roles (services).
aws iam create-policy \
--policy-name AppReadOnlyS3 \
--policy-document file://policy.json
aws iam attach-group-policy \
--group-name Developers \
--policy-arn arn:aws:iam::123456789012:policy/AppReadOnlyS3
aws iam list-attached-group-policies --group-name DevelopersCreate a role with a trust policy for the EC2 service, attach the permission policy, and attach the role to the instance. Credentials are rotated automatically.
# trust-policy.json — who may assume this role
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "Service": "ec2.amazonaws.com" },
"Action": "sts:AssumeRole"
}]
}
aws iam create-role \
--role-name EC2-S3-ReadRole \
--assume-role-policy-document file://trust-policy.json
aws iam attach-role-policy \
--role-name EC2-S3-ReadRole \
--policy-arn arn:aws:iam::123456789012:policy/AppReadOnlyS3
aws iam create-instance-profile --instance-profile-name EC2-S3-ReadProfile
aws iam add-role-to-instance-profile \
--instance-profile-name EC2-S3-ReadProfile \
--role-name EC2-S3-ReadRoleGenerate a credential report, find unused users, keys and permissions, then delete or deactivate them. Repeat monthly.
aws iam generate-credential-report
aws iam get-credential-report \
--query Content --output text | base64 -d > report.csv
# List access keys for every user to spot stale credentials
aws iam list-users --query "Users[].UserName" --output text | tr '\t' '\n' | \
while read u; do
aws iam list-access-keys --user-name "$u" \
--query "AccessKeyMetadata[].{User:'$u',Key:AccessKeyId,Status:Status}" \
--output table
doneSixteen short, memorable statements from the module — the kind of lines worth re-reading before an exam or a design review.
“AWS is a cloud provider that lets you build applications without owning the hardware — you rent what you need, when you need it.”
“A Region is a physical location in the world where AWS has multiple Availability Zones.”
“An Availability Zone is one or more discrete data centers with redundant power, networking and connectivity.”
“Edge Locations exist to deliver content to your users with the lowest possible latency.”
“Local Zones let you run latency-sensitive workloads closer to your end users, in a specific city.”
“When you pick a Region, think about latency, compliance, cost and which services are available there.”
“IAM is a global service — users, groups and roles are not tied to a Region.”
“A user can belong to multiple groups, and inherits the combined permissions of every group.”
“An explicit Deny in a policy always overrides any Allow.”
“Never use the root account for everyday tasks — protect it with MFA and lock it away.”
“If an AWS service needs to access other AWS services, use an IAM Role — not access keys in your code.”
“Multi-factor authentication means a stolen password alone is never enough to log in.”
“The AWS CLI is a tool that lets you interact with AWS from the command line — perfect for automation.”
“The AWS SDK lets your own application code call AWS APIs directly, in the language you already use.”
“You can access AWS three ways: the Management Console, the Command Line Interface, and the Software Development Kit.”
“Apply the principle of least privilege: give only the permissions a user or service actually needs.”
Eighteen key terms explained in plain language, each with a real-world comparison so it sticks.
Renting IT resources — servers, storage, databases, networking — over the internet on demand, instead of buying and maintaining your own hardware.
Analogy: Taking a taxi instead of buying a car — you pay per ride and never worry about maintenance or parking.
A geographic area in the world (for example eu-west-1, Ireland) that contains multiple isolated Availability Zones. You choose a Region to be close to users, meet data-residency laws, or reduce cost.
Analogy: A city where you open a branch office — pick the city closest to your customers.
One or more physically separate data centers inside a Region, with independent power and networking but connected by high-speed links. Deploying across AZs gives you fault tolerance.
Analogy: Different buildings of the same company in one city — if one burns down, the others keep running.
The actual building full of racks, servers, storage and cooling systems. It is the physical layer you never touch directly — AWS manages it entirely on your behalf.
Analogy: The warehouse behind an online shop — customers see the website, never the shelves.
Hundreds of small AWS sites in major cities used by CloudFront, Route 53 and Global Accelerator to cache content and route traffic closer to the end user.
Analogy: Convenience stores in every neighbourhood — you don’t drive to the central warehouse for milk.
An extension of a Region placed in a large metro area, offering compute, storage and select services with single-digit-millisecond latency to local users.
Analogy: A pop-up kitchen in your district instead of the main restaurant across town — same menu, much faster delivery.
Identity and Access Management — a global service that controls who can access which AWS resources and under what conditions. It is free to use and central to every AWS security decision.
Analogy: The security desk of an office tower: it checks your badge and tells you which floors you may enter.
A long-lived identity representing one person or one application, with its own credentials (password and/or access keys). Best practice is one user per human, never shared.
Analogy: A personal employee badge with your name and photo on it.
A container of users that shares permissions. Groups cannot contain other groups, and a user can be in several groups at once — permissions are the union of all of them.
Analogy: A department like “Finance” — everyone in it automatically gets the same door access.
A JSON document defining permissions via Effect, Action, Resource and optional Condition. Policies are attached to users, groups or roles. An explicit Deny always wins.
Analogy: A page in the company rulebook: “Employees may open the archive door, but may not remove boxes.”
A user inherits every policy attached to every group they belong to, plus any policy attached directly to them. The effective permission set is the union — minus any explicit Deny.
Analogy: Holding three different club memberships — you can enter every room any one of them unlocks.
An identity assumed temporarily by an AWS service (EC2, Lambda) or by another account. It issues short-lived credentials, so no long-term secret ever lives on your server.
Analogy: A visitor badge issued at reception for the day — it expires automatically at 6 pm.
A second proof of identity beyond the password: virtual apps (Google Authenticator, Authy), hardware TOTP tokens or FIDO security keys. Even a leaked password becomes useless.
Analogy: Your bank card plus the PIN — one alone gets you nowhere.
Account-level rules for IAM user passwords: minimum length, required character types, maximum age before rotation, and how many previous passwords cannot be reused.
Analogy: The building’s key policy — keys must be long, changed quarterly, and never a copy of an old one.
A command-line tool that calls AWS APIs using your credentials. It is scriptable, reproducible and the natural choice for automation, CI/CD pipelines and quick operational checks.
Analogy: Ordering food through an app instead of walking to the counter — same kitchen, faster and scriptable.
Language-specific libraries (Python/boto3, JavaScript, Java, Go…) that let your application call AWS APIs directly in code, with built-in retries, request signing and pagination.
Analogy: A universal adapter kit — it lets your own language “speak AWS” without hand-crafting raw requests.
Credential Reports list every user, key, MFA status and last login. IAM Access Analyzer finds resources shared outside your account, and last-accessed data reveals unused permissions.
Analogy: A CCTV review of the building — you check who entered, when, and which doors were never opened at all.
Grant the minimum permissions required to do the job, and no more. Add scope only when a real need appears, and remove it when it disappears.
Analogy: A hotel key that opens only your room — not the whole floor.
The original module outline, grouped into four logical tracks so you can see how the pieces fit together.
🌍
🔐
📱
⌨️
🌐
Infrastructure
Regions → AZs → Data Centers, extended by Edge Locations and Local Zones.
🔐
IAM
Users, Groups, Policies, Roles, MFA, password policy — least privilege by default.
⌨️
Access
Console for exploring, CLI for automation, SDK for building.