← Course Index

AWS Account Setup & IAM

~25 min · AWS · AWS Map →

Ref

Primary Source

AWS IAM Best Practices

Official AWS guide to securing your account with IAM. Read the "Security best practices in IAM" section. Read →

AWS Account Setup Checklist

Before touching anything in AWS, do this immediately after creating your account:

Enable MFA on root account — go to IAM → Security credentials → MFA. Use an authenticator app, not SMS.
Never use the root account again — create an IAM admin user for all day-to-day work.
Set up billing alerts — Billing → Budgets → Create budget. Set an alert at $10 and $50. AWS bills can surprise you.
Enable CloudTrail — logs every API action. Essential for auditing and debugging.
Enable Cost Explorer — so you can see what's costing money.

🚨 Root account warning

The root account has unlimited privileges and cannot be restricted. If compromised, everything is lost. Lock it away — enable MFA, then never log in as root except for emergencies.

IAM — Identity & Access Management

IAM controls who can do what to which AWS resources. The fundamental principle is least privilege: grant only the permissions actually needed, nothing more.

Key Concepts

Users — humans or applications with long-term credentials
Groups — collections of users that share permissions
Roles — temporary credentials assumed by services or users (preferred over users for automation)
Policies — JSON documents that define what is allowed or denied

// Example IAM policy: read-only access to one S3 bucket
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ]
    }
  ]
}

IAM Roles — The Right Way to Authorize Services

When your EC2 instance needs to access S3, don't put AWS credentials in your code or environment. Attach an IAM role to the EC2 instance. The AWS SDK automatically uses the role's temporary credentials.

# Create a role with S3 read access and attach to EC2
# Via AWS CLI:
aws iam create-role   --role-name MyAppEC2Role   --assume-role-policy-document file://ec2-trust-policy.json

aws iam attach-role-policy   --role-name MyAppEC2Role   --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Your Node.js app using AWS SDK automatically uses the role:
const s3 = new AWS.S3();  // No credentials needed — role is auto-used

💡 Roles > Users for automation

Never hardcode AWS access keys in code or CI/CD. For EC2: use IAM roles. For GitHub Actions: use OIDC federation (configure once, no keys to rotate).

AWS CLI Setup

# Install AWS CLI v2
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip && sudo ./aws/install

# Configure with your IAM user credentials
aws configure
# AWS Access Key ID: [from IAM console]
# AWS Secret Access Key: [from IAM console]
# Default region: us-east-1
# Default output: json

# Verify
aws sts get-caller-identity

# Use named profiles for multiple accounts
aws configure --profile production
aws s3 ls --profile production

Check Your Understanding

1. Your EC2 instance needs to write to S3. What is the CORRECT way to provide AWS credentials?

2. You accidentally committed your AWS access key to GitHub. What do you do FIRST?

3. Which of these follows the "least privilege" principle for an app that only reads from DynamoDB?