← Articles

April 4, 2026 · Tim Fraser, Cloud Operations Lead

I Just Got Access to an AWS Account — How Do I Understand What's in It?

Someone has handed you the keys to an AWS account. Maybe you inherited infrastructure at a new job, acquired a product with its AWS account, or a migration just completed and you're now responsible for the result. You need to understand what's running, what it costs, and what's important.

The AWS console is designed for people who already know what they're looking for. When you don't know what's there, it's overwhelming — 80+ services, resources scattered across regions, no map. Here's a systematic approach.

Step 1: Figure out what regions are in use

AWS has 30+ regions, and the console only shows one at a time. Start by figuring out where things live.

Go to EC2 → EC2 Global View to see instances across all regions. Check RDS and S3 (buckets are global but data lives in a specific region). Check Lambda in a few regions — functions are a common place for hidden infrastructure.

If AWS Config is enabled, its resource inventory shows everything across all regions. If not, check manually. Most accounts use 1-3 regions, so once you've found where resources live, ignore the rest.

Step 2: Map the running resources

Start with the expensive stuff — the resources that show up on the bill.

EC2 instances. How many, what sizes, what names? An instance named prod-web-01 is probably important. One named test-dec-2024 might be forgotten. RDS databases. How many instances and clusters? What engines and sizes? Multi-AZ or Single-AZ? Which are production versus dev/test? Load balancers. Check target groups to see what each ALB/NLB routes to. This reveals architecture — which instances sit behind which balancers, how traffic flows. S3 buckets. List all buckets and check sizes (enable Storage Lens if needed). Bucket names often reveal purpose — company-backups versus temp-data-upload-2. Lambda functions. Check invocation metrics to see which functions are active. Functions with EventBridge triggers are often invisible glue — disable one without understanding it and something breaks silently.

Step 3: Understand the network

Go to VPC and map the network.

How many VPCs? Most accounts have 1-3. Check CIDR blocks to understand the IP address space. Subnets. Which are public (route to an Internet Gateway) and private? This tells you what's internet-facing. Security groups. Check inbound and outbound rules. Any group allowing 0.0.0.0/0 means those resources are accessible from the entire internet. NAT Gateways and VPC endpoints. Show how private resources reach the internet and AWS services. Also significant cost drivers.

Step 4: Check the bill

Open Cost Explorer, set the range to 3 months, and group by Service. This immediately shows where the money goes.

Group by Linked Account if this is an Organization — you might find sub-accounts you didn't know existed. Group by Tag if resources are tagged to see cost by project or team.

Note the daily run rate. This is your baseline for detecting anomalies.

Step 5: Identify what's critical

Not everything running is production. Look for clues:

Resources with no tags, no alarms, and no recent activity are candidates for investigation — either undocumented infrastructure or abandoned resources costing money.

Getting the full picture faster

Working through these five steps manually takes a full day. Dozens of console pages, multiple regions, cross-referencing security groups with instances, piecing together an architecture from fragments.

plainfra does this with a single question. Ask "What's running in this account?" and plainfra makes API calls across regions, maps resources, identifies what's active, what's idle, and what's costing the most. Two minutes instead of eight hours.

Follow up with "Are there any security issues?" and "Where are we wasting money?" to go from orientation to action in one sitting.

Try plainfra free → 50K tokens, 7 days, no charge. Or see the interactive demo →.