AWS

01Regions, availability zones and shared responsibility

AWS is split into regions, separate geographic areas such as Frankfurt or Ireland, each with its own copy of most services. A region contains several availability zones (AZs): one or more data centers with independent power, cooling and networking, close enough for fast connections. Running your app in at least two AZs protects you from one data center failing; using several regions protects against a whole region failing, at much higher cost and complexity. Choose a region close to your users and compliant with data rules. Security is shared: AWS is responsible for security of the cloud (hardware, data centers, the hypervisor), and you are responsible for security in the cloud: your IAM permissions, network rules, patching your EC2 servers, encrypting and not exposing your data.

• Region = geographic area; AZ = isolated data center(s) inside it.
• Highly available = spread across at least two AZs.
• Misconfiguration on your side is the most common cause of cloud breaches.

02Core services and when to use them

You do not need hundreds of services; a dozen cover most web applications. Compute comes in three flavours: EC2 virtual machines you manage, containers on ECS (simpler, AWS-native) or EKS (managed Kubernetes), optionally serverless with Fargate, and Lambda functions that run on events with no servers at all. Data lives in S3 for files and RDS or Aurora for managed relational databases. CloudFront is the CDN in front, Route 53 is DNS and health-checked routing. VPC is your private network, IAM controls who may do what, and SQS is a managed queue for decoupling work.

• EC2: full control, long-running servers, any software.
• ECS / EKS (+ Fargate): containers without managing schedulers yourself.
• Lambda: short event-driven tasks (up to 15 minutes), pay per invocation.
• S3: object storage for uploads, backups, static sites; versioning and lifecycle rules.
• RDS / Aurora: managed PostgreSQL or MySQL with backups, Multi-AZ failover, replicas.
• CloudFront + Route 53: CDN and DNS; SQS: queues; VPC + IAM: network and permissions.

03Networking: a sensible VPC layout

A VPC (virtual private cloud) is your isolated network inside a region. You divide it into subnets, each in one availability zone. Public subnets have a route to an internet gateway and hold only things that must face the internet, typically the load balancer. Private subnets hold application servers and databases; they cannot be reached from the internet directly. Security groups act as stateful firewalls attached to each resource: the load balancer accepts 443 from anywhere, the app accepts traffic only from the load balancer's security group, the database only from the app's security group. Private resources that need outbound internet, for package updates or external APIs, use a NAT gateway, which is convenient but one of the classic cost surprises, so VPC endpoints for S3 and other AWS services are worth adding.

• Public subnet: load balancer only.
• Private subnet: app and database, reached via security-group references.
• Reference security groups, not IP ranges, between your own tiers.

04IAM and least privilege

IAM (Identity and Access Management) decides who can call which AWS API on which resource. The principle of least privilege means every identity gets only the permissions its job needs. Protect the root account with MFA and never use it day to day. People should sign in through IAM Identity Center with temporary credentials, not long-lived access keys. Applications should use roles: an EC2 instance profile, an ECS task role or a Lambda execution role gives the code short-lived credentials automatically, so no keys sit in .env files. Write narrow policies like the example, which lets an app read and write only one bucket prefix. Use IAM Access Analyzer to find unused or overly broad permissions, and enable CloudTrail to record every API call.

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": ["s3:GetObject", "s3:PutObject"],
7      "Resource": "arn:aws:s3:::example-app-uploads/uploads/*"
8    }
9  ]
10}

05Cost traps and how to avoid them

AWS bills are rarely high because of one big server; they grow from small items nobody watches. NAT gateways charge per hour and per gigabyte processed. Data transfer out to the internet and between availability zones adds up quietly. Every public IPv4 address is billed hourly. Unattached EBS volumes, old snapshots, idle load balancers and forgotten test environments keep charging. CloudWatch log ingestion can cost more than the servers that write the logs. RDS Multi-AZ roughly doubles database cost, which is often right, but should be a conscious choice. Defend yourself from the first day: set AWS Budgets alerts, tag every resource with project and environment, review Cost Explorer monthly, set log retention, and use Savings Plans or reserved capacity for stable workloads.

1aws budgets create-budget --account-id 111122223333 \
2  --budget '{"BudgetName":"monthly","BudgetLimit":{"Amount":"200","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \
3  --notifications-with-subscribers '[{"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"[email protected]"}]}]'

06AWS or a VPS?

A VPS from DigitalOcean, Hetzner or similar gives you a fixed monthly price, generous included bandwidth and one simple control panel. For a single application, a well-run VPS with Docker Compose, off-site backups and monitoring is often several times cheaper than the equivalent on AWS and easier for a small team to understand. AWS wins when you need what is hard to build yourself: managed databases with automatic failover and point-in-time recovery, autoscaling for spiky traffic, many regions, compliance certifications that enterprise clients ask for, or deep integration with other AWS services. A common middle path is a VPS for compute plus a few targeted managed services, such as S3-compatible storage for uploads and a CDN. Decide by requirements and team skill, not by fashion.

07How IAM decides allow or deny

Every AWS API call is evaluated against all policies that apply to it, and the logic is strict. Everything starts as an implicit deny. An explicit Deny in any applicable policy always wins. Within an account, a request is allowed only if some identity-based or resource-based policy allows it and nothing denies it. On top of that, guardrails can only take permissions away, never grant them: service control policies from AWS Organizations, permission boundaries on a role, and session policies must all allow the action as well. Conditions make policies precise: restrict by source VPC endpoint, require encryption in transit, require MFA, or limit to resources tagged for one project. When access fails, the error message and CloudTrail usually say which policy type denied it, and the IAM policy simulator can replay the decision.

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Sid": "DenyInsecureTransport",
6      "Effect": "Deny",
7      "Principal": "*",
8      "Action": "s3:*",
9      "Resource": ["arn:aws:s3:::example-app-uploads", "arn:aws:s3:::example-app-uploads/*"],
10      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
11    }
12  ]
13}

08Multi-account structure with AWS Organizations

An AWS account is the strongest isolation boundary AWS offers: separate permissions, separate quotas and a separate bill line. So mature setups use many accounts, managed through AWS Organizations, instead of one account for everything. A typical layout has a management account used only for billing and organisation settings, a log archive account that receives CloudTrail and config logs from every other account and that application teams cannot modify, a security account for audit tools, and separate workload accounts for production, staging and sandboxes. Service control policies at the organisation level enforce rules nobody can override inside an account, such as deny leaving the organisation, deny disabling CloudTrail, or deny any region outside the ones you use. People sign in once through IAM Identity Center and switch into roles per account. AWS Control Tower can set up this landing zone with sensible defaults.

• Blast radius: a leaked staging credential cannot touch production.
• Quotas and costs are separated per account and per team.
• SCPs are guardrails: they limit, but never grant, permissions.

09EC2 access done right: IMDSv2 and Session Manager

Every EC2 instance can read its own metadata, including the temporary credentials of its instance role, from a local address, 169.254.169.254. In the original IMDSv1, any simple GET request worked, so a server-side request forgery bug in the app, one that makes the server fetch a URL an attacker supplies, could leak those credentials. That is how several well-known breaches happened. IMDSv2 requires a session token obtained with a PUT request and a hop limit, which blocks most SSRF paths; require it on every instance, and new instance types and AMIs increasingly default to it. For shell access, AWS Systems Manager Session Manager opens a session through the SSM agent, authenticated by IAM, logged to CloudTrail, with no inbound port 22, no bastion host and no SSH keys to rotate. Port forwarding through it also reaches private databases for debugging.

1# require IMDSv2 on an existing instance
2aws ec2 modify-instance-metadata-options --instance-id i-0123456789abcdef0 \
3  --http-tokens required --http-endpoint enabled
4 
5# shell without SSH or open ports
6aws ssm start-session --target i-0123456789abcdef0
7 
8# tunnel to a private RDS instance through that host
9aws ssm start-session --target i-0123456789abcdef0 \
10  --document-name AWS-StartPortForwardingSessionToRemoteHost \
11  --parameters '{"host":["db.internal.example.com"],"portNumber":["5432"],"localPortNumber":["5432"]}'

10Where network money goes, and how to keep it

Networking is where AWS bills surprise people, because traffic is priced by path. Data from the internet into AWS is free. Data out to the internet is charged per gigabyte, and CloudFront's rates are usually lower than serving directly from EC2 or S3, with a free monthly allowance, so a CDN often saves money as well as latency. Traffic between availability zones is charged in both directions, so chatty services in different zones, or replicas in other zones, have a real cost. A NAT gateway charges per hour and per gigabyte processed, on top of normal transfer, so private servers pulling large images or backups through NAT pay twice. Gateway VPC endpoints for S3 and DynamoDB are free and remove that traffic from the NAT path; interface endpoints for other services cost per hour but can still be cheaper. Every public IPv4 address is billed hourly too.

• Add the free S3 gateway endpoint to every VPC with private subnets.
• Serve public assets through CloudFront, not straight from S3 or EC2.
• Use Cost Explorer grouped by usage type to find NAT and transfer costs.