> For the complete documentation index, see [llms.txt](https://docs.onelens.cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.onelens.cloud/integrations/cloud-and-cost-sources/connect-to-aws/frequently-asked-questions-faq.md).

# Frequently Asked Questions (FAQ)

Answers to common questions regarding the architecture, security, and implementation of the OneLens Amazon Web Services (AWS) integration.

## What do I need before I can connect OneLens to AWS?

You need two things in place before starting:

* An active AWS account with permissions to create CloudFormation Stacks and StackSets.
* An S3 bucket that stores your Cost and Usage Report (CUR). If you haven't set one up yet, see [Setting Up Cost Reports Manually](/integrations/cloud-and-cost-sources/connect-to-aws/setting-up-cost-reports-manually.md).

{% hint style="info" %}
Both the Resource Role CFT and the CUR Role CFT must be deployed for OneLens to function correctly. Deploying only one will result in incomplete data ingestion.
{% endhint %}

## Does OneLens modify any of my AWS resources?

**No.** OneLens uses read-only IAM roles created by the CloudFormation templates. It only collects resource metadata, CloudWatch metrics, and Cost and Usage Report (CUR) data. No changes are made to your infrastructure at any point.

The roles are also fully reversible - you can delete them at any time to revoke OneLens access to your account.

Our Scheduler setup involves some permissions that can modify resources, but this is optional and not included in the default setup.

## Why must the CUR Stack be deployed in us-east-1?

AWS Billing services, which generate and host the Cost and Usage Report, are internally hosted in the us-east-1 region. The CloudFormation stack that creates the CUR access role must be deployed in the same region to function correctly.

The Resource Role stack, on the other hand, can be deployed in any region since IAM is a global AWS service.

{% hint style="danger" %}
If you accidentally deploy the CUR Stack in a region other than us-east-1, delete it and redeploy in the correct region before proceeding.
{% endhint %}

## What is the difference between a Stack and a StackSet?

Both deploy CloudFormation templates, but they serve different purposes:

* Stack: Deploys resources into a single AWS account. Used for the CUR Role (master account only) and the Resource Role (individual accounts).
* StackSet: Deploys resources across multiple AWS accounts from a central management account. Used to push the Resource Role into all child accounts simultaneously.

If you manage accounts centrally via AWS Organizations, use the StackSet approach for the Resource Role in child accounts. You still need to run a Stack in the management account itself.

## Do I need to deploy the CUR Role in my child accounts?

No. You only need to deploy the CUR Role in your master/payer account. AWS Consolidated Billing means the master account holds all cost data for every linked account, so OneLens only needs CUR access from that one account.

{% hint style="warning" %}
If you have decentralised accounts (not part of AWS Organizations), you will need to deploy the CUR Role separately in each account you want to connect.
{% endhint %}

## Why has my cost data stopped updating after my Master (Payer) account changed?

If your accounts are onboarded to OneLens individually with each account carrying its own CUR 2.0 data export, rather than a single export from a master account, then a change to the master (payer) account silently breaks those exports.

This is common where your master account sits with a reseller. OneLens does not onboard the reseller's master account, so each of your own accounts has its own data export configured. When the billing relationship above those accounts changes, their exports stop being refreshed.

AWS gives you no error when this happens:

* The export remains in an **Active** state in the AWS console.
* The S3 bucket and the OneLens CUR IAM role still exist and are still readable, so there is no permission failure and no delivery error.
* The export simply stops refreshing.

#### How to verify it

In the affected account, open **Billing and Cost Management → Data Exports** and check the **Last refreshed** field on the OneLens export.

* **Healthy:** Last refreshed shows today's or yesterday's date.
* **Stopped:** Last refreshed shows a date older than that, and it does not advance on subsequent days.

An Active status alone does not mean the export is working. **Last refreshed** is the field that tells you the truth.

#### How to fix it

Delete and recreate the data export in each affected account. Nothing needs to be changed in the master account.

1. In the affected account, open **Billing and Cost Management → Data Exports**, select the OneLens export, and delete it.
2. Recreate it by following Setting Up Cost Reports Manually, using the same settings as before: `CUR 2.0` format, **Include Resource ID** and **Split Cost Allocation Data** both selected.
3. Point the recreated export at the **same S3 bucket** and the same `cur` path prefix. Your existing CUR bucket and IAM role remain valid, so there is no need to create a new bucket or redeploy the CloudFormation stacks.
4. Allow 24–48 hours for AWS to generate the first report into the recreated export.
5. Repeat for every affected account.

{% hint style="info" %}
Cost data already ingested by OneLens is not affected, so your historical reporting stays intact. The only gap is the period between the export stopping and the recreated export delivering its first report.
{% endhint %}

{% hint style="warning" %}
If several of your accounts moved at the same time, each one needs its own delete-and-recreate. An export that has stopped will not recover on its own, and it will keep reporting an **Active** status while it does nothing.
{% endhint %}

#### What to send us

Once you have recreated the exports, email <support@astuto.ai> with:

* The Account IDs where you recreated the export
* The date the master account changed
* The S3 bucket name, if it is different from the one you originally shared with us

We will confirm ingestion has resumed from our side.

## My CUR 2.0 export fails when I enable Split Cost Allocation Data. Why?

Because AWS does not allow Split Cost Allocation Data and pro forma cost data in the same export. If your billing is delivered through AWS Billing Conductor, which is how resellers and AWS Solution Provider partners produce a pro forma view of your costs, Split Cost Allocation Data cannot be enabled on that export, and the export will fail to be created.

The AWS Billing and Cost Management Data Exports API rejects the request with a `ValidationException`:

```
Proforma CUR2.0 is not allowed to create a Split Cost Allocation CUR2.0
(Service: BcmDataExports, Status Code: 400)
```

If you are creating the export through CloudFormation, the same rejection surfaces wrapped in a resource handler error against the `AWS::BCMDataExports::Export` resource, with `HandlerErrorCode: GeneralServiceException`:

```
Resource handler returned message: "Error occurred during operation
'AWS::BCMDataExports::Export. e.toString():
software.amazon.awssdk.services.bcmdataexports.model.ValidationException:
Proforma CUR2.0 is not allowed to create a Split Cost Allocation CUR2.0
(Service: BcmDataExports, Status Code: 400, Request ID: <request-id>)
(SDK Attempt Count: 1)'."
(RequestToken: <request-token>, HandlerErrorCode: GeneralServiceException)
```

Because the rejection comes from the API, it applies however you create the export: CloudFormation, the CLI, or the console.

AWS documents the same restriction in its own guidance:

* "**Split cost allocation data** is disabled when pro forma data export is enabled." ([AWS docs](https://docs.aws.amazon.com/cur/latest/userguide/dataexports-create-abc.html))
* "When creating a report based on a billing transfer showback/chargeback view or billing group view, you must disable the Split Cost Allocation Data functionality." ([AWS docs](https://docs.aws.amazon.com/cur/latest/userguide/dataexports-create-billing-view.html))

This is an AWS platform limitation. It is not a OneLens restriction, and there is no configuration on the OneLens side that can lift it.

{% hint style="info" %}
Depending on how you start, you may not see an error at all: if you begin from the Billing Conductor flow in the console, the **Split cost allocation data** checkbox is greyed out instead. The error above appears when Split Cost Allocation Data is already selected and the pro forma view is applied afterwards, which is the path you take when following Setting Up Cost Reports Manually.
{% endhint %}

#### What this means for your EKS visibility

Split Cost Allocation Data is what adds the `split_line_item_*` columns to the CUR, the columns that attribute a shared EC2 instance's cost down to individual Kubernetes pods. Without those columns:

* Your EKS spend still appears in OneLens as the underlying EC2, EBS and networking line items, so **total cost remains accurate**.
* Container-level attribution is **not available:** no pod, namespace or workload level cost breakdown, and no Kubernetes cost allocation to cost centres.
* The OneLens Agent cannot compensate for this. The agent relies on split cost allocation line items in the CUR to attribute cluster cost, so it will not produce workload-level costs when those line items are absent.

{% hint style="warning" %}
If you are billed via a reseller or AWS Solution Provider and you need workload-level Kubernetes cost visibility, raise this with your reseller before onboarding. The limitation sits with how your billing is structured, and it cannot be resolved after the fact from within OneLens.
{% endhint %}

#### Is there a workaround?

No. You have to choose between the two on a given export:

* **Keep the pro forma export.** Your costs match the invoice you actually pay, and you accept EKS visibility at cluster level rather than workload level.
* **Use a standard, non-pro forma export.** You get full Split Cost Allocation Data, but the rates reflect AWS's billing data rather than your reseller's pricing, so the totals will not reconcile against your invoice.

For most customers billed through a reseller, the pro forma export is the correct choice, and reduced EKS granularity is the trade-off.

#### What to send us

If you are in this situation, email <support@astuto.ai> with:

* Your AWS Account ID and the payer (management) Account ID
* Confirmation that you are billed via a reseller, AWS Solution Provider, or AWS Billing Conductor
* The names of the EKS clusters affected

We will confirm the configuration from our side and set expectations on what Kubernetes reporting will show.

## What does the Role Name format mean, and do I have to follow it?

The recommended format for role names is:

```
OneLens-<10-char-alphanumeric-unique-id>
```

The unique identifier helps OneLens associate each role with the correct account during onboarding. You can either:

* Define your own name following this format, or
* Contact the OneLens support team at <support@astuto.ai> and they will provide the exact role name for your account.

## I see a ManagedPolicy warning during Stack creation. Should I be concerned?

No, this is expected. The CloudFormation templates are designed to create IAM roles with Managed Policies that grant OneLens its scoped, read-only access. AWS surfaces this warning any time a template creates an IAM policy.

Simply tick the acknowledgement checkbox and continue. The permissions are strictly limited to what OneLens needs - no broad or administrative access is granted.

{% hint style="info" %}
You can review the full contents of each CloudFormation template before deploying by opening the S3 URL in your browser.
{% endhint %}

## What information do I need to send to OneLens after deployment?

Once both CFTs are deployed successfully, email the following details to <support@astuto.ai>:

* Master Account ID or the list of individually integrated account IDs
* Resource Role ARN (from the Stack Output tab)
* CUR Role ARN (from the Stack Output tab)
* S3 Bucket Name where your CUR files are stored
* Stack Role Names and unique identifiers (only if you customised the role names during deployment)

{% hint style="success" %}
The Role ARNs are visible under the Outputs tab of each completed CloudFormation Stack in the AWS console.
{% endhint %}

## How long does it take for data to appear in OneLens after connecting?

Once OneLens receives your account details and configures the connection, the initial data ingestion begins. Depending on the size of your CUR and the number of resources, the first data may take a few hours to appear in the dashboards.

After the initial load, OneLens processes data daily (or on the agreed schedule), so your insights stay up to date automatically.

## Can I revoke OneLens access to my AWS account?

Yes. To revoke access, simply delete the IAM roles created by the CloudFormation Stacks from your AWS account. You can do this by deleting the stacks themselves from the CloudFormation console, which will automatically remove all associated resources.

Once deleted, OneLens will no longer be able to access your account data.

{% hint style="warning" %}
Deleting the stacks is irreversible. If you want to reconnect OneLens later, you will need to redeploy the CFTs and go through the onboarding process again.
{% endhint %}

## What happens if my StackSet deployment shows a FAILED status for some accounts?

A failed StackSet deployment usually means one of the following:

* The target account does not have the required permissions to create IAM roles.
* The management account does not have StackSet administration permissions enabled.
* There is a naming conflict with an existing role in the target account.

Check the Detailed Status in the StackSet Operations tab for the specific error message. Fix the underlying issue and re-deploy or update the StackSet for the affected accounts.

{% hint style="info" %}
Accounts with a SUCCEEDED status are connected and working even if other accounts in the same StackSet failed. You do not need to re-run the entire StackSet.
{% endhint %}

## Can I connect Kubernetes clusters alongside my AWS accounts?

Yes. After connecting your AWS account, you can optionally integrate your EKS or AKS Kubernetes clusters for deeper cost and usage insights. This gives you pod-level visibility alongside your standard cloud cost data.

See the [Kubernetes Integration](/integrations/kubernetes.md) section for setup instructions, and [Enable Split Cost Allocation for EKS](/integrations/kubernetes/enable-split-cost-allocation-for-eks.md) if you want workload-level cost attribution in your Cost and Usage Report.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.onelens.cloud/integrations/cloud-and-cost-sources/connect-to-aws/frequently-asked-questions-faq.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.