Amazon Web Services - Integration Setup

FAQs

Who can connect or manage an AWS integration in nOps?

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.

How does nOps use my Cost and Usage Report?

nOps reads Legacy CUR files that AWS delivers to Amazon S3. You configure the export in the AWS Billing console (or let the CloudFormation option create it) and tell nOps the bucket name, export name, and optional S3 prefix so ingestion can find your data. nOps can also read a CUR 2.0 export alongside it for Amazon Bedrock details. See CUR 2.0 (BCM Data Exports).

Can I use an existing CUR export instead of creating a new one?

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.

I'm already connected. Can I add CUR 2.0 later?

Yes. Your Legacy CUR keeps working, and you add CUR 2.0 from Manage without redeploying your original stack. See Add CUR 2.0 to an existing integration.

What happens if my existing CUR does not meet the requirements?

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.

Is this the same as AWS Commitment Management setup?

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.

Can nOps deploy the IAM role and policies for me?

Yes. In Step 2, choose CloudFormation (Recommended). Enter an S3 bucket name, choose a permission level, and click Deploy Integration Stack (CloudFormation) to launch AWS CloudFormation with the template pre-filled. The stack creates a new S3 bucket with the name you entered, your Legacy CUR export, your CUR 2.0 export, the customer-managed IAM policies for your 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, choose Manual IAM instead and follow Step 3.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, so 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].

I already have an S3 bucket for my CUR. Can I still use the CloudFormation option?

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, so 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.The same applies to CUR 2.0: an existing bucket must also allow bcm-data-exports.amazonaws.com. See Let AWS Data Exports write to an existing bucket.

What is the difference between Minimum Platform and Full Platform permissions?

Choose a permission level at the top of the setup screen (Step 2 with CloudFormation, Step 3 with Manual IAM):

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.

My stack deployed fine, but the ce:… permission checks fail with "User not enabled for cost explorer access"

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.

Why is Cluster Name missing in Kubernetes Explorer?

Kubernetes Explorer Cluster Name needs Amazon EKS Split Cost Allocation Data (SCAD) and the AWS-generated cost allocation tag aws:eks:cluster-name active in your payer account. Without that tag, nOps never receives the warehouse column resource_tags_aws_eks_cluster_name, and Explorer shows that Cluster Name isn’t available for this account.Check all three:

In Billing and Cost Management preferences, opt in to Split Cost Allocation Data for Amazon EKS (payer account). See Enabling Split Cost Allocation Data.
On your Legacy CUR export, enable Split cost allocation data under Additional export content (CloudFormation-created exports already include this; bring-your-own must match).
Under Cost allocation tags, confirm aws:eks:cluster-name is Active. AWS enables this tag by default for new accounts, but a tag that was previously deactivated stays off until you activate it again.

After you activate the tag, allow about 24–48 hours for CUR delivery and nOps ingest before Cluster Name appears in Explorer.

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. The wizard has these steps:

Account: Payer account ID, integration name, optional AWS Organization ID
Setup: Choose CloudFormation (Recommended) or Manual IAM:
- CloudFormation: Deploy one stack that creates the S3 bucket, your Legacy CUR export, your CUR 2.0 export, and the IAM role. This is the whole setup; there is no Step 3.
- Manual IAM: Configure your Legacy CUR in Billing > Data Exports (new export or bring your own) and enter the bucket, export name, and path in nOps.
Either way, the step includes an AWS CUR 2.0 section. See CUR 2.0 (BCM Data Exports).
IAM Policy Creation (Manual IAM only): Choose Minimum or Full Platform permissions, create customer-managed policies and a cross-account role with an external ID, then submit the Role ARN
Verify: Run verification to confirm nOps can access your account

Not sure which to pick? Choose CloudFormation unless you already have a Legacy CUR you want to reuse as-is, or your security team requires that IAM be created by hand.

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:

Open Billing and Cost Management → Cost 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.
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.

Open Cloud Provider Integrations

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

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”).

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.

Continue to setup

Click Next to go to Step 2: Setup, where you choose CloudFormation or Manual IAM.

Step 2: Setup

After Next on the Account step, choose how to connect your payer account.

	CloudFormation (Recommended)	Manual IAM
You do	Name a bucket, deploy one stack, paste the Role ARN	Create the CUR export and the IAM policies and role yourself in the AWS console
Creates for you	S3 bucket, Legacy CUR export, CUR 2.0 export, IAM policies, cross-account role	Nothing: you create each piece
Wizard steps	Setup, then Verify	CUR export, IAM policy creation, then Verify
Use it when	You’re starting fresh	You have a Legacy CUR to reuse, or IAM must be created by hand

Option A: CloudFormation (Recommended)

Choose CloudFormation and a permission level

Select CloudFormation. At the top, choose Minimum Platform (Savings Analysis) or Full Platform (Inform & Operate). See Choose a permission level for the difference.

Name the S3 bucket

Under S3 bucket, enter a name that doesn’t exist yet. The stack creates it in us-east-1. Already have a CUR bucket? See the FAQ, or choose Manual IAM instead.

Check AWS CUR 2.0

Leave Enable AWS CUR 2.0 (BCM Data Exports) checked and the fields blank. nOps fills in defaults when you deploy. Details are in CUR 2.0 (BCM Data Exports).

Deploy the payer stack

Under Step 1: Deploy payer stack, click Deploy Integration Stack (CloudFormation). AWS opens with the template pre-filled. Keep the region on us-east-1, select the box acknowledging that CloudFormation may create IAM resources, and create the stack. Wait for it to show CREATE_COMPLETE.

Paste the Role ARN

On the stack’s Outputs tab, copy RoleArn. Paste it into Role ARN in nOps.

Optional: deploy child roles

Under Step 2: Deploy child roles via StackSets, you can give nOps read access to your member accounts. It isn’t required to finish onboarding, and you can do it later. See Permissions & Resources.

Start onboarding

Click Start Onboarding, then run verification.

Option B: Manual IAM

Select Manual IAM. 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.

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.

Billing view and report settings

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

Include resource IDs and Split Cost Allocation Data

Under Additional export content, enable Include resource IDs so line items include resource identifiers where applicable. For Kubernetes Explorer Cluster Name, also enable Split cost allocation data on the Legacy CUR (CloudFormation-created exports already include it; bring-your-own must match) and keep the AWS-generated cost allocation tag aws:eks:cluster-name active — see the CUR requirements checklist.

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.

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

Set up CUR 2.0

Below the Legacy CUR settings, the wizard shows an AWS CUR 2.0 section with Enable AWS CUR 2.0 (BCM Data Exports) checked. Fill it in using CUR 2.0 (BCM Data Exports) below.

Continue to IAM

Click Next to open Step 3: IAM Policy Creation.

CUR 2.0 (BCM Data Exports)

CUR 2.0 is AWS’s newer cost and usage export. AWS also calls it a standard data export or BCM Data Exports. nOps reads it in addition to your Legacy CUR. It does not replace it, so you still complete the Legacy CUR settings above. CUR 2.0 is part of Step 2 in the wizard. You’ll see an AWS CUR 2.0 section on the setup screen (below the Legacy CUR settings with Manual IAM). Enable AWS CUR 2.0 (BCM Data Exports) is checked by default. Keep it checked so nOps can show Amazon Bedrock details, including which IAM principal made each model call.

What you enter in nOps

Field	Required	What to enter
S3 bucket	Yes	Bucket name only (for example `my-billing-bucket`), not an `s3://` URL. It can be the same bucket as your Legacy CUR.
S3 path prefix	No	The folder AWS writes the export under. With CloudFormation, the default is `nops-cur2`.
Export name	Yes	The name of the CUR 2.0 export in AWS. With CloudFormation, the suggested name is `nops_cur2_{your_nops_client_id}_hourly`.

Use the exact bucket and export name AWS shows. nOps grants its role access to that bucket only, so a blank or mismatched value stops nOps from finding your data.

Already connected with a Legacy CUR only? Skip to Add CUR 2.0 to an existing integration.

Setting up AWS for the first time? Pick the tab that matches how you’re connecting.

CloudFormation (recommended)
Manual IAM

The stack creates the CUR 2.0 export for you. You don’t need to open the AWS Data Exports console.

Choose CloudFormation

In Step 2, select CloudFormation and choose Minimum Platform or Full Platform at the top. See Option A.

Name the S3 bucket

Enter an S3 bucket name that doesn’t exist yet. The stack creates it.

Fill in AWS CUR 2.0

In AWS CUR 2.0, leave Enable AWS CUR 2.0 (BCM Data Exports) checked. To keep it simple, leave the fields blank. When you deploy, nOps fills them in with:

S3 bucket: the same bucket you named above
S3 path prefix: nops-cur2
Export name: nops_cur2_{your_nops_client_id}_hourly

Deploy the stack

Under Step 1: Deploy payer stack, click Deploy Integration Stack (CloudFormation). Leave the region on us-east-1, then create the stack in AWS. It creates your Legacy CUR export, your CUR 2.0 export, and the IAM role.

Paste the Role ARN

Copy the RoleArn output from CloudFormation, paste it into Role ARN in nOps, and continue.

Using a different bucket for CUR 2.0? Enter it in S3 bucket under AWS CUR 2.0. That bucket must already exist and already allow AWS Data Exports to write to it (see the policy). The stack doesn’t change the policy on a bucket you own. nOps access to the bucket is added for you when you deploy.

You create the CUR 2.0 export in AWS, then tell nOps where it delivers.

Create the export in AWS

In the AWS Billing console, open Data Exports, click Create, and choose Standard data export.

Match these settings

Export name: any name you like (for example nops_cur2_{your_nops_client_id}_hourly). You’ll enter it in nOps.
Table: Cost and usage report (CUR 2.0), with all columns selected
Billing view: Primary
Additional export content: turn on Include resource IDs, Split cost allocation data, Include caller IAM principal, and Include capacity reservation data
Time granularity: Hourly
Compression and file format: Parquet
File versioning: Overwrite existing export file
S3 bucket and prefix: the bucket (and optional prefix) where you want the files delivered

Turn on Include caller IAM principal. nOps uses it for Amazon Bedrock details. Without it, Bedrock details are missing.

Enter the details in nOps

Back in Step 2, under AWS CUR 2.0, keep Enable AWS CUR 2.0 (BCM Data Exports) checked. Enter the S3 bucket and Export name exactly as they appear in AWS. Add the S3 path prefix if you set one.

Copy the bucket policy in Step 3

In Step 3, copy the nOpsBucketPolicy JSON from the wizard. If your CUR 2.0 bucket differs from your Legacy CUR bucket, the JSON already includes both. Copy it from the wizard instead of the example on this page.

Check that it’s working

On the AWS integration card in Settings > Cloud Provider Integrations, a CUR 2.0 badge shows the export’s status:

Badge	What it means
CUR 2.0 (green)	Data is arriving.
CUR 2.0 (waiting)	nOps is waiting for AWS to deliver the export’s files. New exports can take a while to produce their first files.
CUR 2.0 (failed)	Ingest hit a problem. Hover over the badge to see the error. Check the bucket name, export name, and bucket access above.

CUR 2.0 status is tracked separately from your Legacy CUR. A CUR 2.0 problem never changes the health of your main integration. In Manage, the AWS CUR 2.0 section also shows the last sync result.

Add CUR 2.0 to an existing integration

Use this if you already connected AWS with a Legacy CUR and want to add CUR 2.0 now. Your Legacy CUR keeps working and nothing about it changes. You add CUR 2.0 from Manage, with a small add-on stack that creates the export (and, if you want, its bucket) without touching the stack you deployed originally.

Before you start

You’re an Admin in nOps and can create CloudFormation stacks in your AWS payer account.
Decide where the CUR 2.0 files will land. The easiest choice is a new bucket, because the add-on stack sets it up completely. Reusing your Legacy CUR bucket or another bucket you own means editing that bucket’s policy first (see below).

Choose an option

Your situation	Pick this in the add-on card	Extra work
You don’t have a CUR 2.0 export and want the simplest path	Create the export and a new S3 bucket	None. Enter a bucket name that doesn’t exist yet.
You don’t have a CUR 2.0 export but want to reuse a bucket (for example your Legacy CUR bucket)	Create the export in an existing bucket	Add two statements to that bucket’s policy before you deploy.
You already created a CUR 2.0 export in AWS	I already have a CUR 2.0 export	None. Enter its exact bucket and export name. nOps only gets access.

Steps

Open Manage

Go to Settings > Cloud Provider Integrations and click Manage on your AWS integration.

Fill in AWS CUR 2.0

The wizard opens on the CUR settings. Leave your Legacy CUR settings alone. In the AWS CUR 2.0 section below them, make sure Enable AWS CUR 2.0 (BCM Data Exports) is checked, then enter:

S3 bucket. A new bucket name, or the existing bucket you’re reusing.
Export name. For a new export, use nops_cur2_{your_nops_client_id}_hourly. For an export you already have, use the exact name AWS shows.
S3 path prefix (optional). Leave blank to use nops-cur2 for a new export. For an export you already have, enter the prefix it uses.

Deploy the add-on stack

In the Set up CUR 2.0 with CloudFormation card, select the option from the table above and click Deploy add-on stack. AWS opens with the stack pre-filled in us-east-1. Keep that region, select the box acknowledging that CloudFormation may create IAM resources, create the stack, and wait for CREATE_COMPLETE.The stack also attaches a separate nOpsCur2BucketPolicy to your existing nOps role, so nOps can read the bucket.

Save in nOps

Back in nOps, click Next through the wizard (nothing else needs to change) and click Save changes. This is what tells nOps which bucket and export to read, so don’t skip it.

Check the badge

On the AWS integration card, the CUR 2.0 badge shows waiting until AWS delivers the first files, which can take a while for a new export. See Check that it’s working.

If the stack fails

Error	What to do
The bucket already exists	You picked new bucket for a bucket that exists. Delete the failed stack and redeploy with existing bucket.
Failed to verify customer bucket permission	Your bucket doesn’t allow AWS Data Exports yet. Add the policy statements below, delete the failed stack, and redeploy.
The export name already exists	You already have a CUR 2.0 export with that name. Delete the failed stack and redeploy with I already have a CUR 2.0 export.

Other ways to do it

Prefer not to add a stack? Pick one of these instead:

Update your original stack. Set CreateCur2Export to true and Cur2BucketName to your bucket, then update the stack.
Do it by hand. Create the export in AWS using the Manual IAM tab above, then copy the nOpsBucketPolicy JSON from Step 3 over your existing policy.

Don’t combine these with the add-on stack. That puts the same access in two places, and two stacks that both create the export fail on the name.

Let AWS Data Exports write to an existing bucket

When a stack creates the bucket, it also lets AWS Data Exports write to it. When you use a bucket you already own, the stack never edits your bucket policy. A bucket policy is a single document, so writing one would replace everything already on it. If AWS fails the export with “Failed to verify customer bucket permission”, add these two statements to the Statement list in the bucket’s policy (replace YOUR_BUCKET and YOUR_ACCOUNT_ID) and deploy again:

[
  {
    "Sid": "NopsCur2GetBucketMetadata",
    "Effect": "Allow",
    "Principal": { "Service": "bcm-data-exports.amazonaws.com" },
    "Action": ["s3:GetBucketAcl", "s3:GetBucketPolicy"],
    "Resource": "arn:aws:s3:::YOUR_BUCKET",
    "Condition": {
      "StringEquals": { "aws:SourceAccount": "YOUR_ACCOUNT_ID" },
      "ArnLike": { "aws:SourceArn": "arn:aws:bcm-data-exports:us-east-1:YOUR_ACCOUNT_ID:export/*" }
    }
  },
  {
    "Sid": "NopsCur2PutObject",
    "Effect": "Allow",
    "Principal": { "Service": "bcm-data-exports.amazonaws.com" },
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::YOUR_BUCKET/*",
    "Condition": {
      "StringEquals": { "aws:SourceAccount": "YOUR_ACCOUNT_ID" },
      "ArnLike": { "aws:SourceArn": "arn:aws:bcm-data-exports:us-east-1:YOUR_ACCOUNT_ID:export/*" }
    }
  }
]

This is separate from the billingreports.amazonaws.com grant your Legacy CUR uses. A bucket that already receives a Legacy CUR usually needs both.

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 set up CUR 2.0 alongside it (see CUR 2.0 (BCM Data Exports))
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).

Requirement	Required setting	Why nOps needs it
Export type	Legacy CUR export	nOps ingests the classic CUR delivery layout AWS writes to S3
Account	Payer (management) account	Consolidated billing and organization-level cost data
Billing view	Primary	Matches the management account’s primary billing view
View	Primary View	Consistent scope for line items
Resource detail	Include resource IDs enabled	Resource-level cost allocation and showback
Split Cost Allocation Data	Split cost allocation data enabled on the Legacy CUR	EKS pod/namespace split lines for Kubernetes cost views. CloudFormation-created exports already include this; bring-your-own must match
EKS cluster cost allocation tag	AWS-generated tag `aws:eks:cluster-name` Active under Cost allocation tags (warehouse column `resource_tags_aws_eks_cluster_name`)	Without this tag, Cluster Name is unavailable in Kubernetes Explorer
Refresh	Automatic refresh enabled	Ongoing daily (or more frequent) file delivery
Time granularity	Hourly	Hour-level usage and cost analysis
Report versioning	Overwrite existing report	Predictable object paths; avoids version sprawl nOps does not expect
Compression	Parquet	Columnar format used by the ingestion pipeline
Delivery	Amazon S3 in your account	nOps reads objects from the bucket you specify

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. You can keep your CUR 2.0 export and point nOps at it in the AWS CUR 2.0 section of the same step. See CUR 2.0 (BCM Data Exports).

What to enter in nOps (Step 2)

Use the exact values AWS shows for your existing export:

Export name: The Legacy CUR export name in Data Exports (not the S3 object filename).
S3 bucket: Bucket name only (for example company-cur-prod), not an s3:// URL.
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

Situation	What to do
Granularity is Daily instead of Hourly	Edit the export to Hourly, or add a new hourly Legacy CUR export for nOps
Versioning is Create new report version	Switch to Overwrite existing report (nOps expects a stable delivery pattern)
Compression is CSV or GZIP	Create or reconfigure an export with Parquet
Include resource IDs is off	Enable it under Additional export content (may increase file size)
CUR is in a member account bucket	Use payer-account delivery, or copy/consolidate to a bucket the payer integration role can access

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 (Manual IAM)

This step is only for Manual IAM. If you chose CloudFormation, the stack already created everything here and you can skip to Verify. Create customer managed policies and a cross-account role that trusts nOps using the external ID shown in the wizard.

Would you rather not do this by hand? Go back and choose CloudFormation in Step 2. It creates the same policies and role in a single stack.

Choose a permission level

At the top of the setup screen, select Minimum Platform or Full Platform. This controls which platform policy JSON nOps shows and which IAM policy name to create:

Level	IAM policy name	Use when
Minimum Platform	`nOpsMinimumPlatformPermissions`	Savings Analysis: cost visibility, CUR, and commitment read APIs only
Full Platform	`nOpsFullPlatformPermissions`	Inform & Operate: everything in Minimum, plus broader inventory reads and selected write actions (rightsizing, purchasing prep, support cases)

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.

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 when you attach policies below, 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).

IAM Policy: nOpsBucketPolicy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketPolicy",
        "s3:GetEncryptionConfiguration",
        "s3:GetBucketVersioning",
        "s3:GetBucketPolicyStatus",
        "s3:GetBucketLocation",
        "s3:GetBucketAcl",
        "s3:GetBucketLogging",
        "s3:GetObject",
        "s3:PutBucketPolicy",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::<example-bucket-name>",
        "arn:aws:s3:::<example-bucket-name>/*"
      ]
    }
  ]
}

If your CUR 2.0 export uses a bucket other than your Legacy CUR bucket, the wizard adds a second pair of ARNs for it to this same policy. Copy the JSON from the app rather than this example so you get both.

IAM Policy: nOpsMinimumPlatformPermissions (Minimum Platform)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bcm-data-exports:ListExports",
        "bcm-data-exports:ListTables",
        "bcm-data-exports:GetExport",
        "bcm-data-exports:GetExecution",
        "bcm-data-exports:CreateExport",
        "bcm-data-exports:UpdateExport",
        "bcm-data-exports:ListExecutions",
        "ce:GetReservationCoverage",
        "ce:GetReservationPurchaseRecommendation",
        "ce:GetReservationUtilization",
        "ce:GetSavingsPlanPurchaseRecommendationDetails",
        "ce:GetSavingsPlansCoverage",
        "ce:GetSavingsPlansPurchaseRecommendation",
        "ce:GetSavingsPlansUtilization",
        "ce:GetSavingsPlansUtilizationDetails",
        "ce:ListSavingsPlansPurchaseRecommendationGeneration",
        "cur:GetClassicReport",
        "cur:GetClassicReportPreferences",
        "cur:GetUsageReport",
        "cur:DescribeReportDefinitions",
        "cur:PutReportDefinition",
        "ec2:DescribeReservedInstances",
        "organizations:ListAccounts",
        "organizations:DescribeOrganization",
        "organizations:ListRoots",
        "savingsplans:DescribeSavingsPlanRates",
        "savingsplans:DescribeSavingsPlans",
        "savingsplans:DescribeSavingsPlansOfferingRates",
        "savingsplans:DescribeSavingsPlansOfferings",
        "savingsplans:ListTagsForResource",
        "support:CreateCase",
        "support:DescribeCases"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::*:role/nops-sa-child-role-minimal"
    }
  ]
}

IAM Policy: nOpsFullPlatformDenyList1/2 + nOpsFullPlatformPermissions (Full Platform)

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.

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.

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.

IAM Policy: trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::861341088565:role/nops-data-connector"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "<external_id_from_nops_modal>"
        }
      }
    }
  ]
}

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.

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. Next, run verification.

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.

Verify

The last step of the wizard checks that nOps can reach your account. Click Run verification and wait for the results. Each check shows whether it passed and, if not, what to fix. Common fixes:

ce:… checks fail with “User not enabled for cost explorer access”: turn on Cost Explorer, as described in Turn on Cost Explorer in your payer account.
CUR checks fail: confirm the bucket name, export name, and prefix, and that the export meets the requirements.
Role can’t be assumed: confirm the Role ARN, and for Manual IAM that the trust policy has the external ID from the wizard.

Data from a new CUR can take up to 24 hours to appear after AWS first delivers files.

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). Manage skips the CloudFormation-or-manual choice and opens the CUR settings directly, then the IAM step, and ends with Save changes. To add CUR 2.0 to an integration you already have, follow Add CUR 2.0 to an existing integration.

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:

Open AWS Support Console.
Select:
- Related Issue: Account and Billing
- Service: Billing
- Category: Consolidated Billing Questions
- Severity: General question
Click Next step: Additional information.
Paste the prefilled values from the modal:
- Subject: CUR Backfill Request
- Description:

Please Backfill our CUR for the following:
CUR Report name: <cur_report_name>
Time Period: <month_to_backfill_from> to <month_before_data_in_nops>
Master Payer account: <master_payer_account_number>
Type of CUR: Legacy CUR
Reason: We are leveraging a FinOps solution that requires all CURs to be in parquet format, and would like historical information for the dates listed to be backfilled.

Click Next step: Solve now or contact us.
Switch to the Contact us tab.
Select Web.
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.

​FAQs

​Overview

​Prerequisites

​Turn on Cost Explorer in your payer account

​Step 1: Account

​Step 2: Setup

​Option A: CloudFormation (Recommended)

​Option B: Manual IAM

​CUR 2.0 (BCM Data Exports)

​What you enter in nOps

​Check that it’s working

​Add CUR 2.0 to an existing integration

​Before you start

​Choose an option

​Steps

​If the stack fails

​Other ways to do it

​Let AWS Data Exports write to an existing bucket

​Bring your own CUR

​When bring-your-own works well

​CUR requirements checklist

​What to enter in nOps (Step 2)

​S3 bucket access

​If your export is close but not exact

​Step 3: IAM Policy Creation (Manual IAM)

​Choose a permission level

​Verify

​Manage an existing integration

​Request a manual CUR backfill

​Next steps

Users and roles

AWS Commitment Management

Permissions & Resources

FAQs

Overview

Prerequisites

Turn on Cost Explorer in your payer account

Step 1: Account

Step 2: Setup

Option A: CloudFormation (Recommended)

Option B: Manual IAM

CUR 2.0 (BCM Data Exports)

What you enter in nOps

Check that it’s working

Add CUR 2.0 to an existing integration

Before you start

Choose an option

Steps

If the stack fails

Other ways to do it

Let AWS Data Exports write to an existing bucket

Bring your own CUR

When bring-your-own works well

CUR requirements checklist

What to enter in nOps (Step 2)

S3 bucket access

If your export is close but not exact

Step 3: IAM Policy Creation (Manual IAM)

Choose a permission level

Verify

Manage an existing integration

Request a manual CUR backfill

Next steps