3. Account setup and IAM security

IAM is the part of AWS that bites everyone at least once. Get it right at the start: root account locked down, daily-use admin role, deployment role with narrow permissions.

A compromised AWS account is a worst case worth taking seriously. The standard failure mode is straightforward: root credentials leak (a committed key, a phished password), an attacker spins up dozens of GPU instances in regions the owner doesn't watch, and the bill from a single weekend runs into four or five figures. The mitigations are equally standard: lock the root account behind MFA, do daily work as an IAM user with bounded permissions, and put a budget alarm in place so the bill can't surprise you.

This section runs all three: hardening the root, creating the daily-admin IAM user that the rest of the chapter's CLI commands run under, and wiring up an AWS Budgets alert.

Creating an AWS account

AWS requires a credit card for account creation but provides a Free Tier covering many services during your first 12 months. The Free Tier includes 750 hours per month of EC2 compute (enough for one instance running continuously), RDS database instances, limited ElastiCache usage, and more. Staying within Free Tier limits means minimal costs.

Make: Create an AWS account by visiting aws.amazon.com and clicking "Create an AWS Account." You'll need:

  • Email address: Use a personal email you control long-term, not a school or employer address that might expire
  • Account name: Choose something descriptive like "Personal Development" or "Portfolio Projects"
  • Payment information: AWS requires a credit card even for Free Tier usage to prevent abuse
  • Identity verification: AWS will call or text to verify your account, this is normal

Check: After creating your account, sign in to the AWS Management Console at console.aws.amazon.com. You'll see the AWS console dashboard with links to all services. This is your root account, and it has unrestricted access to everything in the account, which is exactly why the next two sections lock it down.

Never Use Your Root Account for Daily Work

The root account has unlimited permissions: it can delete every resource, change billing settings, or close the account. A leaked root credential hands the attacker the whole account. The rule that follows: enable MFA on the root login immediately, then use it only for the handful of tasks that genuinely require it (closing the account, restoring a locked-out admin user, changing billing contact). Everything else in this chapter runs as a separate IAM user.

Securing the root account

Root account security has three components: strong password, multi-factor authentication (MFA), and restricted usage. These protections stack to prevent unauthorized access.

Step 1: Enable MFA for root account

MFA requires both your password and a time-based code from an authenticator app to sign in. Even if someone obtains your password, they can't access your account without your phone. This single change prevents most account compromises.

Make: Enable MFA on your root account:

  1. In the AWS console, click your account name in the top-right corner
  2. Select "Security Credentials"
  3. Under "Multi-factor authentication (MFA)", click "Assign MFA device"
  4. Choose "Authenticator app" (recommended over hardware tokens for cost and convenience)
  5. Scan the QR code with an authenticator app like Google Authenticator, Authy, or 1Password
  6. Enter two consecutive MFA codes to verify the device works

Check: Sign out of AWS and sign back in. You'll be prompted for your MFA code in addition to your password. This two-factor authentication now protects your root account.

After initial setup, use your root account only for tasks that explicitly require root access: changing account name, closing your account, restoring IAM admin access if locked out, or modifying billing contact information. These tasks are rare. Most teams go months or years without touching the root account.

For all other work, including everything in this chapter, use IAM users with appropriate permissions. That bounds the blast radius. A compromised IAM credential gives the attacker only what that user can do; a compromised root credential gives them the whole account.

Setting up billing alerts

Billing alerts notify you when AWS charges exceed specified thresholds. Without alerts, you won't discover runaway costs until the credit card bill arrives. A compromised account or misconfigured auto-scaling policy can generate thousands of dollars in charges overnight. Billing alerts provide early warning.

Make: Configure billing alerts through AWS Budgets:

  1. In the AWS Console, search for "Billing" in the top search bar
  2. Click "Billing" to open the Billing dashboard
  3. In the left sidebar, select "Budgets"
  4. Click "Create budget"
  5. Choose "Cost budget" template
  6. Set budget amount to $25 (or your preferred threshold)
  7. Configure alerts at 80% ($20) and 100% ($25) of budget
  8. Enter your email address for notifications
  9. Review and create the budget

Check: You'll receive a confirmation email for the budget alerts. Click the confirmation link to activate notifications. Now you'll get emails when AWS spending approaches or exceeds your threshold.

Cost strategy for this chapter: Most services in this chapter qualify for AWS Free Tier during your first 12 months. Expected costs staying within Free Tier: $5-15 per month for Application Load Balancer hours and data transfer. Setting a $25 budget provides room for experimentation while alerting you if costs spike unexpectedly.

Beyond billing alerts, enable "Receive Free Tier Usage Alerts" in your billing preferences. AWS will email you when Free Tier usage approaches limits. This dual notification system (budgets + Free Tier alerts) provides comprehensive cost protection. You can also use AWS Cost Explorer to analyze spending patterns and identify optimization opportunities after your infrastructure is running.

Creating IAM users for daily work

IAM (Identity and Access Management) controls who can access your AWS account and what they can do. Instead of using your root account, you create IAM users with specific permissions. This follows the principle of least privilege: grant only the permissions necessary for the task at hand.

Make: Create an IAM user for deployment work:

  1. While still signed in as root, navigate to the IAM service in the AWS Console
  2. Click "Users" in the left sidebar, then "Add users"
  3. Set username to "daily-admin" (or your preferred name)
  4. Select "Programmatic access" (creates access keys for CLI/SDK)
  5. Select "AWS Management Console access" (allows web console login)
  6. Click "Next: Permissions"
  7. Select "Attach existing policies directly"
  8. Search for and attach: AdministratorAccess
  9. Click "Next: Tags" (skip), then "Next: Review", then "Create user"

Check: AWS displays your access credentials. You'll see:

  • Access Key ID: Like a username for programmatic access
  • Secret Access Key: Like a password, shown only once
  • Console sign-in link: URL for web console access

Critical: Download these credentials immediately. The Secret Access Key is shown only once. If you lose it, you'll need to generate new keys. Store credentials securely in a password manager.

About Administrator Access

For this learning chapter, we're using AdministratorAccess policy for simplicity: it grants full permissions to all AWS services. In production, you'd create custom policies with minimal required permissions. For learning and personal projects, AdministratorAccess is acceptable because it's your personal account. In team or production environments, always use least-privilege policies that grant only necessary permissions.

Configuring the AWS CLI

The AWS CLI (Command Line Interface) lets you interact with AWS services from your terminal. You'll use it to push Docker images to ECR, deploy ECS tasks, and manage infrastructure. The CLI needs your IAM credentials to authenticate requests.

Make: Install and configure the AWS CLI:

Terminal (macOS/Linux)
# macOS
brew install awscli

# Linux
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

# Verify installation
aws --version

Configure your credentials:

Terminal
aws configure

# You'll be prompted for:
AWS Access Key ID: [paste your Access Key ID]
AWS Secret Access Key: [paste your Secret Access Key]
Default region name: us-east-1
Default output format: json

Check: Verify AWS CLI access:

Terminal
aws sts get-caller-identity

# Output shows your IAM user:
{
    "UserId": "AIDAI...",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/daily-admin"
}

The CLI now authenticates as the daily-admin IAM user, not root. Every aws command for the rest of the chapter runs through this credential, and CloudTrail logs every call against the IAM user's identity so there's an audit trail to walk back if something looks off later.

Next, in section 4, we create the ECR repository, authenticate Docker against it, and push the Chapter 27 image up so ECS has something to pull when it starts a task.