AWS has over 200 services, and the single biggest mistake developers new to it make is trying to learn all of them — the actual day-to-day toolkit most applications need is a small, stable subset.
AWS (Amazon Web Services) is the largest cloud platform, offering compute, storage, database, and networking services that can be combined to build nearly any infrastructure. For most application developers, a focused subset — EC2 or ECS for compute, S3 for storage, RDS for databases, Lambda for serverless functions, and IAM for access control — covers the large majority of real-world needs, with the rest of the catalog being specialized tools reached for only when a specific problem calls for them.
Why AWS Matters (and When to Skip It)
AWS's breadth means almost any infrastructure requirement has a corresponding managed service, and its maturity means those services are battle-tested at massive scale. For teams needing fine-grained infrastructure control, specific compliance certifications, or services a smaller platform doesn't offer, AWS is often the only realistic option.
Skip direct AWS usage for smaller projects where a PaaS (Railway, Vercel, Fly.io) provides the same outcome with dramatically less configuration overhead — AWS's flexibility comes at a real cost in setup complexity and ongoing management that isn't worth paying without a genuine need for that level of control.
Getting Started with AWS
A minimal Lambda function deployed via the AWS CLI:
// handler.ts
export const handler = async (event: any) => {
return {
statusCode: 200,
body: JSON.stringify({ message: "Hello from Lambda" }),
};
};
aws lambda create-function \
--function-name my-function \
--runtime nodejs22.x \
--handler handler.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/lambda-execution-role
S3 for object storage:
import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
const s3 = new S3Client({ region: "us-east-1" });
await s3.send(new PutObjectCommand({
Bucket: "my-app-uploads",
Key: "user-avatar.jpg",
Body: fileBuffer,
}));
Core AWS Concepts Every Developer Should Know
IAM (Identity and Access Management) governs every permission in AWS, and getting it wrong is the source of most AWS security incidents — either overly permissive roles that widen your attack surface, or overly restrictive ones that break things in confusing ways. The principle of least privilege (grant exactly what's needed, nothing more) is the core discipline here.
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::my-app-uploads/*"
}
VPCs (Virtual Private Clouds) define your network isolation boundary. Understanding subnets, security groups, and how services communicate within a VPC is foundational for anything beyond the simplest single-service deployment.
Managed services trade control for reduced operational burden, the same tradeoff as choosing a PaaS over raw infrastructure, just within AWS itself — RDS instead of self-managed Postgres on EC2, ECS/Fargate instead of self-managed Kubernetes, Lambda instead of self-managed servers for event-driven workloads.
Cost visibility requires active management. AWS billing can surprise teams that don't set up budgets, alerts, and regular cost reviews — unlike a fixed-price PaaS plan, AWS costs scale directly (and sometimes unexpectedly) with actual resource usage.
Common AWS Mistakes and How to Fix Them
Mistake 1: overly permissive IAM policies, often using wildcard * permissions during development and never tightening them. This significantly widens the blast radius of any credential compromise. Fix: scope IAM policies to exactly the actions and resources needed, and review permissions regularly.
Mistake 2: no cost monitoring or budget alerts set up. Without them, a misconfigured service or unexpected traffic spike can produce a large, surprising bill before anyone notices. Fix: set up AWS Budgets with alerts from the start of any project, not after the first surprising invoice.
Mistake 3: reaching for raw AWS infrastructure (EC2, manual VPC setup) when a managed service or a PaaS would meet the need with far less operational overhead. Fix: default to managed AWS services (Lambda, Fargate, RDS) over self-managed infrastructure unless there's a specific reason for the extra control, and consider a PaaS entirely for smaller projects.
When Should You Use AWS Directly Instead of a Managed PaaS?
Use AWS directly when you need infrastructure control, specific compliance certifications, or services and scale a PaaS doesn't support — common for larger organizations and specific regulated industries. Use a managed PaaS for smaller teams and projects where infrastructure management overhead isn't worth trading for AWS's flexibility, which the large majority of new projects fall into.
AWS for Developers in Production
Set up IAM roles with least-privilege access from the start of any project — retrofitting tight permissions onto an already-running system with broad access is much harder than establishing discipline early. Also use Infrastructure as Code (Terraform, AWS CDK) rather than manual console configuration for anything beyond quick experimentation, since manually-configured infrastructure is neither reproducible nor reviewable.
If you're evaluating AWS for a new project, start with the smallest subset of services that solves your actual problem (often just Lambda, S3, and RDS or DynamoDB) rather than trying to learn the platform's full breadth upfront — you can add services as real needs surface.