New Savings Proposals: approve, test and roll back cost changesLearn more Sign in|Talk to a cloud engineer

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.

What you're watching
  1. 1
    Open 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.

  2. 2
    Read 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.

  3. 3
    Redraw 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.

Who does thisPlatform lead or cloud security engineer, usually with the owning service teamWhat you getOne picture of everything checkout-api touches, drawn from a scan finished 14 minutes earlier.
Open findings
0
each pinned to the resource it's on
Internet-reachable
0
findings on resources the internet can reach
Attack paths
0
chains that end at sensitive data
Accounts
0
rolled up, unread accounts ranked last

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.

Visibility

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.

Resolved
Coverage

Gaps 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.

Resolved
Security

Context 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.

Resolved

How the platform team uses the graph

Priya owns the platform for about 40 engineers. This is one ordinary week.

PNPriya NairPlatform lead, Lumora Retail

Lumora Retail is a fictional company. The people, names and numbers are sample data.

    1
    Mon 09:30

    Picks the Traffic lens for checkout

    She starts from the public checkout hostname instead of the account. The view drops to the services a checkout request actually touches: checkout-lb, checkout-api, orders-db and the task role.
    2
    Mon 10:052 findings

    Opens checkout-api

    The drawer shows the subnet and VPC it runs in, the security groups in front of it, and that it runs as checkout-task-role. Two findings are already pinned to it.
    3
    Tue 14:20Not assessed

    Finds a coverage gap in staging

    Staging shows Lambda as locked. The page names the missing read permission, so she adds it to the StackSet that deploys the scan role.
    4
    Wed 08:00

    The next scan reads it

    Staging's freshness badge turns current and three Lambda findings appear. Nobody reads the higher count as a regression, because the gap was visible on Tuesday.
    5
    Thu 16:40

    Exports a diagram for design review

    The Blueprint PNG goes into the review doc for the payments split. It matches production because it was drawn from that morning's scan.
Want this map of your own AWS estate?

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.

A change becomes a ranked finding on the next scan

See toxic combinations
When someone opens a port, Atlas picks it up on the next scan, works out what it now reaches, ranks it, and opens the ticket for the owning team. When the fix lands, the following scan confirms it and the finding resolves with its history kept. Scan intervals come from your scan policy.
  • Detected on each scan
  • Path, rank and ticket in minutes
  • Resolved only when the risk is gone
What you're watching
  1. 1
    The 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.

  2. 2
    Ranked 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.

  3. 3
    Fixed, 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.

Who does thisCloud security engineer on call, with the owning team's engineering leadWhat you getDetection, ticket and verified fix on one timeline, from 14:02 to 16:05 in this example.

Choose the question before the graph draws

See the architecture views
Traffic groups resources by how requests arrive and marks what the internet can reach. Apps follows your application tags. Types, Networks and Services cover the platform team's questions. Switching lenses regroups the same resources instead of starting a new diagram.
  • Traffic: zones and internet exposure
  • Apps: by application tag
  • Types, Networks, Services
What you're watching
  1. 1
    Start in the Traffic lens

    Resources split into front doors, what sits behind them, and data. checkout-cdn and checkout-lb carry Internet-exposed flags.

  2. 2
    Regroup by app, then by type

    The same tiles slide into app: checkout, app: media and app: support, then into networking, compute, identity and data.

  3. 3
    Finish 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.

Who does thisSecurity engineer and platform lead, in a design or incident reviewWhat you getFive groupings of the same eight resources, so each team answers its own question from one scan.

See exactly what the scan couldn't read

Each account lists the services Atlas reads fully, partly or not at all, with the permission that would close the gap. Freshness is tracked per pipeline stage and the badge shows the oldest one, so a green dot can't hide a detector that hasn't run since last week.
  • Coverage per service
  • Freshness shows the oldest stage
  • Locked checks count as not assessed
What you're watching
  1. 1
    Check 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.

  2. 2
    Read 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.

  3. 3
    Open 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.

Who does thisCloud security engineer, with whoever maintains the scan role StackSetWhat you getA named list of permissions to grant, so a quiet account is never mistaken for a clean one.

Rank accounts by certainty, then severity

See compliance scorecards
Every account has a state: Current, Partly read, Out of date or Never scanned. Sort by fewest findings and an account Atlas has never read stays at the bottom. Zero findings from an account nobody can see is not good news.
  • Current, Partly read, Out of date, Never scanned
  • AWS Organizations and StackSets
  • Stale data flagged on the score
What you're watching
  1. 1
    See 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.

  2. 2
    Sort by cleanest first

    sandbox and staging rise on their scores, each labelled stale or partial. The caveat stays attached to the number.

  3. 3
    payments-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.

Who does thisHead of security or cloud security lead reviewing the AWS OrganizationWhat you getAn account ranking where the unscanned acquisition sits last and flagged, never at the top.

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.

Graph Blueprint Lanes Export PNG / SVG

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.