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

Connect AWS and Azure with read-only access

Deploy one IAM role per AWS account, or a StackSet across your whole Organization. On Azure, a tenant admin grants consent once. There are no agents to install and no access keys to rotate.

Get a demoSecurity & trust
What you're watchinglive product
  1. 1
    Choose AWS Organization

    This option deploys CloudLensReadOnlyRole with a StackSet. The panel lists what the role can do, and write actions read None.

  2. 2
    Discovery finds 14 accounts

    Under lumora-management, CloudLens lists the Production, Staging and Sandbox OUs. All 14 accounts are selected for enrollment.

  3. 3
    The StackSet rolls out

    Stack instances succeed OU by OU with 0 failed. The toast reports 11 of 14 accounts connected and 3 still deploying.

  4. 4
    prod-core is validated

    CloudLens assumes the role with an external ID, finds the CUR 2.0 export and confirms Cost Explorer access.

Who does thisCloud engineer in the management account, with a security reviewer checking the roleWhat you getEvery selected account gets the same read-only role, and each one is validated before CloudLens reads its data.
AWSCloudFormation, StackSets and Organizations
Microsoft AzureAdmin consent, then Bicep, Terraform or Cloud Shell
KubernetesEKS clusters through an access entry
Read-onlyEach role is validated before any data is read

Connecting a new tool to production is a risk decision

What can go wrong during onboarding, and how a read-only role keeps that risk small.

Credentials

Access keys leak

What usually happens: A tool asks for an access key. It gets pasted into a form, stored somewhere, and nobody rotates it for a year.

How CloudLens resolves it: CloudLens assumes a role you created in your own account. There is no long-lived key to store, leak or rotate.

Resolved
Access

Write access is a standing risk

What usually happens: A tool that can change resources is one compromised session away from changing them.

How CloudLens resolves it: The role only has read permissions. Applying a change is a separate, opt-in path with approval, a dry run and rollback.

Resolved
Coverage

Accounts get left out

What usually happens: Onboarding accounts one by one takes weeks, and the account nobody got to is the one with the surprise bill.

How CloudLens resolves it: Connect the Organization once. CloudLens discovers member accounts and enrolls the ones you select in bulk.

Resolved

Two ways in: one account, or the whole Organization

Both deploy the same read-only role. Pick the one that matches how your estate is set up.

Run one CloudFormation template

Download the template, launch it in your own account, and watch CloudFormation create the role. The stack hands back a role ARN, and CloudLens assumes it with an external ID before it reads a single resource.
  • Public template you can read first
  • Launch in your own console
  • Live stack events
  • Role ARN returned by the stack
  • External ID on every assume
What you're watchinglive product
  1. 1
    Read the template first

    The panel lists exactly what cloudlens-readonly.yaml creates: the IAM role, the trusted principal, the external ID, the managed policies, and None under write actions.

  2. 2
    Launch it in your own console

    Download the template or launch it straight into CloudFormation. It runs in your account, under your credentials — CloudLens never holds a key.

  3. 3
    Watch the stack events

    CREATE_IN_PROGRESS on the stack, then the IAM role and its policy, then CREATE_COMPLETE. The same lines you would see in the CloudFormation console.

  4. 4
    The stack returns the role ARN

    The RoleArn output comes back to CloudLens automatically, and the role is assumed with the external ID before any resource is read.

Who does thisCloud engineer connecting a single AWS account, usually their own sandbox or production accountWhat you getOne account is connected in a few minutes, with a role you created, can read, and can delete at any time.

Roll the same role out with a StackSet

For many accounts, CloudLens discovers your AWS Organization and deploys the same read-only role with a CloudFormation StackSet. Enroll by OU, watch stack instances succeed account by account, and let new accounts in those OUs enroll themselves.
  • Organization discovery
  • Enroll by OU
  • StackSet across member accounts
  • Per-account progress
  • New accounts auto-enrolled
What you're watchinglive product
  1. 1
    See what gets created

    Before anything deploys, the panel shows the IAM role, its read-only permissions, trust through an external ID, and no write actions.

  2. 2
    Enroll by OU

    Selecting Production, Staging and Sandbox targets 14 member accounts. Accounts added to those OUs later are enrolled automatically.

  3. 3
    Watch deployment and checks

    StackSet progress fills per OU while prod-core passes the role, CUR 2.0 and Cost Explorer checks. No write permissions are requested.

Who does thisPlatform lead onboarding an AWS Organization, with the security team approving the roleWhat you getFourteen accounts are enrolled from one screen, and each is checked before it counts as connected.

One admin consent, then reader roles only

Azure onboarding is a different shape to AWS: consent once at the tenant, then assign reader roles per subscription.

One admin consent, reader roles only

A tenant admin grants consent once and CloudLens gets a service principal. You pick the subscriptions and assign reader roles with Bicep, Terraform or a Cloud Shell script. Then create a Cost Management export, reuse one you already have, or skip it for now.
  • One admin consent for the tenant
  • Service principal, then pick subscriptions
  • Bicep, Terraform or Bash
  • Cost Management Reader
  • Storage Blob Data Reader
What you're watchinglive product
  1. 1
    Tenant admin grants consent

    Sign in with Microsoft lists three permissions: sign-in and profile, resource inventory as Reader, and cost data. The admin accepts.

  2. 2
    Choose subscriptions

    The lumoraretail.onmicrosoft.com tenant connects and the cloudlens-reader service principal is created. Then lumora-prod, lumora-data and lumora-dev are selected.

  3. 3
    Assign reader roles as code

    The Bicep command and the Terraform module grant Cost Management Reader and Storage Blob Data Reader on those subscriptions.

  4. 4
    Set up the cost export

    Create new export is chosen. CloudLens confirms the storage account is reachable, role assignments are verified and a daily export is scheduled.

Who does thisAzure tenant admin granting consent, with a cloud engineer running the TerraformWhat you getThree subscriptions connect with reader roles only, and daily cost data starts arriving from the export.

Fourteen AWS accounts and one Azure tenant

Lumora Retail runs most of its workloads on AWS under one Organization, plus two Azure subscriptions for the loyalty platform. This is how the whole estate was connected in a day.

OHOmar HaddadCloud engineer, Lumora Retail

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

    1
    Mon 10:00

    Chooses the Organization option

    Omar signs in to the AWS management account and picks Organization instead of a single account, because all 14 accounts sit under it.
    2
    Mon 10:08CloudFormation

    Deploys the StackSet

    He launches the CloudFormation StackSet from the link CloudLens provides. It creates the read-only role in the member accounts.
    3
    Mon 10:2614 validated

    Selects accounts and validates

    CloudLens discovers the Organization and lists all 14 accounts. Omar selects them, and CloudLens validates the role in each one before reading any data.
    4
    Mon 14:00Azure

    Connects Azure

    The Azure tenant admin grants consent. Omar picks the two loyalty subscriptions, assigns reader roles with the Terraform snippet, and reuses the Cost Management export finance already had.
    5
    Tue 09:00

    Checks what CloudLens can see

    Cost Explorer shows spend across the 14 accounts and both subscriptions. Atlas lists which security checks can run and names the one extra permission a check still needs.
One AWS account or a whole Organization?

Connect read-only in about 15 minutes

Get a demo

What CloudLens reads, and nothing more

The bill

AWS CUR 2.0 and Azure Cost Management exports, amortized, with Savings Plans and Reserved Instances accounted for.

The estate

Resource inventory and configuration, read through describe and list APIs and Azure Resource Graph.

Identity and network

IAM policies, security groups and routes. These are the connections attack paths are built from.

What we can't see

If a permission is missing, CloudLens names the checks that can't run. An empty list is never presented as a clean account.

AWS
  1. Choose a single account or your Organization
  2. Deploy the CloudFormation template or StackSet
  3. Discover and select member accounts
  4. Provision member roles and validate them
Azure
  1. Grant admin consent
  2. Select the subscriptions to connect
  3. Assign reader roles with Bicep, Terraform or Bash
  4. Create, reuse or skip a Cost Management export
Kubernetes
  1. Connect the AWS account that runs EKS
  2. Add a CloudLens access entry to the cluster
  3. Workloads appear in the security graph
  4. CIS Kubernetes checks start scoring

Connection FAQ

No. Seeing your cloud only needs read access. Applying a change is a separate, opt-in flow through Savings Proposals, with approval, a dry run and rollback.

Use the StackSet option. CloudLens discovers the Organization, provisions the member role in each account you select and validates them in bulk.

Yes. You can reuse an existing export, create a new one, or skip exports and add one later.

Ready to see CloudLens in action?

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.