April 4, 2026 · Tim Fraser, Cloud Operations Lead

I Inherited an AWS Account — Where Do I Start?

Someone left. Or someone got promoted. Or the company grew and suddenly "the AWS stuff" needs an owner. And now it's you.

You're a capable developer. You can write code, deploy applications, maybe even set up a CI/CD pipeline. But managing an AWS account — understanding what's running, what it costs, whether it's secure — that's a different skill set. And nobody gave you a handover document.

Most small companies end up here at some point. Here's a practical, prioritised guide to getting your bearings.

Week 1: Understand what exists

Before you change anything, you need to know what you're working with.

Get the bill

Go to AWS Console → Billing → Bills. Look at the current month and the previous 3 months. This tells you:

• How much the account costs (and whether it's trending up or down)
• Which services are costing the most
• Whether there are any obvious anomalies

Write down the top 5 services by cost. These are where you'll spend most of your time.

Map the running resources

For each of the major services, go to the console and take inventory:

• EC2: How many instances are running? What sizes? Do they have meaningful names/tags?
• RDS: Any databases? What engines? Are they Multi-AZ?
• S3: How many buckets? Which ones have data in them?
• Lambda: Any functions? How often do they run?
• ECS/EKS: Any container services running?
• Load Balancers: Any ALBs/NLBs? What are they fronting?

Don't try to understand everything on day one. The goal is a rough inventory — "we have 8 EC2 instances, 2 RDS databases, 15 S3 buckets, and an ALB."

Check the regions

AWS resources can exist in any region. The console defaults to one region, so you might be looking at an empty account when there are 20 instances running in us-east-1. Check at least: ap-southeast-2, us-east-1, us-west-2, eu-west-1 — these are the most commonly used.

The AWS Resource Explorer service (if enabled) can help here — it shows resources across all regions in one view.

Check who has access

Go to IAM → Users. Who has console access? Who has programmatic access? Are there any users with AdministratorAccess that you don't recognise?

Also check IAM → Roles. Are there cross-account roles? Third-party integrations?

This isn't about fixing anything yet — it's about knowing who can do what.

Week 2: Assess security

Now that you know what exists, check whether it's secure.

Enable CloudTrail (if it isn't already)

Go to CloudTrail → Trails. If there's no trail configured, create one. CloudTrail records every API call in the account — it's your audit log and your investigation tool. Without it, you're flying blind.

Check for public resources

• S3 buckets: Look for the "Public" badge in the S3 console
• Security groups: Look for inbound rules with 0.0.0.0/0 on sensitive ports (22, 3306, 5432, 3389)
• RDS: Check if any databases have "Publicly accessible" set to Yes

Enable MFA on the root account

Go to IAM → Dashboard. If the root account doesn't have MFA enabled, this is your highest priority. The root account has unrestricted access to everything and cannot be limited by IAM policies.

Check for access keys on the root account

Root access keys are a critical security risk. Go to Security Credentials (while logged in as root) and delete any active access keys.

Week 3: Set up monitoring

Create a billing alarm

Go to CloudWatch → Alarms → Billing. Set an alarm that triggers when your monthly bill exceeds your normal spend by 20%. This is your early warning system.

Enable AWS Config (if budget allows)

AWS Config tracks configuration changes to your resources. It's how you find out that someone modified a security group last Tuesday. It has a cost, so check pricing first — but for production accounts, it's worth it.

Set up basic CloudWatch alarms

For your most important resources, set up alarms for:

• EC2 CPU utilisation > 90%
• RDS storage space < 20%
• RDS CPU > 80%
• Any ALB 5xx error rate > 5%

Week 4: Start improving

Now that you have visibility, start making changes:

• Terminate or stop any obviously unused resources
• Restrict overly permissive security groups
• Add Name tags to untagged resources
• Document what you've learned (a simple doc with "what runs where and why" is invaluable)
• Set up a regular review cadence — even 30 minutes a week looking at the bill and CloudWatch will prevent most surprises

The shortcut

Everything above takes about a month of part-time work. If you want to shortcut weeks 1-3 into an afternoon, that's exactly what plainfra is built for.

Connect your AWS account (read-only — one CloudShell command, takes 3 minutes) and start asking questions:

> "What's running in this account and what does it cost?"

"Are there any security issues I should know about?"

"Which resources are unused?"

plainfra makes live read-only API calls to your account and gives you the answers directly. No scripts to write, no console tabs to juggle, no need to know which AWS service does what.

The biggest difference for someone new to AWS operations is the weekly health report.

Every week, plainfra runs a comprehensive scan across all your connected AWS accounts and emails you a PDF report. It flags security exposures, cost anomalies, configuration drift, and operational risks — prioritised by impact. If you manage multiple AWS accounts, the report covers all of them.

It's like having a senior DevOps engineer review your infrastructure every Monday and hand you a to-do list. You don't need to know what to check — plainfra checks everything and tells you what matters.

And it stays connected. When something changes — a new public security group, a cost spike, an expiring certificate — it shows up in next week's report. You're not doing a one-time audit and hoping nothing breaks. You get ongoing monitoring without the ongoing work.

That's worth a lot when you've got an AWS account you didn't ask for and a day job that isn't "manage AWS."