Skip to main content

FAQs

Only Admin users in your organization can connect AWS, remove an integration, or use Manage on an existing integration. Members cannot. See Users and roles.
nOps reads Legacy CUR files that AWS delivers to Amazon S3. You configure the export in the AWS Billing console and tell nOps the bucket name, export name, and optional S3 prefix so ingestion can find your data.
Yes. You can bring your own Legacy CUR instead of creating a new export, as long as it meets nOps CUR requirements. In Step 2, enter your existing export name and the S3 bucket (and prefix) where AWS already delivers it. The suggested name nops_cur_{your_nops_client_id}_hourly is only for teams that choose to create a new export in AWS.
nOps may fail to ingest data, show incomplete cost visibility, or miss resource-level detail. Update the export in Billing > Data Exports to match the requirements checklist, or create a separate Legacy CUR export that does and point nOps at that bucket and export name.
No. This flow connects billing and cost visibility (CUR + integration IAM role). Commitment Management is optional and uses separate CloudFormation templates and roles. After this integration is active, Admins/Owners can start CM from the AWS integration card (Enable CM). See AWS Commitment Management setup.
Yes. AWS CUR 2.0 — also called a standard data export or BCM Data Exports — is an optional add-on to an existing AWS integration, not a separate integration or a replacement for your Legacy CUR. Complete the normal AWS setup below first (it always requires a Legacy CUR export), then enable the CUR 2.0 add-on from Manage on the AWS integration card and enter the export’s S3 bucket, path prefix, and export name — or leave them blank and nOps will discover the export automatically via the AWS Billing Data Exports API, provided your integration role has the standard nOps platform permissions (already granted by both permission levels). CUR 2.0 ingest status is tracked separately from your Legacy CUR’s, so an issue with the add-on never affects your primary integration’s health.
Yes. Step 3: IAM Policy Creation defaults to a one-click Deploy Integration Stack (CloudFormation) option: enter an S3 bucket name, choose a permission level, and click the button to launch AWS CloudFormation with the template pre-filled. The stack creates a new S3 bucket with the name you entered, the Legacy CUR export, the customer-managed IAM policies for your selected permission level, and the cross-account role. Copy the RoleArn output back into nOps to finish. If you’d rather create the policies and role yourself, click Switch to manual setup to follow the step-by-step JSON instructions below.Two things to know before you deploy:
  • The bucket name must not already exist in your account. The stack creates it, so a name that is already taken fails the deployment. If you already have a CUR bucket, see the next question.
  • Deploy in us-east-1. The nOps link opens CloudFormation in us-east-1 for you — don’t change the region. AWS only offers the Legacy CUR resource type there, and deploying elsewhere fails with Unrecognized resource types: [AWS::CUR::ReportDefinition].
Yes, with one extra step. In the CloudFormation console, set the CreateCurBucket parameter to false and enter your existing bucket name.When you do this, nOps does not touch your bucket’s policy. A bucket policy is a single document, so writing one would replace everything already on your bucket — we’d rather leave your permissions alone. That means your bucket must already let AWS billing deliver the report: s3:GetBucketAcl, s3:GetBucketPolicy, and s3:PutObject for the billingreports.amazonaws.com service. Buckets that already receive a CUR normally have this. If yours doesn’t, AWS fails the export with “Failed to verify customer bucket permission” — add the grant and redeploy.The stack’s CurBucketPolicyManaged output tells you which happened: true means nOps created the bucket and its delivery policy, false means the bucket is yours to grant.
In Step 3: IAM Policy Creation, choose a permission level before copying policy JSON:
  • Minimum Platform (nOpsMinimumPlatformPermissions) — Savings Analysis: read-focused access for CUR ingestion, Cost Explorer commitment visibility, and organization metadata. Use this when you only need cost and savings insights.
  • Full Platform (nOpsFullPlatformPermissions) — Inform & Operate: includes all Minimum Platform permissions plus additional read and write actions for broader inventory, recommendations, and operational workflows. Full Platform also attaches the AWS-managed ReadOnlyAccess policy and a customer-managed Deny policy.
Minimum Platform uses two customer-managed policies (nOpsBucketPolicy + nOpsMinimumPlatformPermissions). Full Platform uses four customer-managed policies (nOpsBucketPolicy, nOpsFullPlatformDenyList1, nOpsFullPlatformDenyList2, nOpsFullPlatformPermissions) plus the AWS-managed ReadOnlyAccess policy. See Permissions & Resources for the full breakdown.
This is an AWS account setting, not a problem with your policies — AWS blocks Cost Explorer API calls until the account is opted in, so redeploying the stack won’t clear it. Follow Turn on Cost Explorer in your payer account, then re-run Check. The rest of your integration keeps working in the meantime.

Overview

You’re setting up savings analysis for AWS—linking your organization’s billing data to nOps so we can help you understand costs and find ways to save. The in-app wizard walks you through it. Open Connect Amazon Web Services from Settings > Cloud Provider Integrations. You’ll complete three steps:
  1. Account — Payer account ID, integration name, optional AWS Organization ID
  2. CUR Export Configuration — Legacy CUR in Billing > Data Exports (new export or bring your own); you enter bucket, export name, and path in nOps
  3. IAM Policy Creation — Choose Minimum or Full Platform permissions, create customer-managed policies, cross-account role with external ID, Role ARN submission
For AWS documentation on creating the export, see Creating a Legacy CUR export.
Who can do this: Only Admin users in your nOps organization can connect or manage AWS integrations. Members cannot. See Users and roles. Backend APIs enforce the same restriction.

Prerequisites

Before you start, make sure you can:
  • Use the payer (management) account (or have someone available who can) for AWS Billing and IAM
  • Create or use an S3 bucket where the Legacy CUR is (or will be) delivered — including an existing export you bring yourself, if it meets the requirements
  • Create IAM policies and a cross-account IAM role in your account
  • Turn on Cost Explorer in the payer account (see below) — this is separate from the IAM policies
  • Optional: know your AWS Organizations ID (o-…) if you want to group this integration in nOps

Turn on Cost Explorer in your payer account

AWS blocks all Cost Explorer API calls until the account is opted in, no matter which IAM permissions you grant. If Cost Explorer has never been opened in your payer account, nOps permission checks report the ce:… actions as failing with “User not enabled for cost explorer access” even though your policy is correct. In the payer account:
  1. Open Billing and Cost ManagementCost Explorer and choose Launch Cost Explorer. You can’t do this through the API, and your cost data takes up to 24 hours to appear.
  2. Signed in as the root user, go to the Account page and turn on IAM user and role access to Billing information. Without this, roles are denied Cost Explorer even with the right policies.
Then re-run Check on the integration in nOps.

Step 1: Account

Important: Savings Analysis onboarding must be completed using your AWS Organizations payer (management) account. Child/member accounts are not supported for Savings Analysis onboarding.
1

Open Cloud Provider Integrations

Log in to nOps and go to Settings > Cloud Provider Integrations. Under Add a provider, click Amazon Web Services (AWS).
2

Enter payer account and integration name

  • Payer AWS Account ID — The 12-digit account ID of your AWS Organizations management (payer) account (the account that receives the consolidated bill). Child/member account IDs are not supported for Savings Analysis onboarding.
  • Integration name — A friendly label (for example, your company name plus “AWS Production”).
3

Optional: AWS Organization ID

If you use Organizations, you can enter AWS Organization ID (o-xxxxxxxxxx) so nOps can group accounts consistently. You can select an existing org from the dropdown or enter a new ID.
4

Continue to CUR export

Click Next to go to Step 2: CUR Export Configuration.

Step 2: CUR Export Configuration

In the AWS Billing console, open Data Exports, choose Create, and select Legacy CUR export. Align the export with the following so nOps can rely on the data shape and delivery behavior.
1

Export name

Use an existing Legacy CUR export name if you already deliver CUR to S3—you do not need to create a new export. nOps only suggests a name like nops_cur_<client_id>_hourly (shown in the UI) when you are setting up a new export in AWS.
2

Billing view and report settings

Use Billing view: Primary and View: Primary View (as shown in the nOps wizard summary).
3

Include resource IDs

Under Additional export content, enable Include resource IDs so line items include resource identifiers where applicable.
4

Refresh and format

Keep automatic refresh enabled so AWS continues delivering updates. Set Report data time granularity to Hourly. Set Report versioning to Overwrite existing report (not “Create new report version”). Set Compression type to Parquet.
5

Enter S3 details in nOps

In nOps, enter:
  • S3 bucket — Bucket name only (for example my-cur-bucket), not an s3:// URL
  • S3 path prefix (optional) — Prefix AWS uses under the export path, if you configured one in Data Exports
6

Continue to IAM

Click Next to open Step 3: IAM Policy Creation.

Bring your own CUR

You do not need to create a new Cost and Usage Report if you already deliver a Legacy CUR to Amazon S3 from your payer (management) account. Many teams reuse an export they configured for another FinOps or billing tool. Bring your own means you keep your existing export in AWS and tell nOps where to read it (export name, S3 bucket, and optional prefix). nOps does not require a specific export name—only that the export’s settings match what ingestion expects.

When bring-your-own works well

  • You already have a Legacy CUR export delivering Parquet files to S3 — a CUR 2.0 / standard data export alone does not satisfy this onboarding path, but you can add one as an optional add-on once this integration is active
  • The export is on the same payer account you connect in Step 1
  • You can grant the nOps integration role read access to that bucket (Step 3 updates nOpsBucketPolicy with your bucket ARN)
  • You are willing to change export settings in AWS if your current export does not match the checklist below

CUR requirements checklist

Your export must meet all of the following. If any item differs, update the export in AWS Billing > Data Exports before onboarding (or create a second export that complies and use that one with nOps).
CUR 2.0 / non-legacy exports: This onboarding path (the primary AWS integration) requires a Legacy CUR export. If you only have a newer standard data export and not a Legacy CUR to S3, create a Legacy CUR export as described in Step 2 or in Creating a Legacy CUR export. Once the integration is active, you can separately enable your CUR 2.0 export as an optional add-on — you do not need to give it up.

What to enter in nOps (Step 2)

Use the exact values AWS shows for your existing export:
  1. Export name — The Legacy CUR export name in Data Exports (not the S3 object filename).
  2. S3 bucket — Bucket name only (for example company-cur-prod), not an s3:// URL.
  3. S3 path prefix (optional) — Only if you configured a prefix in the export’s storage settings; leave blank if files land at the bucket root under AWS’s default path.
The suggested name nops_cur_{client_id}_hourly is for new exports. For bring-your-own, type your existing export name instead.

S3 bucket access

The integration IAM role must be able to list the bucket and get CUR objects. In Step 3, replace <example-bucket-name> in nOpsBucketPolicy with your CUR bucket name. If you use a bucket policy, ensure it allows the nOps role (after you create it) to read the CUR prefix.

If your export is close but not exact

After you change export settings, AWS may take up to 24 hours before new files reflect the update. For historical months in a different format, see Request a manual CUR backfill.

Step 3: IAM Policy Creation

Create customer managed policies and a cross-account role that trusts nOps using the external ID shown in the wizard.
One-click option: By default, nOps shows a Deploy Integration Stack (CloudFormation) button that creates a new S3 bucket, the Legacy CUR export, the IAM policies for your selected permission level, and the cross-account role in a single stack — you only need to enter the bucket name and paste back the resulting RoleArn. Pick a bucket name that doesn’t exist yet, and leave the region on us-east-1 (the only region that offers the Legacy CUR resource type). Already have a CUR bucket? See the FAQ above. The manual steps below are for teams that prefer to create the policies and role themselves (click Switch to manual setup in the wizard to see this path).

Choose a permission level

At the top of Step 3, select Minimum Platform or Full Platform. This controls which platform policy JSON nOps shows and which IAM policy name to create:
Full Platform is a superset of Minimum, but attaches more than a single swapped-in policy — see the next step for what each level requires. The bucket policy (nOpsBucketPolicy) is the same for both levels.
1

Create customer managed policies in IAM

In IAM > Policies, create the policies shown in nOps for your selected permission level:
  • Minimum Platform: nOpsBucketPolicy + nOpsMinimumPlatformPermissions (two policies)
  • Full Platform: nOpsBucketPolicy + nOpsFullPlatformDenyList1 + nOpsFullPlatformDenyList2 + nOpsFullPlatformPermissions (four policies) — you’ll also attach the AWS-managed ReadOnlyAccess policy in Step 4, which has no JSON to create
In the modal, each policy block is labeled with the policy name and permission level. Use Copy Policy to copy each JSON document.
Prefer Copy Policy in the nOps wizard so you apply the latest policy version for your account. The accordion below shows Minimum Platform JSON for reference; see Permissions & Resources for the complete Full Platform breakdown (nOpsFullPlatformDenyList1 + nOpsFullPlatformDenyList2 + nOpsFullPlatformPermissions).
Full Platform doesn’t use a single allow-only policy — it attaches the AWS-managed ReadOnlyAccess policy plus three customer-managed documents: nOpsFullPlatformDenyList1 and nOpsFullPlatformDenyList2 (split Deny lists that carve sensitive read actions out of ReadOnlyAccess; split to stay under IAM’s policy-size quota) and nOpsFullPlatformPermissions (writes and reads ReadOnlyAccess doesn’t cover).Use Copy Policy in the nOps wizard for each document when Full Platform is selected, or see the full breakdown in Permissions & Resources.
2

Create the IAM role

In IAM > Roles, create a role for Another AWS account (or create the role and switch to a custom trust relationship). nOps shows a Suggested role name (for example nops-integration-role-<client_id>), and you can copy it from the modal.
3

Enter the custom trust policy

In nOps, copy the trust relationship JSON with Copy trust policy, then paste it into the IAM role trust policy. This policy includes your integration-specific external ID and trusts the nOps connector role.
4

Attach policies to the role

Attach the policies matching your permission level:
  • Minimum Platform: nOpsBucketPolicy + nOpsMinimumPlatformPermissions
  • Full Platform: nOpsBucketPolicy + nOpsFullPlatformDenyList1 + nOpsFullPlatformDenyList2 + nOpsFullPlatformPermissions + the AWS-managed ReadOnlyAccess policy (search and attach — no JSON to paste for this one). A Deny always overrides an Allow, so attaching ReadOnlyAccess alongside the Deny lists cannot grant back anything those lists block.
5

Paste Role ARN and start onboarding

From the IAM role summary, copy the role ARN and paste it into Role ARN in nOps, then click Start Onboarding.
6

Optional: deploy child roles for member accounts

To let nOps read resource inventory (and, on Full Platform, tags) from your AWS Organization’s member accounts, deploy the matching child role template (nops-sa-child-role or nops-sa-child-role-minimal) via CloudFormation StackSets from your payer/management account. Not required to finish onboarding — see Permissions & Resources for details.

Manage an existing integration

Admin users can open Manage on an active AWS integration card to walk through the same steps again (for example, to update the CUR bucket, export name, or role).

Request a manual CUR backfill

If you need historical CUR data that is not yet available in nOps, use Request Backfill to open a guided modal and create an AWS Support ticket. In AWS Support Console, create the case using these selections:
  • Related Issue: Account and Billing
  • Service: Billing
  • Category: Consolidated Billing Questions
  • Severity: General question
Follow these steps:
  1. Open AWS Support Console.
  2. Select:
    • Related Issue: Account and Billing
    • Service: Billing
    • Category: Consolidated Billing Questions
    • Severity: General question
  3. Click Next step: Additional information.
  4. Paste the prefilled values from the modal:
    • Subject: CUR Backfill Request
    • Description:
  1. Click Next step: Solve now or contact us.
  2. Switch to the Contact us tab.
  3. Select Web.
  4. Submit the case.

Next steps

Users and roles

Invite team members and assign Admin or Owner roles where integration access is needed.

AWS Commitment Management

Optional: enable CM from your AWS integration card after onboarding. Uses separate IAM roles and CloudFormation templates.

Permissions & Resources

Complete reference of all IAM roles, policies, and trust relationships for Savings Analysis and Commitment Management.