What Every Developer Should Know About AWS Before Touching the Cloud

---

A no-fluff breakdown of how AWS is built, how access works, and why it matters.

---

Most people approach AWS by jumping straight into a service — spinning up an EC2 instance, uploading something to S3 — without understanding the foundation underneath. That works until it doesn’t. Then you’re debugging permissions errors at 2am wondering why nothing has access to anything.

This is the piece I wish I’d read first.

---

The Cloud Isn’t Magic. It’s Real Estate.

AWS is just Amazon’s data centers, rented out. Instead of buying servers, you pay for computing power, storage, databases, and networking on demand — by the hour, sometimes by the second. Scale up when you need it, scale down when you don’t. No upfront hardware. No wasted capacity.

That’s the model that quietly took over the infrastructure world. Netflix, Airbnb, NASA, the New York Times — all running on AWS. The appeal isn’t just convenience. It’s that AWS handles the hard parts — physical security, power redundancy, hardware failures — so you don’t have to.

---

AWS Is Everywhere (Literally)

One of the first things to understand about AWS is just how distributed it is. The infrastructure spans the globe in three layers:

Regions are geographic areas where AWS operates clusters of data centers — US East, Europe West, Asia Pacific, and so on. Each Region is completely isolated from the others. Data in one Region doesn’t automatically go to another. This matters for latency, compliance, and disaster recovery.

Availability Zones are the next layer down. Every Region has at least 3 AZs, each one made up of one or more physical data centers. They have separate power supplies, networking, and cooling — so a failure in one doesn’t cascade into the others. But they’re connected with ultra-low latency networking, so they can work together seamlessly.

The Sydney Region, for example, looks like this:

ap-southeast-2a
ap-southeast-2b
ap-southeast-2c

Three separate facilities. One coherent region.

Edge Locations are the third layer — over 400 of them across 90+ cities in 40+ countries. These don’t run full AWS services. They exist to cache content close to users, so when someone in Mumbai loads a page hosted in Virginia, they’re actually getting it from a server much closer to home. This is what powers CloudFront, AWS’s content delivery network.

---

Some Services Are Global. Most Aren’t.

This trips people up early. Not all AWS services behave the same way geographically.

A few services are global — they exist outside of any specific Region and apply everywhere:

• IAM — the permissions system

• Route 53 — DNS

• CloudFront — content delivery

• WAF — web application firewall

Everything else — EC2 instances, Lambda functions, databases, storage buckets — is region-scoped. When you create one, you’re creating it in a specific Region. If you need it in multiple Regions, you deploy it multiple times.

This isn’t a quirk. It’s intentional. It gives you fine-grained control over where your infrastructure lives.

---

IAM: The Part Most People Underestimate

IAM — Identity and Access Management — is the most important thing to understand in all of AWS. Get it wrong and you either lock everything down so tightly nothing works, or you leave doors open that shouldn’t be.

When you first create an AWS account, you get a root account. Full, unrestricted access to everything. The right move is to set it up, enable MFA on it immediately, and then never use it again for daily work. Treat it like a break-glass emergency key.

Instead, you create IAM Users — one per person. Each user gets their own login and their own set of permissions. Users can be organized into Groups, which is where permissions are actually managed. Add a user to the Developers group, and they inherit every permission that group has. Remove them from the group, access gone.

Groups can only contain users — not other groups.

---

Policies Are Just JSON

Every permission in AWS comes from a policy — a JSON document that spells out exactly what is and isn’t allowed. Here’s what one looks like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    }
  ]
}

This allows the holder to describe — read information about — any EC2 resource. The structure is always the same:

• Effect — Allow or Deny

• Action — which AWS API calls this covers (wildcards work: ec2:Describe*)

• Resource — which specific resources this applies to (* means all)

• Principal — who the policy applies to, used in resource-based policies

• Condition — optional rules for when this policy activates

The principle AWS hammers on here is least privilege — only give someone the permissions they actually need to do their job. Nothing more. It sounds obvious until you see a production account where everyone has AdministratorAccess because it was easier at the time.

---

Password Policies and MFA: Table Stakes for Security

AWS lets you enforce a password policy across all users — minimum length, required character types, expiration windows, and prevention of reuse. These aren’t optional nice-to-haves. They’re baseline hygiene.

MFA goes further. With Multi-Factor Authentication enabled, logging in requires both a password and a physical or virtual device. Even if a password gets stolen, an attacker can’t get in without the second factor.

AWS supports a few types:

• Virtual MFA apps like Google Authenticator or Authy — free, runs on your phone, the standard choice for most people

• Hardware security keys like YubiKey — a physical USB device, one key can cover multiple accounts

• Hardware key fobs from Gemalto or SurePassID — used mainly in regulated environments like government cloud (AWS GovCloud)

Enable MFA on the root account before you do anything else. Then enforce it for every user.

---

Three Ways to Work With AWS

Once the account is set up, you have three ways to actually use it:

The Management Console is the browser interface. Good for exploring, learning, and one-off tasks. It’s visual, it’s approachable, and it’s how most people start. Protected by your password and MFA.

The CLI is where things get efficient. The AWS Command Line Interface lets you run AWS commands directly from your terminal. Automating deployments, writing scripts, managing resources at scale — the CLI is the right tool for all of it. It’s open source and connects directly to AWS’s public APIs.

The SDK is for building applications that interact with AWS programmatically. AWS has SDKs for JavaScript, Python, Java, Go, Ruby, .NET, C++, and more. If your app needs to read from a database, send a message to a queue, or store a file, the SDK is how it happens. Interestingly, the CLI itself is built on top of the AWS SDK for Python.

The CLI and SDK both authenticate using Access Keys — an Access Key ID paired with a Secret Access Key. Think of them as a username and password for programmatic access. Generate them through the console, store them securely, and never commit them to a repository or share them with anyone.

---

IAM Roles: Permissions for Services, Not Just People

Here’s something that isn’t obvious at first: AWS services themselves need permissions too.

If an EC2 instance needs to read from S3, or a Lambda function needs to write to a database, they can’t just do it without authorization. The wrong solution is to give them an access key — that means credentials sitting inside a server, which is a security problem waiting to happen.

The right solution is an IAM Role. A Role is a set of permissions that a service can temporarily assume. You attach a Role to your EC2 instance, Lambda function, or CloudFormation stack, and it gets exactly the access it needs — with no hardcoded credentials anywhere.

This is the recommended pattern for all service-to-service communication in AWS.

---

How to Know If Your Permissions Are Actually Right

Two tools exist specifically to help you audit what’s going on:

IAM Credentials Report gives you a full account-level snapshot — every IAM user, whether their password is active, whether MFA is enabled, when their access keys were last rotated. Useful for compliance reviews and catching accounts that should have been deactivated months ago.

IAM Access Advisor works at the user level. It shows which services a specific user has permissions to access, and the last time they actually used each one. If someone hasn’t touched a service in six months, the question worth asking is: do they still need that access?

These two tools together make it much easier to move toward least privilege over time rather than just in theory.

---

The Short Version

AWS is infrastructure on demand, distributed across Regions and Availability Zones designed to survive failures at every level. Most services are region-scoped. A handful — IAM, Route 53, CloudFront — are global.

IAM is how everything is secured. Users get credentials. Groups get policies. Services get roles. Everything is governed by JSON policy documents that spell out exactly what’s allowed and what isn’t.

The access model is worth spending real time on. Security problems in the cloud almost never come from sophisticated attacks. They come from misconfigured permissions — someone left a door open that should have been locked.

Understand how IAM works and you’ll sidestep most of those problems before they happen.