DEV Community: Maksim Bolgarin

Why You Can't Get a Full AWS Resource Inventory from the Console

Maksim Bolgarin — Tue, 31 Mar 2026 10:30:55 +0000

AWS has no single screen that shows everything in your account. Here's why building a complete resource inventory is harder than it should be, and what actually works.

There's a question that sounds simple until you actually try to answer it: what's running in my AWS account right now?

You'd think AWS would have a page for this. One screen, all your resources, every region. It doesn't. And the workarounds range from "almost good enough" to "I'll write a script and regret it later."

I've spent a lot of time on this problem, both managing AWS accounts professionally and building a tool that does inventory discovery automatically. The short version: it's genuinely harder than it should be.

The Console Wants You to Already Know What You're Looking For

Open the AWS Console. You get a search bar and a list of services. That's it.

Want to see your EC2 instances? Go to the EC2 page. Your RDS databases? Different page. S3 buckets? Different page again. Lambda functions, IAM roles, EBS volumes, security groups, load balancers, KMS keys — each one lives in its own section of the console with its own layout, its own filters, and its own quirks.

There are over 200 AWS services. Even if you only use 10 or 15 of them, checking each one manually means opening a dozen tabs and clicking through region selectors. And here's the part that gets people: most of these pages only show resources in one region at a time. If you're looking at EC2 instances in eu-west-1, you won't see the instance someone spun up in us-east-1 three months ago for a quick test and forgot about.

This is fine when you know exactly what you're looking for. It falls apart when the question is "what do we have?"

Multi-Region Is Where It Gets Painful

AWS operates in 30+ regions. Most teams use two or three. But resources end up in unexpected places all the time.

Someone creates a CloudFormation stack in us-east-1 because that's the default. A developer launches a test instance in ap-southeast-1 to check latency from Singapore. An old deployment left behind snapshots in eu-central-1 that nobody remembers creating.

The AWS Console doesn't help here. There's no "show me resources across all regions" toggle on most service pages. You have to manually switch regions in the top-right dropdown and check each one. For a single service. Then repeat for the next service.

If you're responsible for security or compliance — especially GDPR, where data residency matters — this is a real problem. Resources in the wrong region aren't just clutter. They can be a compliance violation you don't know about until an auditor asks.

The Tools AWS Gives You (And Why They're Not Enough)

AWS isn't completely unaware of this problem. There are a few built-in options.

AWS Resource Explorer is the closest thing to a unified inventory. You enable it, it indexes your resources across regions, and you can search them in one place. It's better than clicking through service pages manually. But it doesn't cover every resource type, it doesn't show cost data, and the search interface works best when you already know what you're looking for. It's a search engine, not an inventory report. If you want to browse everything and understand the full picture, it's not quite there.

AWS Tag Editor lets you find resources across regions, but only if they're tagged. If your team has inconsistent tagging (and most teams do), you'll get a partial view at best. Untagged resources are invisible here, which is a problem because untagged resources are usually the ones you need to find the most — they're the forgotten ones.

AWS Config is the most thorough option — it records resource configurations and tracks changes over time. The catch: it's a compliance and audit tool, not something you'd use as a daily inventory dashboard. Setting it up across all regions takes real effort, it bills per recorded configuration item, and the output is dense enough that you'll probably need another tool to make sense of it.

AWS Cost Explorer shows you what's costing money, which is useful, but it groups costs by service and region, not by individual resource. You can see that EBS is costing you $340/month in eu-west-1, but you can't easily see which specific volumes are responsible.

You can cobble these together and get a partial answer. But none of them give you a single view that says: here's every resource in your account, across every region, with its cost, its security posture, and whether anyone is actually using it.

The CLI Approach Works but Doesn't Scale

The most common DIY solution is writing AWS CLI scripts. Something like:

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "=== $region ==="
  aws ec2 describe-instances --region $region --query 'Reservations[].Instances[].[InstanceId,State.Name,InstanceType]' --output table
done

This works for one service. Now multiply it by every service you use. EC2 instances, EBS volumes, RDS databases, S3 buckets, Lambda functions, IAM users, security groups, snapshots, Elastic IPs, NAT Gateways, load balancers, KMS keys, CloudWatch log groups...

Each service has its own API call, its own response format, its own pagination logic. Some resources are global (like IAM and S3 buckets), some are regional. The script grows, the edge cases pile up, and eventually you're maintaining a mini infrastructure scanner that you never intended to build.

I've seen teams keep these scripts around for years. They break when AWS adds new regions or changes API responses. Nobody wants to maintain them. And they still don't give you cost estimates or security analysis — just a list of resource IDs.

What You Actually Need

When I talk to engineers about this, the thing they want is simple: one view, everything in the account, across all regions, with enough context to make decisions.

That means seeing every resource with its type, region, state, tags, and estimated monthly cost. It means knowing which resources are orphaned (not attached to anything), which ones have security issues, and which ones are in regions they shouldn't be in.

The AWS Console was built for operating individual services, not for answering "what's in my account." The tools AWS provides are useful for specific tasks — searching, auditing, cost analysis — but they don't combine into a single inventory view without significant effort.

This is why I built ScanOrbit. It connects through a read-only IAM role, scans all regions in one pass, and gives you a full inventory with cost estimates, security findings, and compliance checks. No agents, no scripts to babysit, no clicking through region dropdowns for an hour.

The free scan shows you how many resources and findings you have, so you can see the scope of the problem before committing to anything.

Start With the Manual Check

Even if you don't use any tooling, there's a quick sanity check worth doing right now.

Go to the AWS Console, open Resource Explorer (if it's enabled), and search for * in each region. Look for resources in regions you didn't expect. Then check EC2 → Volumes and filter by "Available" status — those are unattached volumes costing you money right now. Check Elastic IPs for any that aren't associated with a running instance. Check Security Groups for any that aren't attached to anything.

You'll probably find something. Most accounts do.

This article is part of our series on AWS infrastructure visibility. Previously: How to Find and Fix Open Security Groups in AWS and How to Find Orphaned EBS Volumes in AWS.

How to Find and Fix Open Security Groups in AWS

Maksim Bolgarin — Tue, 17 Mar 2026 08:01:43 +0000

Open security groups are among the most common AWS security misconfigurations found in production environments. A single inbound rule allowing 0.0.0.0/0 on port 22 exposes your EC2 instances to every scanner and brute-force bot on the internet. It happens gradually — an engineer opens SSH access for a quick debugging session and forgets to close it. A staging environment gets a permissive rule that's never tightened. Multiply that across dozens of instances and multiple AWS regions, and you have a serious attack surface hiding in plain sight.

This guide shows you how to find and fix open security groups in AWS using both the Console and CLI — and how to automate the process so nothing slips through.

Why Open Security Groups Are a Real Threat

An AWS security group acts as a virtual firewall for your EC2 instances. Each inbound rule specifies which traffic is allowed to reach your instance. When the source is set to 0.0.0.0/0, it means every IP address on the internet can reach that port.

Automated scanners like Shodan and Censys index newly exposed services within minutes. If you open port 22 to the world at 2pm, brute-force attempts will start by 2:15pm. This isn't theoretical — it's measurable.

The Most Dangerous Open Ports

Not all open ports carry the same risk. These are the ones that should never be exposed to 0.0.0.0/0:

Port 22 (SSH) — the primary target for credential brute-forcing and the most common entry point for lateral movement
Port 3389 (RDP) — Windows Remote Desktop, a favorite delivery vector for ransomware
Port 3306 (MySQL) / 5432 (PostgreSQL) — direct database access means direct data exfiltration
Port 27017 (MongoDB) — default MongoDB port, frequently found exposed with no authentication
Port 0–65535 (all traffic) — the worst case, sometimes set accidentally when engineers copy rules between environments

Ports 80 and 443 are often intentionally public for web servers, but even these deserve a review to confirm the exposure is deliberate.

How to Find Open Security Groups in the AWS Console

The AWS Console provides a visual way to inspect security groups, though it requires manual effort across regions.

Using the VPC Console

Sign in to the AWS Console and navigate to VPC (search "VPC" in the top bar)
In the left sidebar, click Security Groups under the "Security" section
Click any security group to open its detail panel
Select the Inbound rules tab
Look for rules where the Source column shows 0.0.0.0/0 or ::/0
Flag any rule where that open source is paired with ports 22, 3389, 3306, 5432, or a wide port range

The Cross-Region Problem

Here's where it gets tedious. The AWS Console shows security groups for one region at a time. If your organization uses 5 regions and has 40 security groups per region, you need to manually inspect 200 security groups — switching regions each time using the dropdown in the top-right corner.

There is no built-in cross-region view for security groups in the AWS Console. If you've ever done this manually, you know how easy it is to skip a region or miss a rule.

How to Find Open Security Groups Using the AWS CLI

The CLI is significantly faster than clicking through the Console. You can query security groups programmatically and even loop across all regions.

List All Security Groups with 0.0.0.0/0 Inbound Rules

aws ec2 describe-security-groups \
  --query "SecurityGroups[?IpPermissions[?IpRanges[?CidrIp=='0.0.0.0/0']]].{ID:GroupId,Name:GroupName}" \
  --output table

This JMESPath query filters for any security group with at least one inbound rule sourced from 0.0.0.0/0 and returns a clean table with the group ID and name.

Check for Port 22 Open to the Internet

aws ec2 describe-security-groups \
  --filters "Name=ip-permission.cidr,Values=0.0.0.0/0" \
            "Name=ip-permission.from-port,Values=22" \
            "Name=ip-permission.to-port,Values=22" \
  --query "SecurityGroups[*].{ID:GroupId,Name:GroupName}" \
  --output table

Scan Across All AWS Regions

for region in $(aws ec2 describe-regions --query "Regions[*].RegionName" --output text); do
  echo "--- $region ---"
  aws ec2 describe-security-groups \
    --region "$region" \
    --filters "Name=ip-permission.cidr,Values=0.0.0.0/0" \
    --query "SecurityGroups[*].{ID:GroupId,Name:GroupName}" \
    --output table 2>/dev/null
done

This loop hits every AWS region. Expect it to take 30–60 seconds. If you use multiple AWS accounts, you'll need to repeat this with assumed roles for each account — or script that too.

At this point, the overhead should be clear. You're writing scripts to do what should be a single button click. And scripts don't run themselves — someone has to remember to execute them regularly.

ScanOrbit detects permissive security groups across all your AWS regions and accounts automatically — no scripts, no region-switching. Run a free scan and get a complete report in minutes.

How to Fix Permissive Security Group Rules

Finding the open rules is half the problem. Here's how to fix them.

Replace 0.0.0.0/0 with a Specific CIDR Block

If only your office or VPN needs SSH access, restrict the source to that IP range:

# Remove the open rule
aws ec2 revoke-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0

# Add a restricted rule
aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 22 \
  --cidr 203.0.113.0/24

Replace 203.0.113.0/24 with your actual office or VPN CIDR range.

Use Security Group References for Internal Traffic

Instead of CIDR blocks, reference another security group as the source. This is the right pattern for service-to-service communication — for example, allowing your application tier to reach the database:

aws ec2 authorize-security-group-ingress \
  --group-id sg-database \
  --protocol tcp \
  --port 5432 \
  --source-group sg-application

This way, only instances in the sg-application security group can reach the database. No IP addresses to manage.

Use SSM Session Manager Instead of SSH

For EC2 access, consider replacing SSH entirely with AWS Systems Manager Session Manager. SSM routes traffic through the AWS service — no inbound ports required. This eliminates the need for bastion hosts and removes port 22 from the equation.

Remediation Checklist

Restrict sources immediately — replace every 0.0.0.0/0 rule on sensitive ports with specific CIDR ranges or security group references
Enforce with SCPs — use AWS Organizations Service Control Policies to prevent rules allowing 0.0.0.0/0 on ports 22 and 3389 from being created
Enable AWS Config rules — the managed rule restricted-ssh flags any security group with port 22 open to the internet; set it to auto-remediate
Tag your security groups — clear naming and tagging makes it easy to identify which groups belong to which workload
Review in code — treat security group changes as part of your infrastructure-as-code review process, not an afterthought

Automating Security Group Audits at Scale

The fundamental problem with point-in-time audits — whether you use the Console or CLI — is that they go stale immediately. A developer adds a 0.0.0.0/0 rule at 11pm for a quick test. Your next manual audit is scheduled for next Tuesday. That's a week of exposure.

As we covered in why AWS infrastructure scanning matters, the real value of automated scanning isn't a single report — it's continuous coverage. The same applies to finding orphaned resources and every other hygiene check. Automation turns a periodic audit into a persistent safety net.

What to look for in an automated scanner:

Cross-region coverage — checks every region, not just the ones you remember to select
Cross-account support — organizations with multiple accounts need a single view
Agentless architecture — no agents to install, no Lambda functions to manage, no additional attack surface
Actionable findings — not just "this rule exists" but what it affects and how to fix it

ScanOrbit uses a read-only IAM role to scan your entire AWS environment and surfaces permissive security group rules alongside other findings like expiring SSL certificates, data residency violations, and cost waste. Because it's agentless and hosted in the EU, there's no operational overhead and no new attack surface.

The steps in this guide will find open security groups in your AWS account today. But staying on top of them over time — as your team grows, new rules get added, and old ones go unreviewed — requires automation.

ScanOrbit detects permissive security groups across all regions automatically. Try a free scan and see what's exposed in your account right now.