🧭 AWS Services: A Map for People Who Know Linux

How AWS is organized (account, region, resource, ARN), the handful of services you meet first, a translation list from Linux ideas to AWS ones, and what keeps costing money when you are not looking

How AWS is organized

Azure puts a resource group between the subscription and the resource. AWS has no resource group. The structure is flatter:

1. The account is the container and the bill (see the account page). Companies group accounts with AWS Organizations.
2. The region (see the regions page) is where most resources live.
3. The resource: an instance, a bucket, a volume, a database.

Every resource has an ARN (Amazon Resource Name), a unique name that looks like arn:aws:SERVICE:REGION:ACCOUNT-ID:RESOURCE. You see ARNs in policies and in error messages. Read them left to right: the service, the region (empty for global things like S3 buckets and IAM), the 12-digit account, and the resource.

How do you group things, then?

• Tags. Labels on resources (project=blog, owner=anna) that you can search and that show up in cost reports. Turn on cost allocation tags to see the bill by project.
• Separate accounts. The strongest way to keep a test apart from production, and the real equivalent of "delete the whole group": close the account.
• CloudFormation stacks (and tools built on them, such as CDK, or Terraform with its own state). You describe a set of resources in a file, and deleting the stack deletes everything it made. This is the nearest thing to deleting a resource group.

No matter what you use, write down what you created while you learn: on AWS it is very easy to leave something behind in a region you have forgotten.

IAM: who may do what

IAM (Identity and Access Management) decides who can do what. The vocabulary:

• User: a person or program with a name and long-term credentials (a password, access keys). AWS recommends relying on temporary credentials instead where possible.
• Group: a set of users that get the same permissions.
• Role: an identity with no password or keys that someone or something assumes to get temporary credentials. Roles are how AWS recommends giving people (through Identity Center) and programs access.
• Policy: a JSON document that lists what is allowed or denied: actions, resources and conditions. By default everything is denied, and a policy has to allow something. An explicit deny always wins.
• AWS managed policies are ready-made ones (such as ReadOnlyAccess) that you can start from, and then narrow down: the least-privilege habit.

The most useful thing in the whole system for a Linux person: an EC2 instance can have a role, and AWS then hands that instance temporary credentials, which the AWS SDKs and the CLI on the machine find on their own. So there is no access key to copy onto the server, and none to leak. If a tutorial tells you to run aws configure on an EC2 server and paste keys, a role is the better way.

Ways to work

• The console (the website), CloudShell (a terminal in it), the AWS CLI (aws SERVICE COMMAND), and the SDKs for programs.
• CloudFormation, CDK and Terraform when you want to rebuild the same thing again.

The first services you will meet

Compute

• EC2 (Elastic Compute Cloud). Virtual servers. You choose an AMI (the image: Ubuntu, Amazon Linux, Windows), an instance type (the size, such as t3.micro), a key pair for SSH, a security group and a disk. The free AWS VM guide walks through one.
• Lightsail. A simpler, fixed-price way to rent a small server with a few extras.
• Lambda. Run a function when something happens, and pay for the time it runs.
• ECS, Fargate and EKS. Containers: ECS is AWS's own container service, Fargate runs containers without servers, and EKS is Kubernetes (compare the Kubernetes node access tutorial).

Storage

• S3 (Simple Storage Service). Objects (files) in buckets, reached by URL or API. Bucket names are globally unique. It is regional, and has storage classes from "standard" to "archive". Treat buckets as private unless you mean otherwise: public buckets are a classic source of leaks.
• EBS (Elastic Block Store). The disks of EC2 instances, in one AZ and attached to one instance at a time. It is the closest thing to a local disk.
• EFS (Elastic File System). A shared network file system that many instances mount at once, speaking NFS. Compare the NFS page, where we built the same idea ourselves.

Networking

• VPC (Virtual Private Cloud). Your private network in a region: address range, subnets (each in one AZ), route tables, and an internet gateway for traffic to and from the internet.
• Security groups. The instance-level firewall: allow rules only, and stateful (a reply to allowed traffic is allowed automatically). The same job as pf or iptables. Network ACLs are the stateless, subnet-level extra.
• Elastic IP. A fixed public address you keep. It is a billable resource (see below).
• Elastic Load Balancing (ALB for web traffic, NLB for plain TCP and UDP), Route 53 (DNS and domain names), NAT Gateway (lets private machines reach the internet), Site-to-Site VPN (compare the WireGuard page for a tunnel you build yourself).

Identity and secrets

• IAM and IAM Identity Center (above), Secrets Manager and Systems Manager Parameter Store (keep passwords and settings out of files), KMS (encryption keys).

Data

• RDS (managed MySQL, PostgreSQL and others) and Aurora, DynamoDB (a key-value and document database that scales automatically).

Watching and cost

• CloudWatch (metrics, logs and alarms: the idea of the monitoring page as a service), CloudTrail (a record of who called which API: the audit log), Cost Explorer and Budgets.

Linux idea, AWS idea

• sudo and file permissions → IAM policies and roles
• Users in /etc/passwd → IAM users, or Identity Center users
• A password or key in a config file → an instance role, Secrets Manager or Parameter Store
• A disk and /etc/fstab → EBS (one instance) or EFS (shared, NFS)
• iptables, nftables, pf → security groups (and network ACLs)
• nginx as a reverse proxy → Application Load Balancer
• /var/log and syslog → CloudWatch Logs
• Cron → EventBridge Scheduler with Lambda (from the documentation, not run here)
• Backups with rsync or zfs send → EBS snapshots and AWS Backup
• /etc/hosts and DNS servers → Route 53
• SSH key login stays SSH key login: EC2 asks for a key pair when you launch (or you can use Systems Manager Session Manager, which needs no open port 22: from the documentation, not run here)

What costs money while it sits there

This matches the free AWS VM guide, with what the documentation confirms:

• A running instance bills while it runs, idle or not.
• Stopping an instance. AWS says to stop it with the console, CLI or API, not only from inside the system, so that the stop is clean and recorded. A stopped instance is not deleted, its EBS disks keep billing, and when you start it again it is normally given a new public IPv4 address. Data on instance store volumes is erased on stop. To really remove it, terminate it.
• Public IPv4 addresses are billed. AWS charges $0.005 per address per hour (since February 1, 2024) for in-use public IPv4 addresses, including those on EC2 instances, and idle Elastic IPs too. That is about $3.60 a month for each address, and the older free tier had an allowance of 750 hours for the first 12 months.
• NAT Gateways and load balancers bill by the hour while they exist, plus data.
• Databases (RDS, Aurora) bill while they exist, even idle.
• Snapshots, S3 storage, CloudWatch logs and data going out to the internet all add small amounts that add up.
• The free plan does not allow some services, and its credits can run out quickly on the wrong ones: the console shows the balance.

The habit that fixes most of this: tag everything with a project name, look at EC2 Global View and the Billing page after every session, and delete what you do not need.

A first small path (from the documentation, not run here)

A tidy first experiment that needs no server: make a bucket, put a file in it, and take it all away. It needs a signed-in CLI.

aws s3 mb s3://YOUR-UNIQUE-NAME-12345 --region eu-west-1
echo "hello from aws" > hello.txt
aws s3 cp hello.txt s3://YOUR-UNIQUE-NAME-12345/
aws s3 ls s3://YOUR-UNIQUE-NAME-12345/
aws s3 rb s3://YOUR-UNIQUE-NAME-12345 --force

• aws s3 mb makes a bucket. The name must be globally unique and lowercase, and the --region decides where it lives.
• cp copies a file in, ls shows it.
• rb --force removes the bucket and everything in it. Only use --force on a bucket you made for this.

Then check the Billing console the next day, as the account page says.

What this page did not cover

CloudFormation and CDK in detail, Organizations and Control Tower, Elastic Beanstalk, App Runner, the AI and analytics services, hybrid networking with Direct Connect, and every service not named above. The AWS documentation covers each of them in depth.

The cheat sheet

• Structure: account (the bill), region, resource (with an ARN). No resource groups: group with tags, separate accounts, or CloudFormation stacks.
• IAM: users, groups, roles (temporary credentials), policies (JSON, default deny, explicit deny wins). Give EC2 a role instead of copying keys onto it.
• First services: EC2, S3, EBS and EFS, VPC with security groups, IAM, RDS or DynamoDB, CloudWatch, Budgets.
• Linux to AWS: sudo is IAM, fstab is EBS or EFS, pf is security groups, syslog is CloudWatch Logs, secrets in files are roles and Secrets Manager.
• Billing traps: a running instance, EBS disks and snapshots kept after a stop, public IPv4 at $0.005 per hour each, idle Elastic IPs, NAT gateways, load balancers, databases.
• Stop or terminate: stop from the console or CLI, terminate to remove. A stopped instance keeps its disks.
• Tidy experiment: aws s3 mb, aws s3 cp, aws s3 ls, aws s3 rb --force.

← AWS Regions and Availability Zones: Why Your Instance Disappeared · ↑ All tutorials