AWS (Amazon Web Services) is a huge set of cloud services: servers, databases, storage, networking, and a couple hundred more things. At first glance it's a wall of acronyms, and it's easy to get lost. But look closer and almost everything rests on four pillars. Get comfortable with them, and the rest will slot into a picture that makes sense.

Those four pillars are: accounts (where everything actually lives and who pays for it), IAM (who is allowed to do what), regions and availability zones (where your resources physically live and how to survive an outage), and VPC (how your private network is arranged). Let's take them in order, in plain words.

Accounts: the boundary of security and money

An AWS account is like a separate apartment. Everything you create (servers, databases, files) lives inside a single account, and it isn't visible from a neighboring account. Resources, access permissions, and the bill for services — each account has its own.

At first it seems logical to keep everything in one account. But as soon as a project grows, companies set up many accounts and group them under the umbrella of AWS Organizations — for example, a separate account for the live system (production), a separate one for the test system (staging), a separate "sandbox" for experiments. Often — one account per team.

Why do it this way:

  • Limit the damage. If someone accidentally deletes resources or an access key leaks, the trouble won't spread beyond a single account. The live system in another account stays intact.
  • Understand the bill. Costs are visible per account, and it's immediately clear who spent how much, without an investigation.

The main practical takeaway: the phrase "we have AWS" always drags along the question "but in which account?" And access from one account into another is done not by copying keys, but through the "assume role" mechanism — more on roles below.

IAM: who can do what

IAM (Identity and Access Management) answers a single question: who is allowed to do what and with which resource. It's the permissions system for all of AWS. It has three key concepts.

A policy — a document in JSON format that describes permissions. It reads almost like a sentence: "allow reading objects from such-and-such storage."

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::orders-export/*"
    }
  ]
}

Here Action is what we allow (s3:GetObject — download a file), Resource is what it's over (arn:... — the address of the specific orders-export storage), and Effect: Allow — allow it.

A role — a set of policies that can be "put on" temporarily. A role has no permanent password or key: whoever assumes it gets temporary credentials for a few hours, after which they expire. That's far safer than permanent keys.

A user — a person or system with permanent access keys. In modern AWS this is almost a relic: people sign in through single sign-on (SSO), and programs work through roles.

Two rules that save your nerves and your money.

First: your code should never carry access keys around with it. When a program runs on an AWS server (on an EC2 virtual machine, in an ECS container, or in an EKS Kubernetes cluster), the platform itself hands it a role — this is called an instance profile for EC2, a task role for containers, and in Kubernetes it's IRSA (a role bound to a ServiceAccount). The AWS library (AWS SDK) finds these temporary credentials automatically, going through the standard sources in turn (this walk-through is called the credentials chain). Keys written into a config, into build variables, or, worse yet, committed into git — that's the classic path to a leak. For more on how this works in code, see the AWS SDK integration.

Second: least privilege. Give roles exactly what they need: the orders service — reading its own queue and writing to its own storage, not "allow everything with storage" just to "make it work." Writing out narrow permissions costs an extra ten minutes. Cleaning up the aftermath of overly broad permissions is an incident. A detailed breakdown of policies and roles is in the article on IAM.

Regions and availability zones

A Region is an AWS geographic location: for example, Frankfurt, Stockholm, Ireland. Each region is independent of the others: resources are tied to a region, and data doesn't travel between regions on its own — if you want a copy in another region, you have to set that up separately.

An Availability Zone (AZ) is an isolated data center (more precisely, a group of data centers) within a region. Each zone has its own power, its own cooling, its own network — this is done on purpose so that a fire or failure in one zone doesn't touch its neighbor. At the same time, zones within one region are connected by fast links: the latency between them is single-digit milliseconds.

Why a beginner should know this:

  • Fault tolerance is built on multiple zones within one region. For example: the primary database in one zone, its replica in another; copies of the application scattered across different zones; a load balancer on top. If one zone "goes down" (and this does happen occasionally), the service keeps running on the remaining ones.
  • A whole region going down is very rare, and protection against it (replication to another region) costs more and is set up separately. That's the topic of resilience and disaster recovery.
  • Traffic between zones costs money. If services in different zones chatter with each other without restraint, it shows up on the bill.

How to build high availability across multiple zones is covered in more detail in the article on scaling and availability.

VPC: your private network

A VPC (Virtual Private Cloud) is your personal isolated network inside AWS, something like a fenced yard where your servers and databases live. Here's the minimal set of concepts that will get you started.

Subnets come in two kinds:

  • A public subnet has a way out to the internet through an Internet Gateway. This is where you put what needs to be reachable from outside: load balancers, entry points.
  • A private subnet doesn't face outward directly. If a service in a private subnet needs to reach the internet (for example, to download an update), it goes through a NAT Gateway — a device that lets outbound traffic out but doesn't allow inbound traffic from outside.

The rule is simple: servers and databases live in private subnets, and only load balancers and entry points sit in public ones.

A security group is a firewall (network filter) at the resource level. It answers the question "who can connect to me and on which port." A good technique: write rules not by IP addresses, but by references to other groups. For example, "only the app group may connect to the database" — and it doesn't matter what addresses the application has. This is close in spirit to network policies in Kubernetes.

VPC endpoints let you reach AWS services straight from a private subnet, without going out to the internet and without paying for NAT traffic. For S3 storage and the DynamoDB database there are free gateway endpoints; for most other services you use interface endpoints (via PrivateLink, which does cost money). It's useful to know the difference so you aren't surprised by the bill.

A typical beginner mistake is to put a database in a public subnet "so it's convenient to connect from a laptop." Convenience is solved differently (through a bastion host or AWS SSM), and a public database is an invitation for scanners and password-guessers. A deeper look at the network model is in the article on networking in AWS.

Where this applies

These four pillars come up in literally any work with AWS. Creating a server — you pick an account, a region, and a zone. Launching an application — you give it a role instead of keys. Bringing up a database — you place it in a private subnet and lock down the security group. Any next service you study (compute, serverless functions, managed databases) rests on this foundation.

Where beginners stumble:

  • Storing access keys in code or in git. The most common and most expensive mistake. Use roles, and keep keys only where there's truly no other way.
  • Handing out overly broad permissions ("allow everything") to get things working faster. Later those permissions are forgotten and left un-narrowed, hanging as a hole for years.
  • Putting a database in a public subnet for convenience — and getting scanned from outside.
  • Confusing a region with a zone or not understanding why a resource is "not visible": often the reason is that it was created in another region.
  • Ignoring traffic between zones and through NAT — and it quietly trickles onto the bill.

What to learn next. If you're just finding your footing, the logical next step is to dig deeper into networking and IAM, then look at where to run a service. When it comes to automation, don't create everything by hand in the console — describe infrastructure as code: start with the fundamentals of infrastructure as code, then pick a tool — Terraform, CloudFormation, or CDK. If your services run in Kubernetes, a lot will layer directly on top of these fundamentals: Kubernetes fundamentals and cluster operations. And to look at all of this from the height of best practices, the Well-Architected Framework is useful.