Your First 60 Minutes in AWS: What Everyone Skips and Regrets Later

You create an AWS account, generate root access keys, and share them on Slack so your cofounder can deploy. You are moving fast. Three months later, you wake up to a $47,000 bill. Cryptominers have been running on your account for weeks. CloudTrail was not enabled, so you cannot even see how they got in.

This happens constantly. Not because founders are careless, but because AWS security documentation assumes you have a compliance team and six months to implement controls. You have 18 months of runway and a product to ship.

Time: About 60 minutes.

Outcome: A locked-down AWS account with MFA on root, an IAM admin user, CloudTrail logging, billing alerts at $10/$50/$100, and the first file of your agent governance system.

Why This Matters

AWS operates on a shared responsibility model. They secure the physical data centers, the hypervisors, the network fabric. You secure your account, your data, and your configurations. Every misconfiguration is your problem.

┌─────────────────────────────────────────────────────┐
│                YOUR RESPONSIBILITY                   │
├─────────────────────────────────────────────────────┤
│  Customer Data & Encryption                          │
│  Identity & Access Management (IAM)                  │
│  Application Security                                │
│  OS, Network & Firewall Configuration                │
│  Security Group Rules                                │
├─────────────────────────────────────────────────────┤
│                AWS RESPONSIBILITY                    │
├─────────────────────────────────────────────────────┤
│  Physical Security of Data Centers                   │
│  Hardware & Network Infrastructure                   │
│  Virtualization Layer                                │
│  Managed Service Internals (S3, RDS, Lambda)         │
└─────────────────────────────────────────────────────┘

By the end of this post, your account will be protected against:

• Credential theft: root keys floating around in Slack, .env files, or GitHub commits
• Bill shock: waking up to charges you did not expect
• Invisible breaches: attackers operating without any audit trail
• Single point of failure: one compromised password giving total access

Root Account Lockdown

When you create an AWS account, you get a single identity: the root user. This account has unlimited privileges. It can bypass every IAM policy, delete CloudTrail logs, close the entire account, and do anything to any resource with no restrictions.

There is no way to limit root’s power. That is by design. It is the break-glass account for emergencies. But that same unlimited power makes it the single most dangerous credential in your infrastructure.

The goal: use root once to set up your account, then never touch it again.

Delete Root Access Keys

Root access keys are long-lived credentials that grant unlimited API access. If they exist, delete them now.

Enable MFA on Root

MFA adds a second authentication factor. Even if someone steals your password, they cannot sign in without physical access to your MFA device.

When You Actually Need Root

After setup, these are the only tasks that require root access:

• Close or rename your AWS account
• Change the root email address
• Activate IAM access to Billing (one-time, we do this below)
• Restore IAM permissions if completely locked out
• Change your AWS Support plan

Full list: Tasks requiring root credentials

For everything else, use an IAM admin user.

Your First IAM Admin User

MFA protects against password theft, but it does not reduce root’s power. A mistake made while signed in as root (deleting the wrong resource, misconfiguring a policy) has no safety net.

An IAM admin user has the same practical capabilities for daily work, with critical differences:

┌──────────────────────────────────────────────────┐
│                  ROOT USER                        │
│  Unlimited Power · No Guardrails · Emergency Only │
│  MFA Enabled · Locked Away · Never Used Daily     │
└──────────────────────┬───────────────────────────┘
                       │ Creates
                       ▼
┌──────────────────────────────────────────────────┐
│               IAM ADMIN USER                      │
│  Full Practical Access · Actions Logged           │
│  Revocable · Restrictable · Daily Operations      │
└──────────────────────────────────────────────────┘

Every action your IAM admin takes is logged in CloudTrail with a specific user identity. You can revoke access without losing account control. You can add restrictions later.

Create the Admin Group and User

Create a group first, then add your user to it. This pattern scales when you hire.

CloudTrail: Your Audit Log

CloudTrail records every API call made in your AWS account. Every console click, every CLI command, every SDK call. When something goes wrong (a resource gets deleted, a security group opens to the internet, costs spike), CloudTrail is how you figure out what happened.

Without it, you are flying blind. With it, you have a forensic record of:

• Who made the change (which IAM user or role)
• What they changed (which API call, which resource)
• When it happened (timestamp)
• Where they were (source IP address)
• How they authenticated (console, CLI, SDK)

Management events (resource creation, deletion, configuration changes) are free to log. There is no reason not to enable this.

Your account is now recording everything. If something goes wrong six months from now, you will be able to trace exactly what happened.

Billing Alerts: No Surprise Bills

AWS bills are post-paid. You find out what you owe after you have already spent it. Without alerts, a misconfiguration or attack can run up thousands of dollars before you notice.

Activate IAM Billing Access

By default, only root can view billing. Fix this now so your IAM admin can manage budgets.

Create Budget Alerts

Free Tier Gotchas

AWS Free Tier is generous but has sharp edges:

Enable Cost Anomaly Detection

AWS Cost Anomaly Detection uses machine learning to flag unusual spending patterns. It is free.

Tagging Strategy

Tags are key-value labels on AWS resources. They seem optional until you have 200 resources and cannot tell which project they belong to, whether they are safe to delete, or who created them.

Start with four required tags on every resource:

The ManagedBy tag becomes critical when you start using AI coding agents. When an agent provisions a resource, tagging it ManagedBy=agent creates an audit trail you will rely on heavily.

Region Selection

AWS has 30+ regions worldwide. Pick one primary region and stick with it.

Recommendation for learning: us-east-1 (N. Virginia). It gets new features first, has the most documentation, and is generally the cheapest. The latency difference for development work is irrelevant.

For production, answer two questions before deploying:

1. Where are your users? If 80% are in India, ap-south-1 (Mumbai) serves them better than Virginia.
2. What does compliance require? GDPR may require EU data residency. Check before you deploy, not after.

Test your latency to AWS regions:

Create Your AGENT-INSTRUCTIONS.md

This is the first file of a system that will grow across all 70 parts of this series.

AGENT-INSTRUCTIONS.md is a living document that tells AI coding agents how to work with your infrastructure. It starts with a single line. By Part 62, it will contain 96 lines of rules covering IAM, Terraform, networking, security, Docker, Lambda, and agent governance.

It will be the most important file in your repository.

Create it now in your project root:

# Agent Instructions for AWS Infrastructure

One line. That is all for now. Every time we establish a rule, a convention, or a boundary in this series, we add it here. The agents you work with will read this file before generating infrastructure code.

This is not busy work. This file is the difference between an agent that generates plausible-looking infrastructure and an agent that generates infrastructure matching your specific constraints. We prove that difference with data starting in Part 4.

What’s Coming

Next in Part 2: IAM, The Key to Everything, we set up IAM properly: users, groups, roles, policies, and a dedicated agent execution role with scoped permissions. The AdministratorAccess policy your admin user has today is temporary.

Key Takeaways

1. The root account is for emergencies only: lock it with MFA, delete access keys, and never use it for daily work.
2. CloudTrail is free for management events and there is no reason not to enable it from day one.
3. Billing alerts at $10, $50, and $100 catch problems before they become disasters.
4. Your AGENT-INSTRUCTIONS.md starts as a single line today; by Part 62, it will be 96 lines of accumulated rules and the most important file in your repository.