What it is
Amazon Web Services (AWS) is a public cloud: on-demand compute, storage, databases and higher-level APIs, billed largely by use. An account is the hard boundary for billing and, by default, for permissions. A region is a geography. Resources you create in one region are not automatically in another. IAM is the identity system for humans and for services. EC2 is a virtual machine. Lambda runs a function. ECS and App Runner run containers. S3 stores objects (files). RDS runs managed relational databases including PostgreSQL.
You do not need all of these. AWS is not Azure and not Google Cloud, though the shapes rhyme: compute, data, identity, logs.
Why and when it is used
Choose AWS when the team or the company already standardised on it, when a service you need is strongest there, or when the hiring pool around you is AWS-shaped. It is a fine default and not a required one. A small app can also live on a single server. Cloud is a trade of operational control for someone else's data centres and a bill that tracks usage.
Do not start by enabling every service in a tutorial's architecture diagram. Do not put production in the same account as a personal experiment if you can avoid it. Account boundaries are the easiest isolation you will ever get.
How it works
You sign in as an IAM user or via single sign-on, then assume a role. Policies allow or deny actions on resources. The application should not run with your personal admin keys. Give it a role that can touch the one bucket and the one database it needs. The data plane is separate: S3 policies, database passwords or IAM authentication, security groups that control network access. A security group is a firewall, not an application login.
Infrastructure as code (CloudFormation, Terraform, CDK) records what you created. The console is a way to learn and a way to create snowflakes. Logs and metrics (CloudWatch is the common default) are how you see a failure after the process exits. Regions and availability zones matter when you promise resilience; one instance in one zone will go down with that zone.
Technologies and dependencies
An account with a budget alarm, the AWS CLI, and IAM that is not the root user. Root is for rare account tasks and should have MFA and no daily use. Compute of one kind, RDS or another database if you have data, S3 if you have files, and a secret store (SSM Parameter Store or Secrets Manager) instead of keys in git. Docker if you ship containers. Environment Variables come from the task definition or the platform, filled from the secret store.
How to get started
- Create an account. Turn on MFA for root. Create an admin IAM user or SSO for yourself. Stop using root.
- Set a budget alert before you create resources.
- In one region, run a tiny container or function that returns the value of a configuration variable.
- Create an S3 bucket with block-public-access left on. Upload a file. Read it from the app using a role, not a long-lived key on your laptop copied into production.
- Delete the experiment or you will pay for it next month.
- Write down the account id and region in the README. "It is in AWS" is not a location.
If a tutorial tells you to paste AWS_ACCESS_KEY_ID into a shell rc file and never rotate it, do not. Use a short-lived login.
Cautions and trade-offs
Public S3 buckets and open security groups are the classic incidents. Private by default. IAM wildcards (*) on production roles mean the app can do more than you think, including things that cost money.
Bills grow from idle load balancers, NAT gateways, unused elastic IPs and log retention you never set. Look at the bill. Multi-account setups (one account per environment) are worth it once a second environment exists. And do not treat AWS service names as an architecture. "We use Lambda, SQS, Dynamo, API Gateway and Step Functions" can be a small workflow or an unmaintainable mesh. Name the request path in one sentence before you add a service.