The latest articles on DEV Community by azmal (@azmal). https://dev.to/azmal https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3728845%2Ffc676ec5-24c4-4f31-a6b5-14d3bfbb44c6.jpg https://dev.to/azmal en azmal Fri, 23 Jan 2026 16:13:43 +0000 https://dev.to/azmal/an-aws-cheatsheet-for-builders-what-to-use-when-and-why-3fnf https://dev.to/azmal/an-aws-cheatsheet-for-builders-what-to-use-when-and-why-3fnf <h1> An AWS Cheatsheet for Builders: What to Use, When, and Why </h1> <h2> Introduction </h2> <p>AWS can feel overwhelming, especially when you’re trying to build and ship something real.</p> <p>There are hundreds of services, detailed documentation, and many “best practices.” But most builders don’t need all of that on day one. What we need is clarity: what to use, when to use it, and why.</p> <p>This article is a practical AWS cheatsheet for builders. It’s not complete, and it’s not meant to be. It focuses on the small set of decisions that matter most when you’re actually building.</p> <h2> Compute: Where Your Code Runs </h2> <h3> EC2 </h3> <p>Use EC2 if:</p> <ul> <li>Your app runs all the time</li> <li>You need full control over the environment</li> <li>You’re okay managing servers</li> </ul> <p>If you’re choosing EC2 by default, pause. It’s powerful, but it also comes with responsibility.</p> <h3> Lambda </h3> <p>Use Lambda if:</p> <ul> <li>Your logic is event-based</li> <li>Execution time is short</li> <li>You don’t want to manage servers</li> </ul> <p>Lambda is a great default for APIs, background tasks, and automation.</p> <h3> ECS / Fargate </h3> <p>Use ECS or Fargate if:</p> <ul> <li>You like containers</li> <li>You want scaling without managing servers directly</li> </ul> <p><strong>Simple rule:</strong><br><br> If you don’t know why you need EC2, start with Lambda or Fargate.</p> <h2> Storage: Files and Assets </h2> <h3> S3 </h3> <p>Use S3 for:</p> <ul> <li>File uploads</li> <li>Images and videos</li> <li>Static website assets</li> <li>Backups</li> </ul> <p>Most applications only need S3. It’s simple, reliable, and scales quietly in the background.</p> <h3> EBS </h3> <ul> <li>Disk storage attached to EC2</li> </ul> <h3> EFS </h3> <ul> <li>Shared file storage across multiple instances</li> </ul> <p><strong>Builder tip:</strong><br><br> If you’re early, don’t design complex storage. Start with S3 and move on.</p> <h2> Databases: Where Data Lives </h2> <h3> DynamoDB </h3> <p>Use DynamoDB if:</p> <ul> <li>Your access patterns are simple</li> <li>You want high scale</li> <li>You want minimal maintenance</li> </ul> <h3> RDS </h3> <p>Use RDS if:</p> <ul> <li>You need SQL</li> <li>Your data is relational</li> <li>You want familiar database behavior</li> </ul> <h3> Aurora </h3> <p>Use Aurora if:</p> <ul> <li>Your app is growing</li> <li>You need higher performance with SQL</li> </ul> <p><strong>Rule of thumb:</strong><br><br> DynamoDB for simplicity, RDS for structure.</p> <h2> Authentication and Secrets </h2> <h3> IAM </h3> <ul> <li>Permissions between AWS services</li> <li>Internal access control</li> </ul> <h3> Cognito </h3> <ul> <li>User sign-up and login</li> <li>Token-based authentication</li> </ul> <h3> Secrets Manager </h3> <ul> <li>API keys</li> <li>Database credentials</li> </ul> <p><strong>Never:</strong></p> <ul> <li>Hardcode secrets</li> <li>Commit credentials to a repo</li> </ul> <p>This mistake is common—and expensive.</p> <h2> Deployment and Automation </h2> <h3> Amplify </h3> <ul> <li>Great for frontends</li> <li>Fast MVP setups</li> <li>Works well with modern frameworks</li> </ul> <h3> CodePipeline </h3> <ul> <li>Simple CI/CD inside AWS</li> </ul> <h3> GitHub Actions + AWS </h3> <ul> <li>Flexible</li> <li>Popular with builders</li> <li>Easy to grow with</li> </ul> <p><strong>Minimum goal:</strong><br><br> One push = one deployment.</p> <h2> Monitoring and Cost Awareness </h2> <h3> CloudWatch </h3> <ul> <li>Logs</li> <li>Errors</li> <li>Basic metrics</li> </ul> <h3> AWS Budgets </h3> <ul> <li>Set monthly limits</li> <li>Get alerts early</li> </ul> <h3> Cost Explorer </h3> <ul> <li>See where money goes</li> <li>Spot unexpected usage</li> </ul> <p><strong>Builder mindset:</strong><br><br> Think in cost per user, not service prices.</p> <h2> Quick Decision Table </h2> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>You need</th> <th>Use this</th> </tr> </thead> <tbody> <tr> <td>Static website</td> <td>S3 + CloudFront</td> </tr> <tr> <td>API backend</td> <td>Lambda + API Gateway</td> </tr> <tr> <td>User authentication</td> <td>Cognito</td> </tr> <tr> <td>File uploads</td> <td>S3</td> </tr> <tr> <td>Fast MVP backend</td> <td>Amplify</td> </tr> </tbody> </table></div> <h2> Closing Thoughts </h2> <p>You don’t need to know every AWS service to build effectively.</p> <p>Most progress comes from making a few clear decisions, shipping early, and adjusting as you learn. AWS supports that approach well—if you keep things simple.</p> <p>This cheatsheet is not a rulebook. It’s a starting point.</p> <p>If you found this useful, you can follow me on DEV and the AWS Builder Community as <strong>@azmaldev</strong>.<br><br> I share short notes and lessons while building with AWS.</p> <p><strong>Tags:</strong> <code>aws</code> <code>cloud</code> <code>devops</code> <code>backend</code> <code>cheatsheet</code></p> beginners aws cheatsheet devops