IAM Roles, Billing, and the Well-Architected Basics

Two last practical topics that matter on every real AWS project: giving your compute the right permissions without hardcoding credentials, and not getting an unpleasant billing surprise.

IAM roles for services, not just people

The single most important AWS security habit: an EC2 instance or Lambda function should be given an IAM role, not a hardcoded access key, to call other AWS services.

Lambda function → assumes an IAM Role → temporary credentials → calls S3, DynamoDB, etc.

The role is attached to the Lambda function (or EC2 instance) itself, AWS automatically provides temporary, auto-rotating credentials to your code, your application code never sees or stores a long-lived secret at all.

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-app-uploads/*"
}

Attach this policy to the Lambda's execution role, and the function can read/write that one bucket, and nothing else, without a single access key in its code or environment variables.

Budgets and cost alerts

AWS bills for exactly what you use, which is powerful but means an unexpected spike (a runaway loop calling an expensive API, a forgotten large instance) shows up on your bill, not before it happens. AWS Budgets lets you set a threshold and get alerted (or even trigger an action) before costs run away:

Budget: $50/month
Alert at: 80% ($40) and 100% ($50)

Setting at least one budget alert on any real account, even a generous one, is a cheap insurance policy against a costly surprise.

The Well-Architected Framework, briefly

AWS's Well-Architected Framework organizes best practices into six pillars:

You don't need to memorize the framework in depth this early, but recognizing the six pillars helps you understand why AWS documentation and architecture reviews keep bringing up the same handful of concerns.