> ## Documentation Index
> Fetch the complete documentation index at: https://help.nops.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Amazon Web Services - Integration Setup
> Onboard your AWS payer account for a savings analysis. A step-by-step walkthrough to connect your payer account so nOps can analyze your spend and surface optimization insights.
## 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](/platform/users).
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](#bring-your-own-cur). 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](#cur-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](/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](/aws/permissions-and-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](#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**](https://clara.nops.io/settings). 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](#bring-your-own-cur)); 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](https://docs.aws.amazon.com/cur/latest/userguide/dataexports-create-legacy.html).
**Who can do this:** Only **Admin** users in your nOps organization can connect or manage AWS integrations. **Members** cannot. See [Users and roles](/platform/users). 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](#bring-your-own-cur), 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 Management**](https://console.aws.amazon.com/costmanagement/) → **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.
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.
Log in to **nOps** and go to [**Settings > Cloud Provider Integrations**](https://clara.nops.io/settings). Under **Add a provider**, click **Amazon Web Services** (AWS).
* **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”).
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.
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.
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__hourly` (shown in the UI) when you are setting up a new export in AWS.
Use **Billing view: Primary** and **View: Primary View** (as shown in the nOps wizard summary).
Under **Additional export content**, enable **Include resource IDs** so line items include resource identifiers where applicable.
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**.
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
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](#can-i-add-a-cur-2-0-bcm-data-exports-export-alongside-my-legacy-cur) 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](https://console.aws.amazon.com/billing/home#/dataexports) 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 |
| 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](https://docs.aws.amazon.com/cur/latest/userguide/dataexports-create-legacy.html). Once the integration is active, you can separately enable your CUR 2.0 export as an [optional add-on](#can-i-add-a-cur-2-0-bcm-data-exports-export-alongside-my-legacy-cur) — 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 `` 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](#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](#faqs). 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:
| 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.
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](/aws/permissions-and-resources) for the complete **Full Platform** breakdown (`nOpsFullPlatformDenyList1` + `nOpsFullPlatformDenyList2` + `nOpsFullPlatformPermissions`).
```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
"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:::",
"arn:aws:s3:::/*"
]
}
]
}
```
```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
"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"
}
]
}
```
**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](/aws/permissions-and-resources#customer-managed-policies).
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-`), and you can copy it from the modal.
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.
```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::861341088565:role/nops-data-connector"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": ""
}
}
}
]
}
```
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.
From the IAM role summary, copy the role ARN and paste it into **Role ARN** in nOps, then click **Start Onboarding**.
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](/aws/permissions-and-resources#sa-child-roles) 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](https://console.aws.amazon.com/support/home#/case/create).
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:**
```text theme={"theme":{"light":"github-light","dark":"github-dark"}}
Please Backfill our CUR for the following:
CUR Report name:
Time Period: to
Master Payer account:
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.
```
5. Click **Next step: Solve now or contact us**.
6. Switch to the **Contact us** tab.
7. Select **Web**.
8. Submit the case.
***
## Next steps
Invite team members and assign **Admin** or **Owner** roles where integration access is needed.
Optional: enable CM from your AWS integration card after onboarding. Uses separate IAM roles and CloudFormation templates.
Complete reference of all IAM roles, policies, and trust relationships for Savings Analysis and Commitment Management.