I've deployed production systems across e-commerce platforms, CRM tools, trading engines, and ride-hailing services—and I can tell you that most developers waste months trying to understand every corner of AWS when they should be shipping features. Learning AWS as an application developer means picking the right tools and learning them deeply, not chasing certification breadcrumbs through two hundred services you'll never touch.
This series covers the essentials. Not the nice-to-haves. Not the services you might use someday. Just what you need to build, deploy, and maintain production applications—and understand your bill when it arrives at the end of the month.
Why Most Developers Get AWS Wrong
I see this pattern constantly: a developer reads an AWS announcement, takes a certification exam covering 50 services, deploys something to the cloud, and then gets blindsided by a $4,000 bill because they didn't understand how RDS pricing works. They know CloudFormation syntax but can't explain why their VPC can't reach their database. They've heard of Lambda but have never actually sized an EC2 instance.
The core issue is that AWS marketing wants you to know about everything. AWS documentation covers everything. But you don't need to know everything. You need to know five things so well that you can troubleshoot them at 2 AM without reaching for Stack Overflow.
Start with IAM, VPC, EC2, S3, and RDS
These five services form the foundation of 95% of real applications I've built. Not because they're the sexiest or most modern—they're not—but because they're the core primitives. Every other AWS service either builds on top of these or integrates with them.
IAM: Your Security Backbone
Identity and Access Management isn't fun, but it's non-negotiable. You need to understand users, roles, policies, and the principle of least privilege. In production, I never create AWS access keys for humans; I use IAM roles with temporary credentials. I never grant * permissions; I grant exactly what's needed.
A real example: your CI/CD pipeline needs to push Docker images to ECR and deploy to ECS. Instead of generating an IAM user with admin access, create a role that only allows ecr:PutImage, ecr:GetDownloadUrlForLayer, and ecs:UpdateService on specific resources. This takes an extra 15 minutes and saves you from a compromised credential dumping your production database.
VPC: Your Private Network
A VPC is your isolated network in AWS. You define the IP ranges, create subnets across availability zones, set up routing, and control what traffic flows where. Most developers treat it as a checkbox during initial setup, then ignore it. That's a mistake.
Understanding VPCs means you can answer these questions instantly: Why can't my EC2 instance reach my RDS database? How do I allow external API calls from a Lambda function in a private subnet? Why does my application work in staging but not production?
The mental model is simple: a VPC is a network. Public subnets have routes to the internet gateway. Private subnets don't. Databases live in private subnets. Web servers can live in public subnets or private subnets behind a load balancer. Security groups act like firewalls at the instance level.
EC2: Compute You Control
EC2 is a virtual machine. You choose the instance type, the operating system, the storage, and you're responsible for patching, scaling, and monitoring. This is where I run application servers, background workers, and specialized workloads that don't fit Lambda.
For developers transitioning from on-premises or managed platforms, EC2 feels like freedom and burden simultaneously. You have complete control, which means you have complete responsibility. I typically use EC2 for stateful workloads—my NestJS API servers, worker processes consuming from Kafka, anything that needs persistent local storage or long-running connections.
The instance type matters. A t3.medium costs $0.04 per hour; an r6i.2xlarge costs $0.64 per hour. Pick wrong and you're either overpaying for performance you don't need or your application is constantly hitting resource limits. I start with t3 instances for testing and move to c5 or r5 instances only when profiling data tells me to.
S3: Your Object Store
Simple Storage Service stores files. Not databases, not hierarchical filesystems—objects. You put things in, you get things out. It's absurdly reliable and incredibly cheap if you understand the access patterns.
I use S3 for: application backups, user-uploaded files (profile photos, invoices), static assets behind a CDN, raw logs for later analysis. The pricing is simple per GB, but where people go wrong is thinking about S3 like a filesystem and creating millions of tiny objects. Each API call costs money. Each request to retrieve a 1KB file costs the same as retrieving a 1MB file.
RDS: Managed Relational Database
RDS runs PostgreSQL, MySQL, or other database engines. AWS handles backups, patches, and failover. You still need to understand how to configure it, size it, and monitor it.
The key difference from EC2 is that you can't SSH into an RDS instance and debug things directly. You work through the database client. The trade-off is worth it—automatic backups, read replicas for scaling reads, automated failover to a standby instance. I run all production databases on RDS.
Learn by Deploying Something Real
Tutorial projects are fine for learning syntax, but they don't teach you architecture. Instead, take a real application—something you've built before or something you want to build—and deploy it to AWS.
Here's what I mean by real:
- It has a database with actual schema and constraints
- It has authentication and authorization
- It needs persistent storage for files
- It has background jobs or async processing
- It actually serves users (even if just you and a few friends)
This is where things get concrete. You'll discover that your application needs to upload files—now you're integrating S3. You'll realize your database queries are slow—now you're learning RDS performance tuning. You'll want to run scheduled tasks—now you're building a worker on EC2 or exploring Lambda.
I recommend building a simple SaaS application: a note-taking app, a project tracker, a habit tracker. Anything with users, authentication, data persistence, and files. Deploy it to a single EC2 instance with an RDS database and S3 for attachments. Make it actually work. Invite some people to use it. Run it for a month.
This one month teaches you more than a year of taking courses.
Read the Bill — It Teaches Architecture
Your AWS bill is a window into your actual resource consumption. Most developers hide from it; I stare at it every month.
When you see the EC2 line item is $200 but S3 is $3, you're learning about your architecture. You're running an expensive always-on compute resource and barely using storage. Maybe that's correct. Maybe you should scale down the instance type or shut it down during off-hours.
When you see RDS is $150 but you're only running a small database, you're learning that you picked the wrong instance class or you have automatic backups creating snapshot costs. When you see data transfer costs are $500, you're learning that your application is shuttling data across regions unnecessarily or you're not using a CDN for static content.
I review our bill every week, not to punish the team but to understand what's consuming resources. This directly informs architecture decisions. Need to process 10GB of logs daily? Maybe Lambda with S3 is cheaper than an always-on EC2 instance. Running a API server that's mostly idle? Maybe save costs by using a smaller instance or an auto-scaling group that scales to zero at night.
| Service | What I Learned From the Bill |
|---|---|
| EC2 costs $300+ | Instance is too large or running 24/7 unnecessarily |
| RDS costs $200+ | Database is oversized or backup retention too aggressive |
| Data transfer $100+ | Cross-region traffic or missing CDN |
| S3 costs $20+ | Good—S3 is cheap. Only worry if it's $500+ |
Depth in a Few Services Beats a Tour of All
AWS has 200+ services. Lambda, DynamoDB, Kinesis, SageMaker, Comprehend, Transcribe—the list goes on. Here's what I've learned: knowing these five services deeply beats knowing 50 services at surface level.
Why? Because depth lets you troubleshoot. When your application mysteriously crashes, you can walk through your IAM permissions, check your VPC routing, examine your EC2 security groups, verify your RDS connections, and find the issue in minutes instead of hours. When you're shallow in many services, you're constantly referencing documentation and guessing.
I can size an EC2 instance, estimate the cost, build a VPC from scratch, design a security group policy, write a SQL query that won't timeout, and troubleshoot database connections without thinking. This frees me to focus on application logic instead of infrastructure minutiae.
Once you're solid on these five, pick one more service that solves an actual problem you have. Running background jobs? Learn SQS and Lambda. Need to process streams? Learn Kinesis. Want to cache database queries? Learn ElastiCache. Add depth incrementally, not breadth frantically.
Common Mistakes
- Using default VPC and security group settings: The defaults are permissive for learning but insecure for production. Create isolated VPCs, use security groups that allow only necessary traffic.
- Not backing up RDS databases: Automated backups are enabled by default, but verify retention. I keep 30 days of backups; it costs next to nothing and saves lives.
- Storing secrets in code or environment variables: Use AWS Secrets Manager or Parameter Store. I generate a role with read access to secrets; my applications authenticate and fetch secrets at startup.
- Trying to learn everything at once: Pick the five core services. Get comfortable. Deploy something real. Then expand.
- Not monitoring your bill: Set up AWS Cost Explorer and check it weekly. A forgotten instance running for three months is a bad surprise. Catching it in week one is a learning opportunity.
- Assuming managed services (RDS, Lambda) require zero tuning: They require less tuning than self-hosted, but you still need to understand instance types, query performance, memory allocation, and timeout settings.
Key Takeaways
- Master IAM, VPC, EC2, S3, and RDS before exploring other services. These five services cover 95% of production applications.
- Learn by building and deploying something real that you actually use, not a tutorial project that sits idle.
- Review your AWS bill weekly. It teaches you more about efficient architecture than any course can.
- Depth beats breadth. Know five services inside out rather than 50 superficially. This makes troubleshooting and optimization fast and reliable.
- Each service has common gotchas—wrong instance types, overly permissive security groups, poor database tuning. Learn these patterns so you don't repeat them.
This is Day 1 of a 100-day journey. You're not trying to become an AWS certified solutions architect by Friday. You're building a solid foundation that lets you deploy production systems confidently. The next 99 days, we'll deepen this foundation and add pieces as you need them.
Tomorrow, we dive into IAM properly—users, roles, policies, and how to think about permissions. See you then.
Comments
Loading comments…