See every resource and what it can reach
Atlas builds a graph of your AWS estate from a read-only scan: accounts, VPCs, workloads, roles, data stores and the connections between them. When the scan can't read something, the page tells you.
- 1Open checkout-api on the graph
The drawer shows its region, the team: checkout owner tag and where it lives: prod-core, prod-vpc, private-a. Two critical findings and one high are pinned to it.
- 2Read what it connects to
It sits behind checkout-lb, runs as checkout-task-role and reaches orders-db and support-tickets. Those edges decide what a compromise of this service exposes.
- 3Redraw as Blueprint, then Lanes
The same tiles move into Edge, Compute and Identity & data boxes, then into Internet-facing, Private and Data lanes. The scan behind them stays the same.
Findings without context all look urgent
A public bucket matters when it holds customer data and a role can reach it. The graph supplies that context.
Nobody has the current picture
What usually happens: The diagram in the wiki is from last year's migration. New services show up in the bill before anyone draws them.
How CloudLens resolves it: The graph is rebuilt from each scan, so a service that exists in the account exists on the map.
ResolvedGaps look like a clean account
What usually happens: A scanner without permission to read Lambda reports zero Lambda findings, and the dashboard turns green.
How CloudLens resolves it: Atlas lists the services it couldn't read and the permission it needs. Those checks count as not assessed.
ResolvedContext decides priority
What usually happens: An open security group on a dev box and one in front of checkout-api look identical in a spreadsheet.
How CloudLens resolves it: Each finding sits on its resource next to its neighbours, so you can see what it actually exposes.
ResolvedHow the platform team uses the graph
Priya owns the platform for about 40 engineers. This is one ordinary week.
Lumora Retail is a fictional company. The people, names and numbers are sample data.
Picks the Traffic lens for checkout
Opens checkout-api
Finds a coverage gap in staging
The next scan reads it
Exports a diagram for design review
See what can reach what in your accounts
Three views, one set of resources
Graph, Blueprint and Lanes all draw from the same scan. You choose the scope first, so the picture answers the question you came with.
- Detected on each scan
- Path, rank and ticket in minutes
- Resolved only when the risk is gone
- 1The scan sees port 22 open
At 14:02 a security group rule opens port 22 on checkout-api to 0.0.0.0/0. Atlas computes the path from there to customer-exports.
- 2Ranked Critical and ticketed
An open port and an administrator role on one workload make a toxic combination. SEC-77 is created for Checkout with the path and fix steps.
- 3Fixed, rescanned, resolved
Priya limits port 22 to bastion-sg at 15:40. The 16:05 scan still sees the resource, confirms the risk is gone and resolves the finding.
- Traffic: zones and internet exposure
- Apps: by application tag
- Types, Networks, Services
- 1Start in the Traffic lens
Resources split into front doors, what sits behind them, and data. checkout-cdn and checkout-lb carry Internet-exposed flags.
- 2Regroup by app, then by type
The same tiles slide into app: checkout, app: media and app: support, then into networking, compute, identity and data.
- 3Finish with Networks and Services
Networks shows what sits in prod-vpc and what is regional with no VPC. Services groups the eight resources by AWS service.
See exactly what the scan couldn't read
- Coverage per service
- Freshness shows the oldest stage
- Locked checks count as not assessed
- 1Check what prod-core lets Atlas read
Five services read in full. EKS is partly read because there is no EKS access entry, and Amazon Inspector access is not granted.
- 2Read freshness by the oldest stage
Discovery ran 12 minutes ago, detectors 16. The badge says 16, so a recent discovery run can't hide stale detection.
- 3Open the three missing permissions
inspector2:ListFindings and two EKS access-entry permissions are listed. Until they are granted, those checks count as Not assessed and never as passed.
- Current, Partly read, Out of date, Never scanned
- AWS Organizations and StackSets
- Stale data flagged on the score
- 1See each account's read state
prod-core and prod-data are Current. staging is Partly read because EKS wasn't read, sandbox is 3 days old, and payments-acq was never scanned.
- 2Sort by cleanest first
sandbox and staging rise on their scores, each labelled stale or partial. The caveat stays attached to the number.
- 3payments-acq stays at the bottom
An account Atlas has never read has no score and can't rank. Zero findings from it means no data.
Click a resource to see its whole context
Resource drawer
Metadata, where it sits (account, VPC, subnet) and every relation in and out.
REACHES edges
Derived from security-group rules, so reachability comes from configuration you can verify.
Findings on the node
Severity, toxic combinations and data classes appear on the resource they describe.
Read-only scan
Built from describe and list calls through a read-only role. Drawing the graph changes nothing.
Questions security teams ask
No. Atlas reads through a read-only IAM role deployed with CloudFormation, or with a StackSet across an AWS Organization. Building the graph doesn't change any resource.
Discovery, graph build and detectors run on a schedule, and each stage records when it last ran for each account. The page shows the oldest of those times.
Checks that depend on it are listed as not running, along with the permission to grant. They count as not assessed in findings and in compliance scores.
For EKS, yes. With an EKS access entry, Atlas reads workloads and flags issues such as privileged containers, containers running as root and public load balancers in front of internal services.
See your own estate as a graph
Connect a read-only AWS role or Azure service principal. We'll walk you through your bill, your security graph and the first things worth fixing.
