What Is AWS? A Developer's Guide to the Basics

What AWS actually is

Amazon Web Services is a cloud computing platform: a catalogue of on-demand infrastructure and managed services you rent by the second, the request, or the gigabyte, through an API. Instead of buying servers, racking them in a data centre and maintaining them for years, you make an API call and get a running machine, a database, a queue, or a petabyte of storage in seconds.

Launched publicly in 2006 with three services — S3 for storage, EC2 for compute and SQS for queues — AWS now offers over 200 services and is the largest cloud provider by market share. Almost all of it is available through the same three interfaces: the web console, the CLI, and the SDKs. Everything the console does is an API call, which is why infrastructure on AWS can be fully automated.

Why teams use it

• Elasticity. Scale from one server to a thousand in minutes and back down again, paying only for what runs.
• No capital expenditure. Hardware becomes an operating cost, which matters enormously for startups and for workloads with unknown demand.
• Managed services. A replicated, backed-up, patched Postgres in ten minutes instead of a week of DBA work.
• Global reach. Deploy in dozens of regions and serve users from hundreds of edge locations without owning anything.
• Compliance and security baseline. Physical security, hardware lifecycle and many certifications come with the platform.

The trade-offs are real too: cost at steady high scale can exceed owned hardware, service-specific APIs create migration friction, and the operational surface — IAM, networking, quotas, billing — is genuinely complex.

Regions, availability zones and edge locations

This is the single most important concept for designing anything reliable on AWS, and the one most often skipped.

• Region — a geographic area such as ap-south-1 (Mumbai) or us-east-1 (N. Virginia). Regions are fully isolated from each other. Most services are region-scoped, and data does not move between regions unless you move it.
• Availability Zone (AZ) — one or more discrete data centres within a region, with independent power, cooling and networking, connected to sibling AZs by low-latency private links. Deploying across two or three AZs is the standard way to survive a data-centre failure.
• Edge location — hundreds of small points of presence worldwide used by CloudFront (CDN) and Route 53 (DNS) to serve content close to users.

Choose a region by latency to your users, data-residency rules, service availability (new services often launch in us-east-1 first) and price, which varies meaningfully between regions.

The core services worth knowing

You do not need 200 services. Roughly fifteen cover the overwhelming majority of real applications, and these are the ones that appear in interviews.

Compute

Storage

Databases

Networking and delivery

• VPC — your private network: subnets, route tables, security groups, NAT. Everything else lives inside it.
• ELB / ALB — load balancers distributing traffic across instances, containers or Lambdas.
• Route 53 — DNS with health checks and latency- or geo-based routing.
• CloudFront — the CDN, caching content at edge locations.
• API Gateway — managed HTTP/REST/WebSocket front door with auth, throttling and validation.

Messaging, identity and operations

• SQS — durable queue for decoupling producers from consumers.
• SNS / EventBridge — pub-sub fan-out and event routing between services.
• IAM — who can do what to which resource. The security backbone of the entire platform.
• CloudWatch — metrics, logs, dashboards and alarms.
• CloudFormation / CDK / Terraform — infrastructure as code, so environments are reproducible.
• Secrets Manager / Parameter Store — managed storage for credentials and configuration.

A typical AWS architecture

Most production web applications on AWS look roughly the same, and being able to sketch this from memory is a genuinely useful interview skill.

Users
  → Route 53          (DNS)
  → CloudFront        (CDN, static assets + caching)
  → ALB               (load balancing, TLS termination)
  → ECS / Lambda      (application tier, private subnets, auto scaling)
  → ElastiCache       (hot reads)
  → RDS / DynamoDB    (primary data store, multi-AZ)
  → S3                (uploads, exports, backups)

Async path:  app → SQS / EventBridge → worker (Lambda / ECS)
Observability: CloudWatch logs, metrics, alarms → on-call
Identity:      IAM roles for every service; no long-lived keys

Key habits baked into that diagram: the application tier lives in private subnets and is only reachable through the load balancer; the database is multi-AZ; long-running work goes on a queue instead of blocking a request; and every component gets an IAM role rather than credentials in an environment file.

IAM and the shared responsibility model

AWS splits security into two halves. AWS is responsible for security of the cloud — data centres, hardware, hypervisors, managed service internals. You are responsible for security in the cloud — IAM policies, network rules, encryption settings, patching your own instances, and what your application does with data. Almost every publicised "AWS breach" is a customer-side misconfiguration, most commonly an overly permissive S3 bucket or an over-privileged IAM role.

IAM has four concepts you must be able to distinguish:

• Users — long-lived identities for humans. Use as few as possible; prefer SSO.
• Groups — collections of users that share policies.
• Roles — temporary credentials assumed by a service, an instance, or a federated user. This is how applications should authenticate, always.
• Policies — JSON documents granting or denying specific actions on specific resources.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-app-uploads/user-content/*"
  }]
}

The rule that prevents most incidents: never attach AdministratorAccess to an application, never put access keys in code or environment files when a role will do, and enable MFA on the root account and then stop using it.

How pricing actually works

AWS bills per resource, per unit, per hour or per request, and the surprises almost always come from the units people forget rather than the ones they planned for.

Three things to internalise early. Data transfer out of AWS and across availability zones is charged and adds up faster than compute. Idle resources still cost money — an unattached EBS volume, an unused NAT gateway, an idle load balancer all bill by the hour. And billing data lags real usage by roughly a day, so budget alerts are a lagging indicator, not a circuit breaker.

Getting started safely

1. Create an account, enable MFA on the root user, then never use root for daily work.
2. Create an admin IAM user or SSO identity and work from that.
3. Set a billing budget and alert at a low threshold — $5 or $10 — on day one.
4. Pick a region close to you and stay in it while learning; cross-region mistakes are expensive.
5. Learn S3, EC2, IAM and VPC first. Everything else builds on those four.
6. Deploy something tiny end-to-end: a static site on S3 + CloudFront, then an API on Lambda + API Gateway + DynamoDB.
7. Use infrastructure as code from the start so you can tear everything down reliably.
8. Tag every resource with an owner and project so you can find and delete it later.

aws configure                                  # set credentials and region
aws sts get-caller-identity                    # who am I?
aws s3 mb s3://my-unique-bucket-name           # make a bucket
aws s3 sync ./dist s3://my-unique-bucket-name  # upload a site
aws ec2 describe-instances --query \
  'Reservations[].Instances[].[InstanceId,State.Name]' --output table

Common beginner mistakes

• Using the root account for everyday work, or creating access keys for it.
• Committing access keys to a public repository — bots find them within minutes and mine crypto on your account.
• Opening security groups to 0.0.0.0/0 on SSH or database ports.
• Leaving resources running after a tutorial, especially NAT gateways and load balancers.
• Deploying into a single AZ and calling it highly available.
• Treating budget alerts as a hard spend limit — they are notifications, not caps. Use service quotas for hard limits.
• Clicking everything in the console with no infrastructure as code, then being unable to reproduce or delete it.

Summary

AWS is a programmable API over global infrastructure. Learn the geography — regions, AZs, edge locations — because it determines your reliability story. Learn the fifteen core services rather than the two hundred. Take IAM seriously, because the shared responsibility model puts almost all realistic risk on your side of the line. And treat billing as a system with its own failure modes: set budgets, use hard quotas, tag everything, and watch data transfer. With those foundations, the rest of the catalogue is just detail you can look up when a problem calls for it.