URL: https://help.doit.com/docs/amazon-web-services/aws-orgs-concepts # Before you begin To prepare for the onboarding after signing up with DoiT, you need to understand your current usage of [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) and AWS accounts. ## AWS Organizations AWS Organizations is an account management service that provides consolidated billing capabilities. - If you use one AWS account to pay all charges accrued by multiple accounts, then you are using AWS Organizations. - If you use multiple AWS accounts to pay charges accrued by multiple accounts, then you may have a mix of accounts with and without Organizations. You can reach out to your DoiT contact to set up a review with us. - If you have only one AWS account, open the [AWS Organizations Console](https://console.aws.amazon.com/organizations/v2/home/) with an IAM administrator role. If you have the option to **Create an Organization**, then you are not using AWS Organizations yet. ## AWS Organizations features AWS Organizations has two feature sets: [All features](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#feature-set-all) and [Consolidated Billing features](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#feature-set-cb-only). To see which features you've enabled: 1. Sign in to the [AWS Organizations Console](https://console.aws.amazon.com/organizations/v2) as an IAM admin user in the organization's management account (the payer account of the organization). 1. Select **Settings** in the navigation pane, find the **Feature Set** section. - If it shows **Consolidated Features Only**, then you're not using Organizations-level features. - If it shows **Your organization has all features enabled**, then you might be using some Organizations-level features. 1. Select **Services** in the navigation pane. 1. Note down all the features that have `Access enabled` in the **Trusted access** column. ## Payer account and member account [AWS Organizations terminology and concepts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) describe the AWS management account as the payer account of an AWS organization that pays a consolidated invoice for all the member accounts. To find out the type of AWS account you're using, sign in to the [AWS Organizations Console](https://console.aws.amazon.com/organizations/v2/home/): - If you have the option to **Create an organization**, then you're using a standalone management account that has no associated organizations or member accounts. - If you see **AWS accounts**, **Services**, **Policies**, and **Settings** in the navigation pane, then you're using a management account of an AWS organization with member accounts. - If you see none of the above, then you're using a member account. Select **Dashboard** in the navigation pane to find the management account email address and account ID. If the email address is in a domain different from your company, you're purchasing AWS services from a reseller or a managed service provider (MSP). In such a case, you may not have access to the payer/management account. Make sure to mention this to your DoiT Contact. :::seealso - [AWS Organizations FAQs](https://aws.amazon.com/organizations/faqs/) - [DoiT consolidated billing account and dedicated payer account](https://help.doit.com/docs/amazon-web-services/import-aws-orgs#am-i-on-a-doit-consolidated-billing-account-or-a-dedicated-payer-account) ::: ## Cost data latency It takes time for your cost data to become available in the DoiT console. Below are the main points to be aware of: - After you [Create Cost and Usage Reports](https://help.doit.com/docs/amazon-web-services/enable-cur) in AWS, it can take up to 24 hours for AWS to deliver the first report to your Amazon S3 bucket. After delivery starts, AWS updates the AWS Cost and Usage Reports files at least once a day. Billing data in the DoiT console is refreshed every 6–8 hours after AWS updates the CUR file. - Different AWS services provide your usage-based billing information at different times. Sometimes there is a delay (up to 3 days) in usage reporting. - If you request a backfill of your cost data with AWS, it can take 24 hours for AWS to push the data to your S3 bucket. - CUR files received in the S3 bucket in your DoiT account are discovered by the platform within 15 minutes upon arrival. - In normal circumstances, after a CUR file is discovered by the platform, it takes about 6 hours for the cost data to become available in the DoiT console. To sum up, if the S3 bucket that stores CUR files is created in your DoiT account, after a cost is incurred, it typically takes 24–72 hours for the usage data to become available in the DoiT console. :::seealso AWS Documentation: [Report timeline](https://docs.aws.amazon.com/cur/latest/userguide/how-cur-works.html#cur-timeline) ::: ## Cost incurred by the DoiT role The AWS IAM role associated with the DoiT console performs certain actions that may incur costs, such as accessing S3 buckets for cost and usage data or querying the AWS Cost Explorer API to enable advanced FinOps capabilities. You may see a small charge for these services, even if you're not actively using them. In such a case, you can run a [Cloud Analytics report](https://help.doit.com/docs/cloud-analytics/reports) to check the charges: ![S3 and AWS Cost Explorer API costs](@site/assets/png/doit-aws-s3-cost-explorer-costs.png) --- URL: https://help.doit.com/docs/amazon-web-services/aws-rootguard # DoiT RootGuard ## What is RootGuard? As an AWS partner, we are required to monitor specific activities within the management account. RootGuard, DoiT's solution, fulfills this monitoring obligation by tracking root user activity, billing modifications, and contact information changes. ## Architecture ![DoiT RootGuard client side architecture](@site/assets/png/doit-rootguard-architecture.png) RootGuard operates through two key components: * An AWS EventBridge rule that monitors the default event bus using specific event patterns to detect targeted activities. * A Lambda function that runs on a six-hour schedule. This function verifies existence of at least one CloudTrail and reports the state back by publishing a custom event to the event bus. :::note RootGuard requires an active CloudTrail in the US East (N. Virginia/us-east-1) region to function properly. Most events are only available through CloudTrail logs. ::: The RootGuard Cloudformation template can be accessed from [here](https://doit-rootguard.s3.amazonaws.com/rootguard.template). ## Events In addition to monitoring **all** activities performed by the [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html), RootGuard collects the following events: | Event|EventSource| |------|-----------| | PutContactInformation|account.amazonaws.com| | DeleteAlternateContact|account.amazonaws.com| | PutAlternateContact|account.amazonaws.com| | SetContactAddress|billingconsole.amazonaws.com| | SetDefaultPaymentMethod|billingconsole.amazonaws.com| | SetAdditionalContacts|billingconsole.amazonaws.com| | SetAccountPreferences|billingconsole.amazonaws.com| | AWSPaymentPortalService.ValidatePaymentInstrumentOperation|billingconsole.amazonaws.com| | CreatePaymentInstrument|aws-payment-encryption.amazonaws.com| | Preferences_CreatePaymentProfile|payments.amazonaws.com| | Preferences_UpdatePaymentProfile|payments.amazonaws.com| | Instruments_Create|payments.amazonaws.com| | Instruments_Update|payments.amazonaws.com| | DeleteTaxRegistration|tax.amazonaws.com| | CreateCustomerCase|taxconsole.amazonaws.com| | PreviewTaxRegistrationChange|taxconsole.amazonaws.com| | Healthcheck|rootguard.doit.com| --- URL: https://help.doit.com/docs/amazon-web-services/create-an-aws-account # Create an AWS account You can create a new AWS account directly from the console. :::note You need access to the [Billing Profile](https://help.doit.com/docs/billing/billing-profiles) that manages your domain. ::: ## Create a new account To create a new account: 1. Sign in to the DoiT console, select **Data ingestion and integrations** > **Integrations** from the top navigation mega menu. 1. Search for **Amazon Web Services** in the integrations catalog. 1. Select **Assets** on the integration card. 3. Select **Create account** and provide the necessary information. ![The Amazon Web Services assets page.](@site/assets/png/aws-assets-page.png) - **Billing profile**: Choose the [billing profile](https://help.doit.com/docs/billing/billing-profiles) that defines how the new account is to be billed. This field is visible only if you have more than one _active_ billing profile. - **Payer account**: Choose the DoiT reseller payer account for the new account. This field is configurable only if you are on more than one DoiT reseller payer account. - **Account name**: Enter a name for the new AWS account. - **Root email**: Enter an email address in your domain. Use a corporate email distribution list or email box if your account is a professional AWS account. Avoid using an individual's corporate email address. See the [AWS Knowledge Center article](https://aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/) for more information. :::caution When creating a new account in the console, AWS automatically creates an IAM role named `OrganizationAccountAccessRole`. This role gives DoiT full administrator access in the new account. We suggest you to keep the **Delete AWS Organization role** checkbox selected to prevent unnecessary access from the DoiT account. ::: 4. Select **Create**. You will see a message confirming the creation of the new account. You will also get an email with further instructions. If you need further assistance, open an expert inquiry. --- URL: https://help.doit.com/docs/amazon-web-services/enable-cur # Enable CUR in AWS We recommend enabling Cost and Usage Reports (CUR) for your AWS accounts before you start the onboarding process with DoiT. This ensures you have a comprehensive copy of your AWS usage data. There is no charge for enabling CUR; storing the billing data in your Amazon S3 bucket is billed at standard Amazon S3 rates. Starting June 2026, the platform defaults to CUR 2.0 when onboarding new AWS accounts. [Legacy CUR exports](https://docs.aws.amazon.com/cur/latest/userguide/dataexports-create-legacy.html) are still supported but not recommended. ## Supported formats We support the following CUR file types: - CSV - Parquet ## Create CUR and request a backfill To request data for the past 12 months: 1. Sign in to the [AWS Billing and Cost Management console](https://console.aws.amazon.com/billing/home#/) as an IAM user with administrator and billing privileges, or the root user of your organization's management account, which is the payer account of your organization. 1. Click this hyperlink to deploy our AWS CloudFormation stack: [DoiT-CUR-Backfill-Stack](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?templateURL=https://doit-cur-data-ingestion.s3.amazonaws.com/DoiT-CUR-Backfill-Stack.yaml). 1. Provide a name for the stack and the bucket, as an input to the stack. This will create all required resources and request the backfill. ## Verify the backfill Historical data backfill takes time to complete. We suggest waiting for 1 to 24 hours before checking the bucket. 1. Sign in to the [AWS S3 Console](https://s3.console.aws.amazon.com/s3/). 1. Select the bucket that you created to receive the reports. AWS stores reports in the `REPORT-PREFIX/REPORT-NAME` folder. Your report should be under the `billing/aws-usage-report` folder. :::note AWS delivers all reports in a report date range in the same `billing/aws-usage-report/YYYYMMDD-YYYYMMDD` folder. See [Amazon S3 organization and naming conventions](https://docs.aws.amazon.com/cur/latest/userguide/understanding-report-versions.html#keeping-previous-cur) for details. ::: See also [Cost data latency](https://help.doit.com/docs/amazon-web-services/aws-orgs-concepts#cost-data-latency). ## `DoiT-CUR-Backfill-Stack` YAML template This CloudFormation YAML template creates AWS resources to manage and automate the AWS Cost and Usage Report (CUR), and start the cost allocation tag backfill process. ### Parameters - `BucketName` - **Type**: `STRING` - **Description**: Specifies the name of the Amazon S3 bucket to store the AWS Cost and Usage Report. ### Resources - `MyCURReportBucket` - **Type**: `AWS::S3::Bucket` - **Description**: Creates an Amazon S3 bucket to store the AWS Cost and Usage Report. - **Properties**: - `BucketName`: Specifies the name of the S3 bucket. - `AccessControl`: Sets access control for the bucket to BucketOwnerFullControl. - `VersioningConfiguration`: Configures bucket versioning, currently suspended. - `CURReportBucketPolicy` - **Type**: `AWS::S3::BucketPolicy` - **Description**: Attaches a bucket policy to the CUR report bucket to allow access for the billingreports service. - **Properties**: - `Bucket`: References the created S3 bucket. - `PolicyDocument`: Defines permissions for the bucket policy. - `CURReport` - **Type**: `AWS::CUR::ReportDefinition` - **Description**: Defines the AWS Cost and Usage Report settings. - **Depends on**: `CURReportBucketPolicy` - **Properties**: - `ReportName`: Specifies the name of the CUR report. - `TimeUnit`: Sets the time unit for the report to `HOURLY`. - `Format`: Sets the format of the report to text or CSV. - `Compression`: Specifies GZIP compression for the report. - `AdditionalSchemaElements`: Includes resource usage details in the report. - `S3Bucket`: References the S3 bucket for storing the report. - `S3Region`: Specifies the region for the S3 bucket. - `S3Prefix`: Defines the prefix for the report files. - `RefreshClosedReports`: Enables refreshing of closed reports. - `ReportVersioning`: Specifies to create a new report version. - `CostAllocationTagBackfillFunction` - **Type**: `AWS::Lambda::Function` - **Description**: Lambda function to start the cost allocation tag backfill process. - **Depends on**: `CURReport` - **Properties**: - `Handler`: Specifies the entry point for the Lambda function. - `Role`: Specifies the IAM role for the Lambda function. - `Code`: Includes the Lambda function code and installs the necessary dependencies (`boto3`). - `Runtime`: Sets the runtime environment to Python 3.8. - `LambdaExecutionRole` - **Type**: `AWS::IAM::Role` - **Description**: IAM role for the Lambda function. - **Properties**: - `AssumeRolePolicyDocument`: Specifies the trust policy for the role. - `Policies`: Defines permissions for the Lambda execution role. - `BackfillCustomResource` - **Type**: `Custom::CostAllocationTagBackfill` - **Description**: Custom resource to trigger the cost allocation tag backfill process. - **Properties**: - `ServiceToken`: References the Lambda function to execute the backfill process. ### Outputs - `BackfillStatus` - **Description**: Status of the cost allocation tag backfill process. - **Value**: References the response from the custom resource. ### What's next The CloudFormation YAML template may trigger AWS Security Hub Findings, for example, S3 buckets should require requests to use Secure Socket Layer and S3 buckets should have Lifecycle configurations. You can remediate these findings by: - Enforcing Secure Sockets Layer (SSL) for access to the S3 bucket. - Configuring a lifecycle policy. --- URL: https://help.doit.com/docs/amazon-web-services/import-aws-orgs # AWS onboarding This page explains the onboarding process if you prefer to preserve your own AWS Organization after signing up with DoiT. Except for the payment method and tax settings, which will be handled by the DoiT team, this process is self-service. You can always request our assistance if needed! ## Step 1 — Readiness (by the Customer) After signing a contract with DoiT, you will receive an overview of [our onboarding process](https://drive.google.com/file/d/1aTeirN5pvYj1fXvGiQ-kyjNrMkNMeJta/view?usp=sharing) from the DoiT Account Executive team, who will also guide you through the readiness phase. Here is what to expect: 1. Identify the AWS management account in your AWS organization (formerly known as Master Payer Account). 2. Ensure all [AWS organizations features are enabled](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html). 3. Notify your Account Executive about completing the steps above. ## Step 2 — Self-service Onboarding (by the Customer) Watch the short video below or follow the step-by-step instructions. 1. Within the `us-east-1` region, [import one of the available Service Catalog portfolios](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_sharing.html) using the portfolio ID. :::note Make sure you are importing the portfolio in the `us-east-1` region. Otherwise, the portfolio will fail to import. ::: 2. [Grant access to your AWS principal](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_users.html) on the `DoiT-Onboarding-*` Service Catalog portfolio. 3. [Launch](https://docs.aws.amazon.com/servicecatalog/latest/userguide/enduser-launch.html) the `mpa-access` Service Catalog product. Below are the available options: | Option | Description | Supported values | Default | |------------------|---------------------------------------------------------|------------------|----------| | PayerAccountType | Do not change unless you are asked to by the DoiT team. | standard, nra | standard | 4. [Launch](https://docs.aws.amazon.com/servicecatalog/latest/userguide/enduser-launch.html) the `mpa-onboarding` Service Catalog product. Below are the available options: | Option | Description | Default | |------------------|-------------------------------------------------------------------------------------------------------------|---------| | countryCode | Country Code to set the correct contact details on the AWS Account, provided by your DoiT Account Executive | - | | deployAwsOrg | Create an AWS Organization, or import the existing one and enable all AWS organization's features. | true | | deployCloudTrail | Deploys an AWS CloudTrail Trail and S3 Bucket used as Destination. | true | | isNra | Special setting for onboardings. Please change only if asked to. | false | | payerId | DoiT internal payer ID, provided by your DoiT Account Executive. Must follow the schema [0-9]. | - | ## Step 3 — Account Configuration (by the DoiT AWS Ops team) 1. Complete the organization email verification process (necessary because the management account root user email has changed). 2. Reset the AWS management account root user password. 3. Onboard the organization to SPP using the AWS Channel Management dashboard. 4. Replace the existing payment method with a DoiT payment method. 5. Set the tax profile to the country matching DoiT's billing profile. ## FAQ ### Will anything break during the process? No, the process was designed to be disruption-free. ### What's the impact on AWS Organizations features? All AWS Organization features (AWS SSO, AWS Backup, AWS Firewall Manager, Resource Manager, etc.) will continue to function in the same way as before. ### Where can I find the IAM policies for the roles you create on the management account? Before installing anything, you can review the resources that will be created using one of the following methods: - Reviewing the CloudFormation stack that the AWS Service Catalog products are going to install before launching the products. - Creating an [AWS Service Catalog launch plan](https://docs.aws.amazon.com/servicecatalog/latest/userguide/launch-plan.html), which will provide you with a computed preview of the resources. ### What permissions do I need to perform the self-service onboarding? Please refer to the up-to-date [minimum required IAM permissions](https://doit-nra-onboarding-access.s3.eu-central-1.amazonaws.com/nra-onboarding-access.json). ### What if I need to access the management account using root user credentials after onboarding? We provide an IAM administrator role for you to perform daily admin tasks and access AWS resources. This is in line with the AWS [Best practices to protect your account's root user](https://docs.aws.amazon.com/accounts/latest/reference/best-practices-root-user.html#bp-root-limit-tasks). In case you need to perform [Tasks that require root user credentials](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html), open an expert inquiry to request DoiT to carry out the tasks. See [AWS management account root user credentials](https://help.doit.com/docs/amazon-web-services/mpa-root-credentials) for more information. ### Am I on a DoiT consolidated billing account or a dedicated payer account? If your account is a member account of one of the three consolidated payer accounts listed below, then you're on a DoiT consolidated billing account. | Payer account ID | Payer account name | | :--------------- | :------------------ | | `561602220360` | `doitintl-payer-01` | | `017920819041` | `doitintl-payer-02` | | `279843869311` | `doitintl-payer-07` | If your account is on a DoiT reseller payer account other than the three listed above, then you're on a dedicated payer account. See also [Payer account and member account](https://help.doit.com/docs/amazon-web-services/aws-orgs-concepts#payer-account-and-member-account). --- URL: https://help.doit.com/docs/amazon-web-services/invite-existing-aws-account # Invite an AWS account You can invite existing AWS accounts to your DoiT payer account using the DoiT console. DoiT payer accounts are AWS management accounts used by DoiT for billing administration on customer organizations. Their AWS account names follow the naming convention `doitintl-payer-{id}`. ## Required permission Your DoiT account must have the **Assets manager** permission. You need access to the [Billing Profile](https://help.doit.com/docs/billing/billing-profiles) that manages your domain. ## Invite an existing account To invite an existing AWS account: 1. Sign in to the DoiT console, select **Data ingestion and integrations** > **Integrations** from the top navigation mega menu. 1. Search for **Amazon Web Services** in the integrations catalog. 1. Select **Assets** on the integration card. 1. Select **Invite account** and provide the necessary information. ![The Amazon Web Services assets page](@site/assets/png/aws-assets-page.png) - **Billing profile**: Choose the [billing profile](https://help.doit.com/docs/billing/billing-profiles) that defines how the invited account is to be billed. This field is visible only if you have more than one _active_ billing profile. - **Payer account**: Choose the DoiT reseller payer account for the invited account. This field is configurable only if you are on more than one DoiT reseller payer account. - **AWS Account ID**: Enter the [12-digit AWS account ID](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindAccountId) of the invited account. You can also add notes to include in the invitation email. 1. Select **Invite**. You should then receive an email from Amazon Web Services with a link to accept the invitation. If you haven't received the email in five minutes, re-enter your AWS account ID in the DoiT console and send the invitation again. To complete the process: 1. Sign in to the [AWS Organizations Console](https://console.aws.amazon.com/organizations/). Your open invitations to join organizations are shown on the **Invitations** page. 1. Accept the invitation. You will be redirected to the **Organization overview** page with details about the organization that your account has joined, including the organization's ID and the owner's email address. ### Multiple accounts under a management account If you have multiple accounts under a management account (formerly known as master account), you will get an error trying to accept the invitation. To solve the problem, you need to remove the linked AWS accounts from your management account (see [AWS documentation](https://aws.amazon.com/organizations/faqs/) for more information). For each linked account: 1. Leave the organization (no new invitation will appear before you finish this step). :::note You'll be prompted to enter payment details for the account if you haven't done so. ::: 1. Accept the invitation from DoiT International. ### Complete IAM Access for CloudHealth If you're on a [DoiT consolidated billing account](https://help.doit.com/docs/amazon-web-services/import-aws-orgs#am-i-on-a-doit-consolidated-billing-account-or-a-dedicated-payer-account), after accepting the invitation in the AWS Console, you'll receive a final email about how to [Set up CloudHealth](https://help.doit.com/docs/amazon-web-services/set-up-cloudhealth). ### Check the account Once the DoiT operations team finishes onboarding the account in DoiT systems, the account will appear automatically in **Assets** in the DoiT console. Sign in to the DoiT console, select **Data ingestion and integrations** > **Integrations** from the top navigation mega menu. If you are on a [DoiT consolidated billing account](https://help.doit.com/docs/amazon-web-services/import-aws-orgs#am-i-on-a-doit-consolidated-billing-account-or-a-dedicated-payer-account), your account needs to have at least one resource with some spend. Your AWS account appears after you have [set up CloudHealth](https://help.doit.com/docs/amazon-web-services/invite-existing-aws-account#complete-iam-access-for-cloudhealth) and the DoiT operations team have associated your account. It may take 24-48 hours to appear after the DoiT team finishes the association. See also [Amazon Web Services](https://help.doit.com/docs/integrations/aws). ## FAQ ### Why should I use the platform for cost analytics when there is the AWS Cost Explorer? When you consolidate with the DoiT International billing organization, the [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) can only report on [blended rates and costs](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/con-bill-blended-rates.html#Blended_CB), while the platform's reporting and analytics features work directly with your non-blended cost data. If you have a dedicated billing account (i.e., non-consolidated), you can use the AWS Cost Explorer with un-blended costs. However, we still recommend that you refer to the platform for a fully integrated reporting and analytics experience. ### I've performed all the requested steps and have spends on my AWS billing account, why my information is still not there? In normal circumstances, it takes 24–72 hours for the data to start flowing through from AWS, then the platform will update. ### I haven't received any invitation email. What could have gone wrong? Sign in to the [AWS Organizations Console](https://console.aws.amazon.com/organizations/), see if there are invitations on your organization's page. - If there are no invitations, check if your account have left your organization as described at [Multiple accounts under a management account](#multiple-accounts-under-a-management-account). - If you can see the invitation on the organization's page, consider the following: - Is the invitation in your spam folder? - Did you enter the correct AWS account ID when inviting the account? If you still have issues, open an expert inquiry. ### My payer account is showing as N/A or my CloudHealth status shows as "critical" or "unknown". What does that mean? It means that your CloudHealth is not configured properly, which has the following consequences: - The platform cannot properly reflect your reservation data, and you cannot use the Flexsave and PerfectScale for Spot services. - You will not be able to run reports on this asset because no data is flowing to the platform. Open an expert inquiry with our support team. ### I want historical backfill. What should I do? We support the backfill of historical data on dedicated payer accounts. Open an expert inquiry with our support team. ### Why do my Cloud Analytics reports not match the figures reported by the AWS Cost Explorer? To understand discrepancies between Cloud Analytics reports and AWS Cost Explorer, try using the [Invoice Explainer](https://help.doit.com/docs/billing/billing-explained/invoice-explainer). If you need further clarification or assistance, please open an expert inquiry. --- URL: https://help.doit.com/docs/amazon-web-services/mpa-access-for-doit-agents # AWS management account access for the DoiT Customer Solutions Team As an AWS reselling partner, we require access to your management account (or master payer account, a.k.a. MPA) to manage the billing elements of your organizations to set up and monitor our reselling partner payment methods. In addition, access to your management account allows us to offer AWS Partner-Led Support for your organization. ## Key points - For the DoiT Customer Solutions Team access, we leverage the same technology that we use [to access AWS member accounts](https://help.doit.com/docs/consulting-support/aws-access). - DoiT logs every access attempt with the related requested permissions and retains these logs for 365 days. - The DoiT Customer Solutions Team requires that access to intervene directly with AWS support if you opt in to an AWS Partner-Led Support plan. - Your DoiT account team uses that access to proactively advise you about potential savings. - As of March 2024, the required components are already installed on your management account through our [AWS onboarding procedure](https://help.doit.com/docs/amazon-web-services/import-aws-orgs), specifically via the AWS Service Catalog Product named `mpa-access`, which manages the `doit-support-gateway` CloudFormation Stack in the `us-east-1` region. ## Required components installed on the management account We only require the following resources to be installed on your AWS management account: - Two AWS IAM Identity providers to federate DoiT-managed identities. - One AWS IAM support role named `DoiT-Support-Gateway` to allow access from the identities mentioned above. - (Optional) One AWS IAM role named `SupportDiagnostics` to leverage [AWS Partner-Led Support diagnostic tools](https://docs.aws.amazon.com/diagnostic-tools/latest/userguide/what-is-aws-diagnostic-tools.html). ## Permissions granted to DoiT on the management account: You can review the permissions we require at any time directly in [our public CloudFormation Stack template](https://doit-support.s3.amazonaws.com/doit-support-mpa.json). --- URL: https://help.doit.com/docs/amazon-web-services/mpa-root-credentials # AWS management account root user credentials The AWS management account is the account used to create the AWS organization. It is a payer account and pays all charges accrued by the member accounts (see [AWS Organizations terminology and concepts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)). DoiT co-owns the root user credentials of the AWS management account (formerly known as Master Payer Account (MPA)) for billing administration. We do not require access to root users of any AWS member accounts. ## Why does DoiT hold the AWS management account root user credentials? DoiT holds the root user credentials of the AWS management account, which is the payer account of the AWS organization, for billing administration. Amazon requires its partners such as DoiT to use root user credentials of a payer account when communicating with Amazon for billing issues. In addition, we set the management account root user's email address to a unique DoiT-owned email account. This email is a distribution list, and you can add email addresses owned by your organization to this group. This ensures that you continue to receive all emails sent to the root account. Our expert inquiry system automatically creates and updates requests according to emails sent to that specific address. This allows our Forward Deployed Engineering (FDE) team to share account updates with you, as our customer, through expert inquiries. ## Co-ownership of the AWS management account root user credentials DoiT co-owns the root user credentials with our customers in our new approach to enhance security and transparency. This means that both DoiT and you have access to the root user credentials, providing an additional layer of security and control for you. ## How is my team impacted? DoiT uses the management account root user credentials solely for billing administration. We provide you with root user access so that you can create an IAM role and manage the access to that account for your company. All access requests to the management account should be handled internally within the company. This aligns with the AWS [Best practices to protect your account's root user](https://docs.aws.amazon.com/accounts/latest/reference/best-practices-root-user.html#bp-root-limit-tasks). ## How does DoiT secure and store the management account root user credentials? DoiT stores the management account root user credentials in a secure vault. Only a specific group of DoiT employees has access to the secure vault. We audit the access and constrain it to performing [Tasks that require root user credentials](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). In case you end the partnership with DoiT, we transfer the ownership of the credentials back to you. After we update the root user credentials of the AWS management account to a DoiT email address, we deal with the password and enable multi-factor authentication (MFA) on the AWS management account. We also encrypt the new password and vault it using specialized software. There are two scenarios in which we handle the password: - You want to keep your existing password. We will send you a secure one-time link. You can use the link to share the password with us. - You want to change your password. We will send you a securely generated password via a one-time link. In both scenarios, we make sure that the credentials are handled securely. DoiT operates on the highest level of industry security standards. See DoiT compliance offerings for our certifications and compliance standards. ## How does DoiT release management account root user credentials? As part of our co-ownership policy, customers already have access to the root user credentials. This co-ownership provides an additional layer of security and control for the customer. There are two additional scenarios: - Closure of an account - Reverse assumption (customers taking billing ownership of accounts) If you close an account, the root user credentials lead to a _dead end_. They do not need to be destroyed by DoiT. If you terminate management services with DoiT, we follow the _reverse assumption_ process, which includes changing the root user credentials to those defined by you as the customer. ## Usage of Root User Credentials DoiT uses root user credentials sparingly. They are primarily used during onboarding and only when necessary to communicate with AWS for billing issues. For all regular activities, we utilize IAM roles, which align with AWS best practices for account security. This approach ensures that root user credentials are not exposed to unnecessary risks. --- URL: https://help.doit.com/docs/amazon-web-services/set-up-cloudhealth # Set up CloudHealth :::tip CloudHealth is available only to customers in the DoiT shared Amazon Web Services (AWS) organizations under the management accounts (formerly known as Master Payer Account) `561602220360`, `017920819041`, and `279843869311`. ::: Follow the instructions below to set up [CloudHealth](https://www.cloudhealthtech.com) for your new or existing AWS account linked to DoiT International consolidated billing. ## Sign in to the AWS Management Console Sign in to the AWS account to be integrated with CloudHealth. You need to use an IAM account that has the permission to create AWS IAM roles and policies. ## Create an AWS IAM Policy 1. Navigate to [IAM Policies](https://console.aws.amazon.com/iam/home?region=us-east-1#/policies) and select **Create policy**. 1. Switch to the JSON tab and replace the existing content with [this JSON policy](https://storage.googleapis.com/hello-static-assets/cloudhealth/iam-policy.json): 1. Select **Review Policy** and set the policy name to _CloudHealth_. 1. Select **Create Policy**. ## Create an IAM Role 1. Navigate to [IAM Roles](https://console.aws.amazon.com/iam/home?region=us-east-1#/roles) and select **Create Role**. 1. Select **AWS Account** as the trusted entity type. 1. Provide `454464851268` as the Account ID. 1. Select **Require external ID** and paste `6cda262029ad7b34a64ff537196ab4`. 1. Select **Next: Permissions**. Search and select _CloudHealth_ IAM Policy. 1. Select **Next: Tags**. 1. Select **Next: Review**. Set Role Name to _CloudHealth_. 1. Select **Create Role**. :::seealso - [CloudHealth incurred costs](#cloudhealth-incurred-costs) ::: ## Create Users The first user will be an administrator we create for you. An admin will be able to create more users and administrators in the [CloudHealth Interface](https://apps.cloudhealthtech.com/users). If you need further assistance, open an expert inquiry. ### Single Sign-On If you have enabled SSO in CloudHealth, you will not be able to add users with usernames and passwords. You must first add them to the proper role group within the IdPs directory. See [AWS Single Sign-On Service Integration Guide For CloudHealth](https://blogs.vmware.com/cloudhealth/aws-single-sign-on-service-integration-guide-for-cloudhealth/) for more information. ## CloudHealth incurred costs The role assumed by CloudHealth performs certain activities that incur costs. For example, the CloudHealth role may need to collect the Cost and Usage Reports from your account and add them to a S3 bucket. The costs incurred by the CloudHealth role are usually small. Below is an example invoice issued to a fictitious customer who was not using AWS services otherwise. ![CloudHeath incurred costs on a monthly AWS invoice.](@site/assets/png/cloudhealth-charge-invoice.png) You can run a [Cloud Analytics report](https://help.doit.com/docs/cloud-analytics/reports) to understand the cost and usage: - with the **Cost** metric: ![CloudHeath incurred costs in report.](@site/assets/png/cloudhealth-charge-report-cost.png) - with the **Usage** metric: ![CloudHeath usage in report.](@site/assets/png/cloudhealth-charge-report-usage.png) --- URL: https://help.doit.com/docs/amazon-web-services/update-aws-iam-policies # Update access permissions for AWS Billing, Cost Management, and Account Consoles ## Changes to access permissions On January 2023, AWS announced the replacement of IAM actions for the Billing, Cost Management, and Account Consoles under the service prefix `aws-portal` and the `purchase-orders:ViewPurchaseOrders` and `purchase-orders:ModifyPurchaseOrders` actions with new fine-grained service specific permissions. If your AWS account has IAM policies that use the retired actions, you may have already received a message from AWS in your root user email address of the account (the email address provided when creating the account), reminding you to update your policies for continued access to Billing, Cost Management, and Account Console, titled: **`[Action required][Reminder] Update your policies for continued access to Billing, Cost Management, and Account consoles [AWS Account: ]`** You may also see a similar notice in the [IAM Console](https://us-east-1.console.aws.amazon.com/iamv2/home?region=us-east-1#/home). :::seealso For the full announcement, see the AWS blog [Changes to AWS Billing, Cost Management, and Account Consoles Permissions](https://aws.amazon.com/blogs/aws-cloud-financial-management/changes-to-aws-billing-cost-management-and-account-consoles-permissions/). ::: ## Update affected policies To update the affected policies: 1. Log in to your AWS account and access the [Affected Policy console](https://us-east-1.console.aws.amazon.com/poliden/home?region=us-east-1#/). 1. You'll see detailed step-by-step instructions with a table that lists all IAM policies that reference the retired actions. ![Manage new IAM actions](@site/assets/png/aws-iam-policies-to-update.png) - If a policy has _no_ `CloudHealth` in its name, select **Copy** to copy the updated policy and then select **Edit** to edit the policy in IAM Console. - If a policy has `CloudHealth` in its name, copy the [DoiT CloudHealth JSON Policy](https://storage.googleapis.com/hello-static-assets/cloudhealth/iam-policy.json) and then select **Edit** to replace the existing policy with it. 1. Go back to the [Affected Policy console](https://us-east-1.console.aws.amazon.com/poliden/home?region=us-east-1#/) and verify that there are no policies to be updated. --- URL: https://help.doit.com/docs/attribute/changelog # Documentation changelog This page highlights the main changes in DoiT Attribute™ documentation. ## August 2026 - Updated [Attribute overview](https://help.doit.com/docs/attribute/overview/overview) with ChannelOps Essentials availability and provisioning timeline. ## July 2026 - Added [Access Attribute from the console](https://help.doit.com/docs/attribute/overview/access-from-dci) for the launch flow with DCI SSO. - Added [Attribute Java Instrumentation Guide](https://help.doit.com/docs/attribute/integrations/cloud-integrations/attribute-java-instrumentation-guide). - Updated Terraform deployment guides for [AWS](https://help.doit.com/docs/attribute/integrations/cloud-integrations/aws/attribute-aws-deployment-guide-tf), [Azure](https://help.doit.com/docs/attribute/integrations/cloud-integrations/attribute-azure-deployment-guide-tf), and [GCP](https://help.doit.com/docs/attribute/integrations/cloud-integrations/gcp/attribute-gcp-tf-deployment-guide). - Added sensor installation for [ECS](https://help.doit.com/docs/attribute/integrations/cloud-integrations/aws/attribute-sensor-for-aws-ecs) and [Fargate Java](https://help.doit.com/docs/attribute/integrations/cloud-integrations/aws/attribute-sensor-for-aws-fargate-java). - Updated the [data flow overview](https://help.doit.com/docs/attribute/overview/attribute-data-flow). --- URL: https://help.doit.com/docs/attribute/configurations/api-documentation-including-identifiers # Attribute API Attribute API enables one to interact with the data programmatically, extract large amounts of data and integrate it with your internal systems. The following document will describe the authentication and endpoints available, response codes, and will provide some code examples for easy use of the Attribute API. ## Authentication and Authorization The authentication with the Attribute API is based on JWT (JSON Web Token). :::note For security reasons, once generated, the token cannot be recovered. Make sure you keep your token in a secure manner. ::: To generate your token, please access the Attribute Dashboard. Navigate to the `setup/api-tokens` page, where you will be able to create new tokens and manage your existing tokens. ![API Tokens page in the Attribute Dashboard](@site/assets/png/attribute/api-tokens-page.png) Click **Create Token** to open the new-token dialog. Provide a token name, description, expiration in days, and any IP restrictions, then click **Create**. ![New API Token creation dialog](@site/assets/png/attribute/new-api-token-modal.png) ## API Endpoints :::note AWS usually takes up to 48 hours to update the data, thus the earliest stable daily data is two days ago. ::: ### Granularity and Date Parameters Most endpoints below accept two path parameters that follow the same conventions: - `granularity`: `daily` to get data for a single day, or `monthly` to get data for the whole month. - `date`: The date for which to fetch the data, in the format `YYYY-MM-DD`. - When `granularity` is `daily`, the data corresponds to that specific day. Entering the current day fetches the data available so far; future dates return an empty response. - When `granularity` is `monthly`, the day part of the date is ignored and the data covers the entire month. Entering the current month fetches the previous month's data; future months return an empty response. *Example: if the date is `2026-05-06` and granularity is `monthly`, the response will include data for April 2026.* ### Healthcheck Information Checks the health of the server. - **Endpoint**: `/api/v1/health` - **Method**: `GET` - **Example**: `https://api.app.attrb.io/api/v1/health` - **Returns**: HTTP 200 if the server is healthy. ### Resources Information The Resources Information endpoint returns billing data for individual cloud resources (the billing page in Attribute's dashboard). - **Endpoint**: `/api/v1/resources/{granularity}/{date}` - **Method**: `GET` - **Example**: `https://api.app.attrb.io/api/v1/resources/daily/2025-11-10` - **Description**: Starts a job to fetch resources data. - **Parameters**: - `granularity` and `date`: See [Granularity and date parameters](#granularity-and-date-parameters). - **Query Strings**: - `includetags` (boolean, optional): If `true`, includes resource tags in the response. Default `false`. - **Returns**: `JobDescription` :::note Dashboard configurations `show $0 cost` and `show tax` are both treated as `true` in the API. ::: ### Workloads Information The Workloads Information endpoint returns billing data aggregated by workload. - **Endpoint**: `/api/v1/workloads/{granularity}/{date}` - **Method**: `GET` - **Example**: `https://api.app.attrb.io/api/v1/workloads/daily/2025-11-10` - **Description**: Starts a job to fetch workloads data. - **Parameters**: - `granularity` and `date`: See [Granularity and date parameters](#granularity-and-date-parameters). - **Query Strings**: - `includelabels` (boolean, optional): If `true`, includes resource labels in the response. Default `false`. - **Returns**: `JobDescription` ### All Customers Information The All Customers Information endpoint extracts customer insights from the Attribute platform across all cloud providers, such as the customer cost and amortized, effective, and GCP costs for the resources attributed to each customer. (For the detailed structure of the customer data, see [`AllCustomerEntryObject`](#allcustomerentryobject).) - **Endpoint**: `/api/v1/allcustomers/{granularity}/{date}` - **Method**: `GET` - **Example**: `https://api.app.attrb.io/api/v1/allcustomers/daily/2026-05-01` - **Description**: Starts a job to fetch customer data across all cloud providers. - **Parameters**: - `granularity` and `date`: See [Granularity and date parameters](#granularity-and-date-parameters). - **Returns**: `JobDescription` - **Result object**: `AllCustomerEntryObject` ### Identifiers Information The Identifiers Information endpoint returns compute cost broken down by identifier — a unit such as a customer, project, or country running on a shared cluster. This lets you see how a single cluster's cost splits across business units based on each identifier's share of requests. > **Availability:** AWS data only, and only for customers who have multiple units configured through sensor identifiers. For other customers, cost is reported through the standard customer cost flow (see [All Customers Information](#all-customers-information)). - **Endpoint**: `/api/v1/identifiers/{granularity}/{date}` - **Method**: `GET` - **Example**: `https://api.app.attrb.io/api/v1/identifiers/daily/2026-06-02` - **Description**: Starts a job to fetch identifiers cost data. - **Parameters**: - `granularity`: daily to get data for a single day (this endpoint supports daily granularity only) - `date`: See [date parameters](#granularity-and-date-parameters). - **Returns**: `JobDescription` #### Cost Calculation Types Each workload + identifier combination is returned four times, once per `cost_calculation_type`. The type encodes two independent dimensions: - **Anonymous costs** — whether the cost share of requests with no identifier is kept as-is, or redistributed across the identified groups. - **Unallocated costs** — whether billing costs that could not be attributed to any workload are excluded or distributed across workloads. | `cost_calculation_type` | Anonymous costs | Unallocated costs | |---|---|---| | `with_anonymous_without_unallocated` | Kept | Excluded | | `with_anonymous_with_unallocated` | Kept | Distributed | | `without_anonymous_without_unallocated` | Redistributed to identified groups | Excluded | | `without_anonymous_with_unallocated` | Redistributed to identified groups | Distributed | ### AI Cost Information The AI Cost Information endpoint retrieves AI cost from all clouds and direct providers — Bedrock, Vertex AI, OpenAI, Azure OpenAI, and Anthropic. - **Endpoint**: `/api/v1/aicost/{granularity}/{date}` - **Method**: `GET` - **Example**: `https://api.app.attrb.io/api/v1/aicost/monthly/2025-11-01` - **Description**: Starts a job to fetch AI cost data. - **Parameters**: - `granularity` and `date`: See [Granularity and date parameters](#granularity-and-date-parameters). - **Returns**: `JobDescription` - **Result object**: ```json { "results": [ { "granularity": "MONTHLY", "data_date": "2026-03-01", "cloud_provider": "OpenAI", "resource_type": "OpenAI", "resource_name": "attribute-cyopcu/gpt-5.2-2025-12-11", "token_type": "Output Tokens", "amortized_cost": 0.088521999999999976, "unblended_cost": 0.088521999999999976 } ] } ``` ### OpenAI Information The OpenAI Information endpoint retrieves OpenAI-related insights per Customer and Workload from the Attribute platform. Results are returned only if you have a native OpenAI integration in AWS configured, including a customer identifier. - **Endpoint**: `/api/v1/reports/openai/{granularity}/{date}` - **Method**: `GET` - **Example**: `https://api.app.attrb.io/api/v1/reports/openai/monthly/2025-11-01` - **Description**: Starts a job to fetch OpenAI data. - **Parameters**: - `granularity` and `date`: See [Granularity and date parameters](#granularity-and-date-parameters). - **Returns**: `JobDescription` - **Result object**: ![Example OpenAI result object](@site/assets/png/attribute/openai-result-example.png) ## Job Management Every data endpoint above returns a `JobDescription` with an `id`. Use the endpoints below to track and retrieve the job's results. ### Job Status - **Endpoint**: `/api/v1/job/{jobid}/status` - **Method**: `GET` - **Example**: `https://api.app.attrb.io/api/v1/job/{jobid}/status` - **Description**: Retrieves the `JobDescription` for a specific job with its status. - **Parameters**: - `jobid`: The ID of the job. - **Returns**: `JobDescription` ### Fetch - **Endpoint**: `/api/v1/job/{jobid}/fetch` - **Method**: `GET` - **Example**: `https://api.app.attrb.io/api/v1/job/{jobid}/fetch` - **Description**: Fetches the results of a completed job. - **Parameters**: - `jobid`: The ID of the job. - **Query Strings**: - `maxResults` (int, optional): Maximum number of objects inside `JobData.results` to fetch. - `token` (int, optional): Token for pagination. - **Returns**: `JobData` ## Status Codes Attribute API uses standard HTTP status codes: | Code | Meaning | Description | |------|---------|-------------| | `400` | Bad Request | Failed to parse request parameters | | `401` | Unauthorized | Request is not authorized | | `404` | Not Found | Job is not completed or no data was found | | `429` | Rate Limit | Too many requests were made for a single org | | `500` | Internal Server Error | Server errors | ## Data Structures ### JobDescription | Field | Description | |-------|-------------| | `id` | Job ID | | `status` | Job status: `pending`, `running`, `completed`, `failed` | | `reason` | Failure reason (applicable for `failed` status, optional) | | `lastUpdate` | Unix timestamp of last status update | ### JobData | Field | Description | |-------|-------------| | `results` | List of result objects | | `nextToken` | Optional integer for pagination — absent on the final page of results | ### AllCustomerEntryObject | Field | Description | |---------------|-------------| | `customer_name` | Customer identifier | | `organization_id` | Attribute organization identifier | | `granularity` | Granularity of the data: `DAILY` or `MONTHLY` | | `data_date` | The date of the data | | `execution_date` | The date the job was executed | | `data` | Attribution data list | | `data[].resource` | Resource identifier object | | `data[].resource.cloud_provider` | Cloud provider type (e.g. `AWS`, `Azure`, `GCP`) | | `data[].resource.account_id` | Attribute account ID | | `data[].resource.customer_rule_identifier` | Attribution rule identifier | | `data[].resource.resource_name` | Resource name (e.g. EKS cluster name) | | `data[].resource.resource_type` | Type of resource (e.g. `EC2-EKS`) | | `data[].resource.resource_region` | Region of the resource (e.g. `us-east-1`) | | `data[].cost` | Attributed cost object | | `data[].cost.amortized_cost` | Amortized cost value (AWS, MongoDB® Atlas, OpenAI) | | `data[].cost.effective_cost` | Effective cost value (Azure) | | `data[].cost.gcp_cost` | Cost value (GCP) | ## Code Examples **Request to the customers API for the daily data on 2026-05-01:** ```bash curl -X GET "https://api.app.attrb.io/api/v1/allcustomers/daily/2026-05-01" \ -H "Accept: application/json" \ -H "Authorization: Bearer " ``` **Response with the `JobDescription` for the created job:** ```json { "id": "7a116c30-e245-43cb-b451-f099e84ffdeb", "status": "pending", "lastUpdate": 1741012038 } ``` **Request for the status of Job ID `7a116c30-e245-43cb-b451-f099e84ffdeb`:** ```bash curl -X GET "https://api.app.attrb.io/api/v1/job/7a116c30-e245-43cb-b451-f099e84ffdeb/status" \ -H "Accept: application/json" \ -H "Authorization: Bearer " ``` **Response indicating that the job has been completed successfully:** ```json { "id": "7a116c30-e245-43cb-b451-f099e84ffdeb", "status": "completed", "lastUpdate": 1741012038 } ``` **Request for 1 row of data:** ```bash curl -sG "https://api.app.attrb.io/api/v1/job/7a116c30-e245-43cb-b451-f099e84ffdeb/fetch" \ --data-urlencode "maxResults=1" \ -H "Accept: application/json" \ -H "Authorization: Bearer " ``` **Response with a single row of data:** ```json { "results": [ { "customer_name": "acme_corp", "organization_id": "org-id", "granularity": "DAILY", "data_date": "2026-05-01", "execution_date": "2026-06-03", "data": [ { "resource": { "cloud_provider": "AWS", "account_id": "acct-id", "customer_rule_identifier": "Proportions", "resource_name": "prod-cluster", "resource_type": "EC2-EKS", "resource_region": "us-east-1" }, "cost": { "amortized_cost": 12.45, "effective_cost": 0, "gcp_cost": 0 } }, { "resource": { "cloud_provider": "Azure", "account_id": "azure-acct-id", "customer_rule_identifier": "Proportions", "resource_name": "vm-prod", "resource_type": "VirtualMachine", "resource_region": "eastus" }, "cost": { "amortized_cost": 0, "effective_cost": 8.30, "gcp_cost": 0 } }, { "resource": { "cloud_provider": "GCP", "account_id": "gcp-acct-id", "customer_rule_identifier": "Proportions", "resource_name": "gke-prod", "resource_type": "GKE", "resource_region": "us-central1" }, "cost": { "amortized_cost": 0, "effective_cost": 0, "gcp_cost": 5.72 } } ] } ], "nextToken": 363 } ``` --- *Trademarks: AWS is a trademark of Amazon.com, Inc. or its affiliates. Microsoft and Microsoft Azure are trademarks of the Microsoft group of companies. Google Cloud is a trademark of Google LLC. MongoDB is a registered trademark of MongoDB, Inc. OpenAI is a trademark of OpenAI. Anthropic and Claude are trademarks of Anthropic, PBC. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/configurations/okta-integration-guide # Connect to Okta SSO ## Prerequisites OIDC integration requires the following: - Access to the Attribute platform and an effective Enterprise contract. - Access to the Okta Admin dashboard and the required privileges to add an application. To configure the integration, please follow the [Configuration](#configuration) section. ## Supported Features Currently, the Okta integration supports SP-initiated SSO and IDP-initiated SSO (Single Sign-On). ## Configuration ### Okta Setup 1. Navigate to the **Applications** section of the Okta Admin dashboard, then click **Browse App Catalog**. 2. Type "**Attribute Dashboard**" in the search box, then select the result named simply "**Attribute Dashboard**" and click **Add Integration**. ![Browsing the Okta App Integration Catalog for "Attribute"](@site/assets/png/attribute/okta-app-catalog.png) 3. Configure the application and complete the configuration by clicking **Done**. 4. Go to the **Applications** section of the Okta Admin dashboard, then click on "**Attribute Dashboard**" and then on **Sign On**. 5. Under **OpenID Connect**, copy the **Client ID** and **Client secret** fields. ### Attribute Platform 1. Create a support ticket by sending an email to [support@attrb.io](mailto:support@attrb.io) titled "**Okta Integration Request**". 2. In the email's body, provide the following: 1. Organization domain name. 2. Organization's Okta Issuer (e.g. `acme.okta.com`). 3. A link to a secure file share containing the Client ID and Client secret. 3. After processing the request, a reply email will be sent confirming the integration. 4. When the integration is complete, users can sign in with Okta directly, or after entering their email on the dashboard's login page. ## SP-Initiated SSO Login 1. Navigate to the Attribute Dashboard using the login link provided during the onboarding process. 2. Enter your user email. If Okta is configured for your organization, the "**Continue with Okta**" button will become enabled. ![Attribute Dashboard login page showing Continue with Google, Sign in with Microsoft, and Continue with Okta options above an email and password form](@site/assets/png/attribute/attribute-login-page.png) 3. Click "**Continue with Okta**" and complete the login process. 4. On success, you will be redirected to the application. ## Contact If you require any additional assistance, please contact Attribute's support at [support@attrb.io](mailto:support@attrb.io). Alternatively, you can request to join a shared Slack channel for support. To request access, email [support@attrb.io](mailto:support@attrb.io) with your details. --- *Trademarks: Okta is a trademark of Okta, Inc. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/cloud-integrations/attribute-azure-deployment-guide-tf # Attribute Azure Deployment ## Install with Attribute Terraform To ensure a smooth implementation, Attribute provides a Terraform module that automates setup for billing-information extraction and sensor registration. Detailed Terraform documentation and examples can be found in the README within the Terraform module. ### Resources Created by This Module When you run the module, the following resources are created: - Resource group named `Attribute`. - Storage account to hold the billing data. - Managed Identity named `Attribute` to allow us to fetch data. - Data Export resource to facilitate data retrieval. ### Important Clarifications - Supported Terraform version is **1.9 and above**. - The module can be installed at either the Azure tenant level or Azure subscription level and will create all the required infrastructure for the Attribute solution. - To run the module, the user needs a specific set of permissions (see the full list of required permissions reproduced in step 2 of the installation instructions below). - The module **does not** deploy the Attribute sensor on the compute infrastructure. That process is done with different tools per compute cluster (see Attribute's installation guide). ## Appendix A: Detailed Installation Instructions This appendix walks you through the entire setup process at the subscription level. ### Step 1 — Billing Integration 1. Verify your Terraform version is 1.9 or above: ```bash terraform version ``` 2. Make sure you have permission to run the module. The most up-to-date list can be found in the module README. Required permissions: ```text Microsoft.Resources/subscriptions/resourceGroups/read Microsoft.Resources/subscriptions/resourceGroups/write Microsoft.Resources/subscriptions/read Microsoft.Storage/storageAccounts/read Microsoft.Storage/storageAccounts/write Microsoft.Storage/storageAccounts/listkeys/action Microsoft.Storage/storageAccounts/blobServices/containers/read Microsoft.Storage/storageAccounts/blobServices/containers/write Microsoft.Storage/storageAccounts/blobServices/read Microsoft.Storage/storageAccounts/fileServices/read Microsoft.ManagedIdentity/userAssignedIdentities/read Microsoft.ManagedIdentity/userAssignedIdentities/write Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/read Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write Microsoft.Authorization/roleAssignments/read Microsoft.Authorization/roleAssignments/write Microsoft.CostManagement/exports/read Microsoft.CostManagement/exports/write ``` 3. Update the `main.tf` file. By default, the Billing Export is created at the **subscription** scope. If you'd like to create the export at the **billing account** scope instead, see Option 2 below. **Option 1 — Running on the subscription level:** 1. Update the Terraform profile you're using so it points to the correct Azure subscription. 2. Update `subscription_id` to point to your subscription. 3. Do **not** change the `organization_id` and `token` values — leave them as is. ```hcl terraform { required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 4.0" } azapi = { source = "azure/azapi" version = ">= 2.0.0, < 3.0" } } } provider "azurerm" { features {} subscription_id = "subscription-id" } module "attribute-sensor" { source = "ZouzIO/attribute-sensor/azurerm" version = "~> 2.0" organization_id = "XXXXXXXXXXXXXXXXXXX" token = "XXXXXXXXXXXXXXXXX" } ``` **Option 2 — Create Billing Export at the billing account level:** Update the `attribute-sensor` module in `main.tf` to include the billing account ID: ```hcl module "attribute-sensor" { source = "ZouzIO/attribute-sensor/azurerm" version = "2.0.1" organization_id = var.organization_id token = var.token billing_account_id = "" } ``` **For each additional subscription**, update the module to include the following values (disabling the costs export for non-primary subscriptions): ```hcl module "attribute-sensor" { source = "ZouzIO/attribute-sensor/azurerm" version = "2.0.1" organization_id = var.organization_id token = var.token create_costs_export = false } ``` 4. Apply the Terraform: ```bash terraform init terraform apply ``` 5. **Verification.** Confirm the following resources were created: 1. An `Attribute` role. 2. A storage account. 3. The `AttributeExport` Cost Management export. ![Azure portal Roles page showing the AttributeSensorTerraform custom role with description "Custom role for deploying attribute-sensor module"](@site/assets/png/attribute/azure-tf-role-assignment.png) ### Step 2 — Sensor Implementation Next, run the sensor installation on each AKS cluster using a Helm chart. 1. Save the values file provided by Attribute (`operator-values.yaml`). This file contains a unique ephemeral token. 2. Verify your Helm version — version 3.8.0 or above is supported: ```bash helm version ``` 3. Update the `cluster_name` value in `operator-values.yaml` to match the target cluster: ```yaml cluster_name: // ``` :::note `subscription_id` and `resource_group` are for the specific cluster. If you're using different resource groups for the cluster nodes, use the **cluster** resource group, not the node resource group. ::: 4. Review the Java instrumentation settings in `operator-values.yaml`. The file includes the following flags by default: ```yaml # Java instrumentation settings sensorDisableAutoJavaInstrumentation: true javaAutoInject: enabled: true ``` This configuration is supported on Kubernetes **1.28 and above**. The injection backend is selected automatically, so no version-specific adjustment is needed. To use the sensor's dynamic Java instrumentation instead of admission-time injection, set `javaAutoInject.enabled` to `false` **and** set `sensorDisableAutoJavaInstrumentation` to `false`. The two must never be enabled together. For a full explanation of both modes, see the [Attribute Java Instrumentation Guide](https://help.doit.com/docs/attribute/integrations/cloud-integrations/attribute-java-instrumentation-guide). 5. Install the Helm chart: ```bash helm upgrade -i attribute \ oci://quay.io/attribute/operator-chart \ -f \ -n attribute \ --create-namespace ``` 6. **Verification.** Run the following to verify the Helm release and that the operator and sensor are running: ```bash helm list -n attribute kubectl get pods -n attribute ``` Example expected output: ![Terminal output of helm list -n attribute showing the attribute release deployed with the operator-chart](@site/assets/png/attribute/tf-helm-list.png) ![Terminal output of kubectl get pods -n attribute showing five attribute pods all in Running state with READY 1/1](@site/assets/png/attribute/tf-kubectl-pods.png) :::note If you'd like to deploy the sensor on other compute resource types (such as standalone), refer to the relevant sensor deployment documentation. ::: --- *Trademarks: Microsoft and Microsoft Azure are trademarks of the Microsoft group of companies. Terraform is a registered trademark of HashiCorp, Inc. Kubernetes is a registered trademark of The Linux Foundation. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/cloud-integrations/attribute-java-instrumentation-guide # Attribute Java Instrumentation Guide ## Introduction The Attribute Sensor collects traffic data at the kernel level using eBPF, which gives it visibility into application traffic without any code changes. Java applications are the one case where this is not sufficient on its own. When a Java application uses TLS, the encryption is performed by the Java platform itself rather than by a shared system library. There is no library boundary for the sensor to observe, so an encrypted Java connection appears only as ciphertext. Attribute closes this gap with the Attribute Java agent, which observes the connection inside the JVM and makes the traffic visible to the sensor for attribution. :::note This affects TLS-encrypted Java traffic only. Attribution for Java applications that communicate over unencrypted connections works with no Java agent and requires no configuration. ::: There are two ways to deliver the Java agent, and exactly one of them can be active at a time: - **Dynamic instrumentation:** The sensor attaches the agent to running JVMs on the node. Requires no application changes and no redeployment. - **Admission-time injection:** The Attribute Operator adds the agent to pods as they are created, so the agent is present from the moment the JVM starts. This guide covers Kubernetes deployments only. Java instrumentation in other environments is not covered here — contact Attribute support if you need it. ## About the Attribute Java Agent The agent is deliberately narrow in what it does. It observes the point inside the Java platform where your application's traffic is encrypted and decrypted, and makes what it sees available to the Attribute Sensor already running on the node. It instruments only the Java TLS classes your application uses, never your application's own code. It does not participate in TLS itself. It reads no keys and no certificates, registers no security provider, and has no influence on which protocol versions or cipher suites your application negotiates. It is also small, by design rather than by tuning: - **No background activity:** The agent starts no threads, opens no network connections of its own, and polls nothing. It does work only while your application is already sending or receiving data. - **A fixed memory footprint:** Buffers are allocated once and reused rather than per operation, so instrumentation adds no ongoing garbage collection pressure. Off-heap use is roughly 8 KB per application thread that carries traffic. - **Sub-microsecond cost per operation:** The work added to a read or write is a buffer copy and a local handoff, measured in tens to a few hundred nanoseconds depending on payload size. - **No configuration and no state:** The agent reads no environment variables, no system properties, and no configuration files, and keeps no state of its own. Most importantly, it is built to fail safe. Every instrumentation point is wrapped so that an error inside the agent is contained: instrumentation stops and your application carries on unaffected. The same is true if the sensor is not running — the agent simply produces nothing. Data is read only after your application's own read or write has already completed, so the agent does not change the content, ordering, or timing of your traffic. ## Requirements - A Kubernetes cluster running version **1.28 or above**. - Attribute Helm chart **0.0.96 or above**, with operator **0.0.30 or above** and sensor **0.0.284 or above**. - Helm **3.8.0 or above**. - Java **8 or above**, on Linux `x86-64` or `arm64`. - A HotSpot-based JVM: OpenJDK, Eclipse Temurin, Amazon Corretto, Azul Zulu, or GraalVM in JIT mode. OpenJ9 is not supported. - For dynamic instrumentation only: a writable `/tmp` directory in the application container. Applications outside these bounds are left untouched. Instrumentation is skipped rather than failing the application. ## Choosing an Instrumentation Mode Both modes deliver the same Java agent and produce the same attribution data. They differ in how the agent reaches the JVM, which has practical consequences: | | Dynamic Instrumentation | Admission-Time Injection | |---|---|---| | Applies to | Every supported JVM on every node | Only workloads you opt in | | Requires redeployment | No | Yes — pods must be recreated | | Connection coverage | Connections opened after the agent attaches | All connections, from application start | | Kubernetes version | 1.28 or above | 1.28 or above | Dynamic instrumentation needs no application changes and no redeployment, which makes it the simpler mode to operate. Choose admission-time injection when you need complete connection coverage from the moment an application starts, or when you want to control precisely which workloads are instrumented. The values file provided by Attribute determines which mode your deployment uses. Review it before changing either setting, and contact Attribute support if you are unsure which mode is active. :::caution Important The two modes must never run at the same time, or applications are instrumented twice. Admission-time injection therefore requires you to explicitly disable dynamic instrumentation, and the Helm chart refuses to install if you do not. ::: ## Dynamic Instrumentation with the Sensor ### How It Works The sensor watches for Java processes starting on the node, including processes that were already running when the sensor itself started. When it finds one, it waits for the JVM to finish initializing, then places the agent files in the application container and loads the agent into the running JVM. Waiting for initialization to complete is deliberate. Attaching to a JVM that is still starting up can disrupt it on some Java versions, so the sensor confirms the JVM is ready before it acts. In practice a typical JVM is instrumented within roughly half a second of starting. The application is neither restarted nor redeployed. Because the agent arrives after the application has started, it observes _connections opened from that point onward_; connections that were already established are not instrumented. ### Configuration Dynamic instrumentation is controlled by a single flag. When it is not disabled, the sensor instruments every supported JVM it finds, with no per-workload configuration. To turn it off — which you must do before enabling admission-time injection — set: ```yaml sensorDisableAutoJavaInstrumentation: true ``` ### Limitations - Only connections opened after the agent attaches are instrumented. For a long-lived connection pool created at application startup, restart the application to bring its connections into scope, or use admission-time injection instead. - All supported JVMs on the node are instrumented. There is no per-workload opt-in. - The application container needs a writable `/tmp`. If it is read-only, instrumentation is skipped for that container. - A JVM started with `-XX:+DisableAttachMechanism` cannot be instrumented. - A JVM started with `-XX:-UsePerfData` is instrumented roughly a minute after it starts instead of immediately. Some database images, such as Cassandra, set this by default. ## Admission-Time Injection ### How It Works When a pod is created, the operator adds three things to it: 1. A shared volume, and an init container that copies the Java agent into that volume. 1. A read-only mount of that volume in every container in the pod. 1. The agent's `-javaagent` option, merged into each container's `JAVA_TOOL_OPTIONS` environment variable. Any value your application already sets is preserved. The agent is therefore present before the JVM starts, and every connection the application opens is instrumented. Injection happens only when a pod is _created_. Pods that already exist are not modified, so roll out your workloads after enabling it. Injection is also idempotent: a pod that already carries the agent is left alone. ### Workload Opt-In Annotation No workload is injected unless it opts in. Set this annotation to `true` on a pod, or on a namespace to opt in every pod within it: ```yaml instrumentation.attrb.io/inject-java: "true" ``` On a Deployment, the annotation belongs on the pod template, not on the Deployment itself: ```yaml spec: template: metadata: annotations: instrumentation.attrb.io/inject-java: "true" ``` ### Enabling Injection ```yaml sensorDisableAutoJavaInstrumentation: true javaAutoInject: enabled: true mode: auto ``` ### Selecting a Backend Two interchangeable backends perform identical injection. `mode` selects between them, and the default `auto` picks the right one for your cluster: | `mode` | Backend | Cluster requirement | |---|---|---| | `auto` | Chooses `policy` on Kubernetes 1.36 and above, otherwise `webhook` | Any supported version | | `policy` | Runs inside the Kubernetes API server | Kubernetes 1.36 or above | | `webhook` | A small admission service, deployed by the chart | Kubernetes 1.28 or above | Leave this at `auto` unless you have a specific reason to pin a backend. Setting a backend your cluster cannot support fails the installation with an explanatory message rather than installing something that does not work. The `policy` backend is evaluated by the API server itself, so it adds no workload to your cluster. The `webhook` backend runs as a small, highly available Deployment that the API server calls when a pod is created; the chart provisions it, along with its own certificates, service, and permissions, with no further setup on your part. ### Configuration Reference | Value | Default | Description | |---|---|---| | `javaAutoInject.enabled` | Set in your values file | Enables admission-time injection. | | `javaAutoInject.mode` | `auto` | Backend selection: `auto`, `policy`, or `webhook`. | | `javaAutoInject.failurePolicy` | `Ignore` | `Ignore` lets pods start uninstrumented if injection fails. `Fail` blocks pod creation instead. | | `javaAutoInject.injectAnnotation` | `instrumentation.attrb.io/inject-java` | The opt-in annotation. | | `javaAutoInject.image.repository` | `quay.io/attribute/java-agent` | Image containing the agent. | | `javaAutoInject.image.tag` | `0.0.11` | Agent image tag. | | `javaAutoInject.mountPath` | `/attrb-jagent` | Where the agent volume is mounted in your containers. | | `javaAutoInject.resourceName` | `attrb-jagent` | Name of the injected volume and init container. | Keep `failurePolicy` at `Ignore` in production. It means a problem with injection leaves an application running without instrumentation, rather than preventing it from starting. ### Advanced Webhook Tuning These apply to the `webhook` backend only and can be left at their defaults. The most useful one is `namespaceSelector`. | Value | Default | Description | |---|---|---| | `javaAutoInject.webhook.namespaceSelector` | `{}` (all namespaces) | Restricts which namespaces are sent to the webhook at all. Recommended on large clusters. | | `javaAutoInject.webhook.replicas` | `3` | Replica count for the webhook Deployment. | | `javaAutoInject.webhook.timeoutSeconds` | `2` | How long the API server waits for the webhook before applying `failurePolicy`. | | `javaAutoInject.webhook.antiAffinity` | `preferred` | Spreads replicas across nodes. `required` guarantees spreading but leaves replicas pending if there are too few nodes. | | `javaAutoInject.webhook.resources` | 50m / 64Mi requests | Requests and limits for the webhook pods. | Every pod created in a selected namespace is sent to the webhook, so on a large cluster narrowing `namespaceSelector` to the namespaces that actually use injection is the most effective tuning available: ```yaml javaAutoInject: webhook: namespaceSelector: matchLabels: attrb.io/inject-java: "true" ``` Your Attribute release namespace and `kube-system` are always excluded, whatever you configure here. :::note If you run the chart with `networkPolicy.enabled=true`, the webhook backend opens its own port so the API server can reach it. All other Attribute components remain subject to the default-deny policy. ::: ## Post-Installation Validation For **dynamic instrumentation**, confirm the agent reached a Java application container and was loaded by the JVM. The first file shows the sensor delivered the agent; the second is written by the agent itself once it starts, so it confirms the JVM accepted it: ```bash kubectl exec -- ls /tmp/jagent.jar /tmp/attrb_agent.jar ``` For **admission-time injection**, confirm a newly created pod carries the agent. Both commands should return a value: ```bash kubectl get pod -o jsonpath='' kubectl get pod -o jsonpath='' ``` In `webhook` mode, confirm the webhook itself is available: ```bash kubectl get pods -n attribute -l app=attrb-inject-java-webhook ``` ## Troubleshooting Instrumentation is designed to fail quietly: if something prevents it, your application starts and runs normally without it. This is the safe behavior, but it means a missing agent produces no obvious symptom. Work through the table below. | Symptom | Likely cause | What to do | |---|---|---| | No instrumentation, admission-time injection | The pod predates the configuration change | Roll out the workload. Only newly created pods are injected. | | No instrumentation, admission-time injection | Missing opt-in annotation | Confirm the annotation is on the **pod template**, not the Deployment, or on the namespace. | | No instrumentation, admission-time injection | Injection is failing silently under `failurePolicy: Ignore` | Temporarily set `javaAutoInject.failurePolicy=Fail`. Pod creation then reports the underlying error. Revert afterwards. | | No instrumentation, dynamic mode | Application container has a read-only `/tmp` | Use admission-time injection for this workload. | | No instrumentation, dynamic mode | JVM runs with `-XX:+DisableAttachMechanism` | Remove the flag, or use admission-time injection. | | Instrumentation appears about a minute late, dynamic mode | JVM runs with `-XX:-UsePerfData` | Expected. Use admission-time injection if you need coverage from startup. | | Some connections attributed, others not, dynamic mode | Connections opened before the agent attached | Restart the application, or use admission-time injection. | | Nothing at all, any mode | Unsupported JVM, Java version, or architecture | Check the application against the requirements above. | | Installation fails with a message about `sensorDisableAutoJavaInstrumentation` | Both modes were enabled together | Set `sensorDisableAutoJavaInstrumentation: true` when using admission-time injection. | For a deeper look in dynamic mode, enable debug logging on the sensor and check its logs for Java attach activity. Attach failures are always logged; successful attaches are logged at debug level only. Contact Attribute support if you need help interpreting the output. ## Files Added to Your Containers Both modes place files inside your application containers. This is what to expect. **Dynamic instrumentation** writes the agent and a small attach helper into the application container's `/tmp` directory, then attaches the agent to the running JVM. These files remain in the container's writable layer for the lifetime of the container and are removed when it is replaced. Account for a few tens of megabytes of ephemeral storage per instrumented container if you monitor it closely. **Admission-time injection** places the agent in a dedicated volume that the operator adds to the pod. Nothing is written into your container images or their writable layers, and everything is removed with the pod. In both cases the agent runs inside your application's JVM in order to observe its connections. It is added to the running application only; your container images are never modified. --- *Trademarks: Java and GraalVM are registered trademarks of Oracle and/or its affiliates. Kubernetes is a registered trademark of The Linux Foundation. Amazon Corretto is a trademark of Amazon.com, Inc. or its affiliates. Eclipse and Temurin are trademarks of the Eclipse Foundation. Azul and Zulu are trademarks of Azul Systems, Inc. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/cloud-integrations/aws/attribute-aws-deployment-cf-and-stackset # CloudFormation and StackSet Attribute provides a holistic platform for cloud cost, including the ability to understand cost attribution and accountability from the resource level up to the feature, application, team, and customer levels. To achieve this, Attribute requires several levels of access: - Access to billing information. - Attribute sensor implementation, to gain resource utilization information. The detailed permissions are documented in the CloudFormation template provided by Attribute. :::note Depending on your cloud implementation, additional permissions may be required for specific resources. ::: ## CloudFormation Using StackSet To ensure a smooth implementation, we leverage CloudFormation to both create the billing information and complete the necessary setup. The CloudFormation template is supplied by Attribute. :::caution Important All stacks must be applied in region **`us-east-1`**. ::: ### Management Account Setup On the Management account, run the following: 1. Go to **CloudFormation → Stacks → Create stack → With new resources (standard)**. 2. Select **Choose an existing template**. 3. Upload the template provided by Attribute. 4. Add the required stack details: - **Stack name:** A name of your choosing. Do **NOT** use `AttributeRegistration` — that name is used by a child stack. - **Account name:** Will be added automatically as needed; can be overridden if needed. - **Account type:** `management`. 5. Deploy the stack. ### Subaccount Deployments 1. Go to **CloudFormation → StackSets → Create StackSet**. 2. On the **Choose a template** page: 1. Choose **Service-managed permissions**. 2. Choose **Template is ready**. 3. Choose **Upload a template file** and upload the template provided by Attribute (the same file used for the management account setup, now applied to subaccounts). 4. Click **Next**. ![Choose a template page, with annotations on Template is ready (1), Upload a template file (2), and the uploaded attribute-cf-base.yml file (3)](@site/assets/png/attribute/aws-stackset-choose-template.png) 3. On the **Specify StackSet details** page: 1. Enter a **StackSet name**. 2. Leave **AccountName** empty so subaccount names are detected automatically. 3. Set **AccountType** to `sub`. 4. Click **Next**. ![Specify StackSet details page, with annotations on StackSet name (1), AccountName left empty (2), and AccountType set to sub (3)](@site/assets/png/attribute/aws-stackset-specify-details.png) 4. On the **Set deployment options** page: 1. **Deployment targets:** choose **Deploy to organizational units (OUs)**. 2. Apply an account filter if needed. 3. **Specify regions:** must be `us-east-1`. 4. Create the StackSet. ![Set deployment options page, with annotations on Deploy to organizational units (1) and the us-east-1 region selected (2)](@site/assets/png/attribute/aws-stackset-set-deployment-options.png) --- *Trademarks: AWS is a trademark of Amazon.com, Inc. or its affiliates. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/cloud-integrations/aws/attribute-aws-deployment-guide-tf # Attribute AWS integration ## Install with Attribute Terraform To ensure a smooth implementation, Attribute provides a Terraform module that automates setup for billing-information extraction and sensor registration. Detailed Terraform documentation and examples can be found in the [README] within the Terraform module. ### AWS Account Types The module supports installation on both AWS organizational management accounts and member accounts (also known as sub-accounts). Terraform creates all the required infrastructure for the Attribute solution via CloudFormation. **Please note the following:** - Supported Terraform version is **1.9 and above**. - Whenever the sensor needs to be deployed, the Terraform module must be deployed on each sub-account. Additionally, if using a billing or payer account, the module must be deployed on both the billing/payer account and its associated sub-accounts to ensure full cost visibility. We recommend keeping the account installations in the same Terraform state so they're managed together. - The module **does not** deploy the Attribute sensor on the compute infrastructure. That process is done with different tools per compute cluster (see Attribute's installation guide). - The Terraform module must run on **`us-east-1`**, even if the account's resources are in a different region. - When running the module, specify whether you are deploying to the AWS Organization management account or to a member (sub) account where a sensor will be installed, using the `account_type` parameter. ### Resources Created by This Module **When running on an AWS management account**, the following resources are created: - S3 bucket and ACLs used to store CUR 2.0 reports and billing data export resources. - IAM role to allow Attribute to access AWS APIs. - Data Export resource to facilitate data retrieval. - CloudFormation stack to automate Attribute Sensor registration. - EKS (and ECS where applicable) cost allocation tags to support cost tracking. **When running on an AWS member account**, the following resources are created: - IAM role to allow Attribute to access AWS APIs. - CloudFormation stack to automate Attribute Sensor registration. ### Upgrading an Existing Attribute Terraform Module :::note When upgrading, manually remove the old `ZouzCURExport` resource. ::: ## Appendix A: Detailed Installation Instructions This appendix walks you through the entire setup process, from the management account configuration to sensor deployment on a member account. ### Step 1 — Billing Integration The following steps should be done **only on the management (payer) account**. 1. Verify your Terraform version is 1.9 or above: ```bash terraform version ``` 2. Make sure you're operating in the `us-east-1` region before deploying. 3. Update the following variables in the `main.tf` file you received from Attribute: 1. Update the Terraform profile you're using so it points to the correct AWS account. 2. Verify the region is set to `us-east-1` (do not change to another region). 3. Verify the alias is set to `"management"`. 4. Update the account name from `"change-me"` to your account name. 5. Do **not** change the `organization_id` — leave it as is. ```hcl terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } } provider "aws" { region = "us-east-1" alias = "management" } # provider "aws" { # region = "us-east-1" # alias = "sub-1" # } resource "random_uuid" "external_id" {} module "attribute-sensor" { source = "ZouzIO/attribute-sensor/aws" version = "~> 2.1" account_type = "management" account_name = "change-me" organization_id = "XXXX-XXXX-XXX-XXXX-XXXXXXX" external_id = random_uuid.external_id.id providers = { aws = aws.management } } # module "attribute-sensor-sub" { # source = "ZouzIO/attribute-sensor/aws" # version = "~> 2.1" # # account_type = "sub" # account_name = "change-me-sub" # organization_id = "XXXX-XXXX-XXX-XXXX-XXXXXXX" # external_id = random_uuid.external_id.id # # providers = { # aws = aws.sub-1 # } # } ``` 4. Apply the Terraform: ```bash terraform init terraform apply ``` 5. **Verification.** Log in to your management account's AWS Console and verify that the following resources have been created: 1. An S3 bucket to store CUR 2.0 reports, plus the Data Export. ![AWS General purpose buckets list showing the attribute-cur-us-east-1 bucket in us-east-1](@site/assets/png/attribute/aws-tf-s3-bucket.png) ![AWS Data Exports page showing AttributeCurExport with status Healthy, type CUR 2.0](@site/assets/png/attribute/aws-tf-data-exports.png) 2. An IAM role that allows Attribute to access AWS APIs. ![AWS IAM role AttributeLoaderV-us-east-1-861276102138 summary showing creation date, ARN, and switch-role link](@site/assets/png/attribute/aws-tf-iam-role.png) ### Step 2 — Sensor Implementation Configure each member account (sub-account) where you plan to deploy a sensor. This involves two parts: running Terraform to create the prerequisites (once per sub-account), and then deploying the sensor on each EKS cluster using a Helm chart. #### Step 2.1 — Terraform Prerequisite Setup (Member Account) The following steps should be run **once per member account (sub-account)**. 1. Update the `main.tf` file you received from Attribute to reflect the member account: 1. Update the Terraform profile to point to the correct AWS account. 2. Uncomment the additional provider with the alias of the sub-account (you can have several sub-account providers as needed). 3. Uncomment the sub-account module and update the account name from `"change-me-sub"` to your sub-account name. 4. Do **not** change the `organization_id` — leave it as is. ```hcl terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } } provider "aws" { region = "us-east-1" alias = "management" } provider "aws" { region = "us-east-1" alias = "sub-1" } resource "random_uuid" "external_id" {} module "attribute-sensor" { source = "ZouzIO/attribute-sensor/aws" version = "~> 2.1" account_type = "management" account_name = "change-me" organization_id = "XXXX-XXXX-XXX-XXXX-XXXXXXX" external_id = random_uuid.external_id.id providers = { aws = aws.management } } module "attribute-sensor-sub" { source = "ZouzIO/attribute-sensor/aws" version = "~> 2.1" account_type = "sub" account_name = "change-me-sub" organization_id = "XXXX-XXXX-XXX-XXXX-XXXXXXX" external_id = random_uuid.external_id.id providers = { aws = aws.sub-1 } } ``` 2. Apply the Terraform: ```bash terraform apply ``` 3. **Verification.** Log in to your sub-account on the AWS Console and verify that an IAM role allowing Attribute to access AWS APIs has been created. #### Step 2.2 — Deploying the Sensor with Helm on EKS The following steps should be repeated on every EKS cluster where you want to deploy the sensor. 1. Save the values file provided by Attribute (`values.yaml`). This file contains a unique ephemeral token. 2. Review the Java instrumentation settings in the values file. The file includes the following flags by default: ```yaml # Java instrumentation settings sensorDisableAutoJavaInstrumentation: true javaAutoInject: enabled: true ``` This configuration is supported on Kubernetes **1.28 and above**. The injection backend is selected automatically, so no version-specific adjustment is needed. To use the sensor's dynamic Java instrumentation instead of admission-time injection, set `javaAutoInject.enabled` to `false` **and** set `sensorDisableAutoJavaInstrumentation` to `false`. The two must never be enabled together. For a full explanation of both modes, see the [Attribute Java Instrumentation Guide](https://help.doit.com/docs/attribute/integrations/cloud-integrations/attribute-java-instrumentation-guide). 3. Verify your Helm version — version 3.8.0 or above is supported: ```bash helm version ``` 4. Install the Helm chart: ```bash helm upgrade -i attribute \ oci://quay.io/attribute/operator-chart \ -f \ -n attribute \ --create-namespace ``` 5. **Optional — configure the token as a secret.** If you'd like to store the token as a secret using an external secret manager, add the following configuration to the values file: ```yaml initconfig: create_secret: false orgToken: secretName: external-secret-name secretKey: external-secret-key ``` 6. **Verification.** Run the following to verify the Helm release and that the operator and sensor are running: ```bash helm list -n attribute kubectl get pods -n attribute ``` Example expected output: ![Terminal output of helm list -n attribute showing the attribute release deployed with the operator-chart](@site/assets/png/attribute/tf-helm-list.png) ![Terminal output of kubectl get pods -n attribute showing five attribute pods all in Running state with READY 1/1](@site/assets/png/attribute/tf-kubectl-pods.png) :::note If you'd like to deploy the sensor on other compute resource types (standalone, Fargate, etc.), refer to the relevant sensor deployment documentation. ::: --- *Trademarks: AWS is a trademark of Amazon.com, Inc. or its affiliates. Terraform is a registered trademark of HashiCorp, Inc. Kubernetes is a registered trademark of The Linux Foundation. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/cloud-integrations/aws/attribute-ec2-sensor-installation # Attribute EC2 Sensor Installation ## Introduction The Attribute EC2 sensor is an eBPF sensor that runs as a `systemd` service on a Linux-based virtual machine. It provides deep visibility and real-time monitoring of EC2 instances using eBPF (Extended Berkeley Packet Filter) technology, capturing network and system-level events without changes to application code and without kernel modules. The sensor operates as a passive observer, so overhead and performance impact on the monitored instance remain minimal. ## Requirements | Requirement | Details | |---|---| | Kernel version | 5.10 or newer | | Architecture | `x86_64` and `arm64` | | Privileges | `sudo` access on the instance | ## Before You Begin Obtain your installation token from Attribute. The token is unique **per account** and is used for both installation and later upgrades. ## Installation Methods There are two ways to install the sensor. Choose the one that matches how your instances are provisioned. | Method | When to Use It | |---|---| | [Image or launch template install](#installing-in-a-machine-image-or-launch-template) | Instances are created from a golden AMI, a launch template, or an Auto Scaling group. Install once during image creation and every instance launched from it carries the sensor. | | [Runtime install](#installing-on-a-running-instance) | Instances are long-lived and managed individually. Install directly on the running instance. | Both methods run the same installation script; they differ only in whether the sensor is started as part of the installation. ## Installing in a Machine Image or Launch Template Use this method when baking the sensor into an AMI, a launch template's user data, or any image-build pipeline (for example Packer or EC2 Image Builder). 1. On the build instance, download the installation script and make it executable: ```bash wget https://storage.googleapis.com/attrb-artifacts/standalone-install.sh chmod +x ./standalone-install.sh ``` 2. Run the script with your workload name, memory limit, and token: ```bash sudo ./standalone-install.sh 524288000 ``` | Argument | Description | |---|---| | `` | Name of the service that will run on instances launched from this image. | | `524288000` | Memory limit for the sensor, in bytes (500 MiB). | | `` | Installation token provided by Attribute. | 3. Finish the image build as usual and create the AMI. Do not start the sensor on the build instance. The installation script enables the `zprobe` `systemd` service, so it starts automatically on the first boot of every instance launched from the image. Verify the sensor on a launched instance rather than in the image itself, as described in [Verifying the Installation](#verifying-the-installation). ## Installing on a Running Instance Use this method to add the sensor to an instance that is already in service. 1. Download the installation script and make it executable: ```bash wget https://storage.googleapis.com/attrb-artifacts/standalone-install.sh chmod +x ./standalone-install.sh ``` 2. Run the script with your workload name, memory limit, and token: ```bash sudo ./standalone-install.sh 524288000 ``` | Argument | Description | |---|---| | `` | Name of the service running on the instance. | | `524288000` | Memory limit for the sensor, in bytes (500 MiB). | | `` | Installation token provided by Attribute. | 3. Start the sensor. The installer enables the `zprobe` `systemd` service but does not start it, so without this step the sensor only begins reporting after the next reboot: ```bash sudo systemctl start zprobe ``` ## Verifying the Installation On a running instance, check the service status: ```bash sudo systemctl status zprobe ``` The service should report `active (running)`, as in the example below: ![Terminal output of systemctl status zprobe showing the zprobe.service as loaded, enabled, and active (running) with main PID, memory, and CGroup details](@site/assets/png/attribute/ec2-sensor-systemctl-status.png) ## Upgrading the Sensor The installation script always fetches the latest sensor version, so upgrading means re-running it with the same per-account token. For image-based deployments, re-run the installation script in your image build and roll out the new image; instances launched from it start the updated sensor on first boot. For a running instance: 1. Run the installation script again: ```bash sudo ./standalone-install.sh 524288000 ``` 2. Restart the sensor to load the new version: ```bash sudo systemctl restart zprobe ``` --- *Trademarks: AWS is a trademark of Amazon.com, Inc. or its affiliates. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/cloud-integrations/aws/attribute-sensor-for-aws-ecs # Attribute Sensor for AWS ECS The Attribute ECS sensor is an eBPF sensor that runs as one task per EC2 container instance in your cluster. It observes network and system-level events on the instance without changes to your application code and without kernel modules, so it sees the traffic of every task scheduled on that instance and attributes task-level cost to the resources those tasks use. ## How the Deployment Works Attribute delivers you a CloudFormation template named `ecs-sensor-.json`. **Your installation token and the sensor image version are already filled in as parameter defaults** — do not enter or edit them. Installing the sensor is a two-step process: | Step | What You Do | Why It Is Separate | |---|---|---| | [Deploy the CloudFormation stack](#step-1-deploy-the-cloudformation-stack) | Create a stack from the template, in the region of the ECS cluster you want to cover. | The stack creates the IAM role and the sensor task definition. | | [Create the ECS service](#step-2-create-the-ecs-service) | Manually create a Daemon service in the cluster, using the task definition from the stack. | The template deliberately does not create a service, so you choose which clusters run the sensor. | Both steps are repeated per region and per cluster: one stack for each region that holds clusters you want covered, and one service in each of those clusters. :::caution Important Deploy the stack in the **same region** as the ECS cluster. The task definition and the IAM role it references are regional resources, and a cluster cannot use a task definition from another region. ::: ## Requirements | Requirement | Details | |---|---| | Cluster capacity | An ECS cluster with **EC2** container instances. Fargate is not covered by this guide — see [Attribute Sensor for AWS Fargate](https://help.doit.com/docs/attribute/integrations/cloud-integrations/aws/attribute-sensor-for-aws-fargate). | | Container instances | Linux, kernel 5.10 or newer. The sensor supports both `x86_64` and `arm64`, but the task definition the template creates declares a single architecture — see the note below. | | IAM permissions | Permission to create IAM roles with custom names (the stack needs `CAPABILITY_NAMED_IAM`) and to register ECS task definitions. | | Outbound network | HTTPS (TCP 443) from the container instances to `otel-endpoint.app.attrb.io`. | | Image pull | Container instances must be able to pull images from `quay.io`. | | Task placement | The sensor task runs privileged with host PID mode and host path mounts. | ## What the Template Creates The stack creates two resources and nothing else. It does not modify your clusters, services, or existing task definitions. - **An IAM role**, named `AttributeECSZprobeDaemonSetRole-`, assumed by `ecs-tasks.amazonaws.com` and used as both the task role and the execution role of the sensor task. It carries the AWS managed policies `AmazonECSTaskExecutionRolePolicy` (to pull the image) and `AmazonEC2ReadOnlyAccess` (to identify the instance the sensor is running on). - **An ECS task definition**, in the family you name, with a single container called `zsense` running `quay.io/attribute/sensor`. It is an EC2-launch-type task definition with host PID mode, a 1024 MiB memory limit, a 512 MiB memory reservation, and no reserved CPU. :::note Because the role name is fixed per region, only one Attribute ECS stack can exist in a region at a time. A second stack in the same region fails with a role-name conflict. To cover more clusters in the same region, reuse the task definition the existing stack already created. ::: The task definition carries no log configuration, so sensor container logs go to the container instance's default Docker log driver rather than to CloudWatch. If you need them in CloudWatch, add an `awslogs` log configuration to a new revision of the task definition after the stack has been created. ### Architecture The sensor itself runs on both `x86_64` and `arm64`, but an ECS task definition declares exactly one `CpuArchitecture`, and the template ships with `X86_64`. As created, the task definition therefore places only on `x86_64` container instances, and any `arm64` (Graviton) instances in the cluster are left uncovered. If your cluster runs `arm64` container instances, contact Attribute before you deploy — covering them needs a task definition that declares `ARM64`, and a cluster with both architectures needs one Daemon service per architecture. ## Step 1: Deploy the CloudFormation Stack 1. In the AWS console, switch to the region of the ECS cluster you want to cover. 1. Go to **CloudFormation** > **Stacks** > **Create stack** > **With new resources (standard)**. 1. Select **Choose an existing template**, then **Upload a template file**, and upload the `ecs-sensor-.json` file. 1. Add the stack details: | Field | Value | |---|---| | **Stack name** | A name of your choosing, for example `attribute-ecs-sensor`. | | **AttributeToken** | Pre-filled by Attribute. Leave it exactly as it is. | | **TaskFamily** | The name for the sensor task definition family, for example `attribute`. Note the value down — you need it in step 2. | | **SensorVersion** | Pre-filled with the current released sensor version. Leave it as it is unless Attribute has asked you to pin a specific version. | 1. On the review page, acknowledge that the stack creates IAM resources with custom names. 1. Submit the stack and wait for it to reach `CREATE_COMPLETE`. ## Step 2: Create the ECS Service The stack has registered the task definition, but nothing is running yet. Create a service in the cluster to schedule the sensor onto every container instance. 1. Go to **ECS** > **Clusters** > your cluster > **Services** > **Create**. 1. Under **Compute configuration**, choose **Launch type** and set the launch type to **EC2**. Do not use a capacity provider strategy. ![ECS Compute configuration set to EC2 launch type, with the Deployment scheduling strategy set to Daemon](@site/assets/png/attribute/ecs-compute-deployment-config.png) 1. Under **Deployment configuration**, set: - **Task definition family:** the `TaskFamily` value you entered in step 1. - **Task definition revision:** the latest revision. - **Service name:** a name of your choosing, for example `attribute`. - **Scheduling strategy:** **Daemon**. This places and maintains exactly one sensor task on each container instance in the cluster, including instances added later. ![ECS Service details form with the task definition family and service name both set to "attribute"](@site/assets/png/attribute/ecs-service-details.png) :::note The screenshots use `attribute` as the task definition family and service name. Substitute the `TaskFamily` value you chose. ::: 1. Under **Deployment failure detection**, clear **Use the Amazon ECS deployment circuit breaker**. :::caution Important The circuit breaker must be off. On a mixed cluster, container instances the sensor task cannot be placed on — `arm64` instances, or an unsupported operating system — cause individual task failures. With the circuit breaker enabled, ECS reads those as a failed deployment and rolls the whole service back, so the sensor is removed from the instances where it was running correctly. With it off, the sensor runs wherever it can and the remaining instances are simply left uncovered. ::: 1. Leave the remaining settings at their defaults and create the service. ## Verifying the Installation 1. In the cluster's **Tasks** tab, confirm there is one running sensor task per EC2 container instance, and that the tasks stay in `RUNNING` rather than cycling through stops and restarts. 1. Confirm that the service's running count matches its desired count. For a Daemon service, ECS sets the desired count to the number of eligible container instances. 1. Task-level data appears in the Attribute dashboard shortly after the tasks reach `RUNNING`. If nothing appears, verify outbound HTTPS access to `otel-endpoint.app.attrb.io` from the container instances. ## Upgrading the Sensor Attribute tells you when a new sensor version is available. 1. Go to **CloudFormation** > **Stacks** > your Attribute ECS stack > **Update**. 1. Choose **Replace existing template** and upload the newer template, or keep the current template and set **SensorVersion** to the version Attribute specified. 1. Apply the update. CloudFormation registers a new revision of the task definition. 1. Update the ECS service to the new task definition revision and deploy it. The Daemon service replaces the sensor task on each container instance in turn. ## Uninstalling 1. Delete the ECS service in each cluster running the sensor. This stops and removes the sensor tasks. 1. Delete the CloudFormation stack in each region. This removes the IAM role and the sensor task definition. --- *Trademarks: AWS is a trademark of Amazon.com, Inc. or its affiliates. Docker is a trademark of Docker, Inc. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/cloud-integrations/aws/attribute-sensor-for-aws-fargate-java # Attribute Sensor for AWS Fargate (Java Edition) This document outlines the information and configuration required to install the Attribute Sensor within an AWS Fargate task definition for Java applications. The sensor runs as an embedded process inside your application's container. For Java applications it is paired with the Attribute Java agent, which is attached to the JVM so that TLS-encrypted traffic is visible for attribution. See the [Attribute Java Instrumentation Guide](https://help.doit.com/docs/attribute/integrations/cloud-integrations/attribute-java-instrumentation-guide) for background on why Java requires the agent. ## Step 1: Update `containerDefinitions` In your task definition, modify the relevant `containerDefinition` as follows. **Add environment variables to the `environment` section:** ```json "environment": [ { "name": "CONFIG_ZPROBE_BEARER_TOKEN", "value": "" }, { "name": "CONFIG_ZPROBE_OTEL_ADDR", "value": "otel-endpoint.app.attrb.io:443" }, { "name": "JAVA_TOOL_OPTIONS", "value": "-javaagent:/opt/zprobe/jagent.jar" } ] ``` **Add a dependency to the `dependsOn` section:** ```json "dependsOn": [ { "containerName": "attribute-sensor", "condition": "COMPLETE" } ] ``` **Add a mount to the `mountPoints` section:** ```json "mountPoints": [ { "sourceVolume": "attribute-shared", "containerPath": "/opt/zprobe" } ] ``` **Change the `entryPoint` and `command` of the container:** ```json "entryPoint": [ "/opt/zprobe/launch/ecs-fargate" ], "command": [ "" ] ``` :::note Replace `` with your application's start command, split into one array element per argument — for example `["java", "-jar", "/app/app.jar"]`. ::: **Add another container definition to `containerDefinitions` (sidecar):** ```json { "name": "attribute-sensor", "image": "quay.io/attribute/sensor:", "essential": false, "entryPoint": [ "/bin/sh", "-c" ], "command": [ "mkdir -p /shared && cp -r /app/* /shared/" ], "mountPoints": [ { "sourceVolume": "attribute-shared", "containerPath": "/shared" } ] } ``` ## Step 2: Update `volumes` Add the shared volume to the `volumes` section: ```json "volumes": [ { "name": "attribute-shared" } ] ``` ## Notes - It is recommended to create a new revision of your task definition when making these changes, then update your ECS service accordingly. - **Performance and availability:** - The sensor runs as an embedded process within the container. We recommend increasing the CPU allocation by 1 vCPU to ensure minimal performance impact. - If the sensor fails, application functionality should not be affected. - Terraform automation for installation is supported. ## Appendix A: Example of a Complete Task Definition ```json { "family": "", "containerDefinitions": [ { "name": "", "image": "", "environment": [ { "name": "CONFIG_ZPROBE_BEARER_TOKEN", "value": "" }, { "name": "CONFIG_ZPROBE_OTEL_ADDR", "value": "otel-endpoint.app.attrb.io:443" }, { "name": "JAVA_TOOL_OPTIONS", "value": "-javaagent:/opt/zprobe/jagent.jar" } ], "workingDirectory": "/app", "cpu": 0, "essential": true, "dependsOn": [ { "containerName": "attribute-sensor", "condition": "COMPLETE" } ], "entryPoint": [ "/opt/zprobe/launch/ecs-fargate" ], "command": [ "java", "-jar", "/app/app.jar" ], "mountPoints": [ { "sourceVolume": "attribute-shared", "containerPath": "/opt/zprobe" } ], "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group": "/ecs/go-zprobe-fargate", "mode": "non-blocking", "awslogs-create-group": "true", "max-buffer-size": "25m", "awslogs-region": "us-east-1", "awslogs-stream-prefix": "ecs" } } }, { "name": "attribute-sensor", "image": "quay.io/attribute/sensor:", "essential": false, "entryPoint": [ "/bin/sh", "-c" ], "command": [ "mkdir -p /shared && cp -r /app/* /shared/" ], "mountPoints": [ { "sourceVolume": "attribute-shared", "containerPath": "/shared" } ] } ], "volumes": [ { "name": "attribute-shared" } ], "executionRoleArn": "", "networkMode": "awsvpc", "placementConstraints": [], "requiresCompatibilities": ["FARGATE"], "cpu": "4096", "memory": "8192", "runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "LINUX" }, "enableFaultInjection": false } ``` --- *Trademarks: AWS is a trademark of Amazon.com, Inc. or its affiliates. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/cloud-integrations/aws/attribute-sensor-for-aws-fargate # Attribute Sensor for AWS Fargate This document outlines the necessary information and configuration to install the Attribute sensor within an AWS Fargate task definition. ## Background Attribute is a FinOps platform that uncovers a new layer of application-level runtime data and connects it directly to cloud and SaaS platform costs. We've developed a unique, first-of-its-kind AWS Fargate sensor that lets you analyze task-level costs and attribute them to resources such as S3, RDS, ElastiCache, and others. Please review the instructions below, and reach out to our team with any questions. ## Step 1: Update `containerDefinitions` In your task definition, modify the relevant `containerDefinition` as follows. **Add environment variables to the `environment` section:** ```json "environment": [ { "name": "CONFIG_ZPROBE_BEARER_TOKEN", "value": "" }, { "name": "CONFIG_ZPROBE_OTEL_ADDR", "value": "otel-endpoint.app.attrb.io:443" } ] ``` **Add a dependency to the `dependsOn` section:** ```json "dependsOn": [ { "containerName": "attribute-sensor-loader", "condition": "COMPLETE" } ] ``` **Add a mount to the `mountPoints` section:** ```json "mountPoints": [ { "sourceVolume": "attribute-shared", "containerPath": "/opt/attrb" } ] ``` **Change the `entryPoint` and `command` of the container:** ```json "entryPoint": [ "/opt/attrb/launch/ecs-fargate" ], "command": [ "", "-javaagent:/opt/attrb/jagent.jar" ] ``` :::note The `-javaagent:/opt/attrb/jagent.jar` line only applies to Java/Scala applications. Omit it for other runtimes. ::: **Add another container definition to `containerDefinitions`:** ```json { "name": "attribute-sensor-loader", "image": "quay.io/attribute/sensor:", "essential": false, "entryPoint": [ "load_attribute" ], "mountPoints": [ { "sourceVolume": "attribute-shared", "containerPath": "/opt/attrb" } ] } ``` ## Step 2: Update `volumes` Add the shared volume to the `volumes` section: ```json "volumes": [ { "name": "attribute-shared" } ] ``` ## Notes - It is recommended to create a new revision of your task definition when making these changes, then update your ECS service accordingly. - **Performance and availability:** - The sensor runs as an embedded process within the container. We recommend increasing the CPU allocation by 1 vCPU to ensure minimal performance impact. - If the sensor fails, application functionality should not be affected. - Terraform automation for installation is supported. ## Appendix A: Example of a Complete Task Definition ```json { "family": "", "containerDefinitions": [ { "name": "", "image": "", "environment": [ { "name": "CONFIG_ZPROBE_BEARER_TOKEN", "value": "" }, { "name": "CONFIG_ZPROBE_OTEL_ADDR", "value": "otel-endpoint.app.attrb.io:443" } ], "workingDirectory": "/app", "cpu": 0, "essential": true, "dependsOn": [ { "containerName": "attribute-sensor-loader", "condition": "COMPLETE" } ], "entryPoint": [ "/opt/attrb/launch/ecs-fargate" ], "command": [ "/app/bin/mongo-scala", "-javaagent:/opt/attrb/jagent.jar" ], "mountPoints": [ { "sourceVolume": "attribute-shared", "containerPath": "/opt/attrb" } ], "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group": "/ecs/go-zprobe-fargate", "mode": "non-blocking", "awslogs-create-group": "true", "max-buffer-size": "25m", "awslogs-region": "us-east-1", "awslogs-stream-prefix": "ecs" } } }, { "name": "attribute-sensor-loader", "image": "quay.io/attribute/sensor:", "essential": false, "entryPoint": [ "load_attribute" ], "mountPoints": [ { "sourceVolume": "attribute-shared", "containerPath": "/opt/attrb" } ] } ], "volumes": [ { "name": "attribute-shared" } ], "executionRoleArn": "", "networkMode": "awsvpc", "placementConstraints": [], "requiresCompatibilities": ["FARGATE"], "cpu": "4096", "memory": "8192", "runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "LINUX" }, "enableFaultInjection": false } ``` --- *Trademarks: AWS is a trademark of Amazon.com, Inc. or its affiliates. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/cloud-integrations/gcp/attribute-gcp-tf-deployment-guide # Attribute GCP TF Deployment Attribute provides a holistic platform for cloud cost, including the ability to understand cost attribution and accountability from the resource level up to the feature, application, team, and customer levels. To achieve this, Attribute requires several levels of access: - Access to billing information. - Attribute sensor implementation, to gain resource utilization information. Below are the detailed steps and permissions required to complete the installation. :::note Depending on your cloud implementation, additional permissions may be required for specific resources. ::: ## Billing Export Data Attribute uses GCP's detailed billing export to load the current billing and usage information for your organization. Configure the Billing Export with the following steps: 1. Access the billing dashboard by selecting **Billing** in the console's navigation panel. 2. *(Optional)* If you have more than one billing account and encounter the "You have multiple billing accounts" message, click **GO TO LINKED BILLING ACCOUNT**. 3. In the side panel, navigate to **Billing export**, locate the **Detailed usage cost** section, and click **EDIT SETTINGS**. 4. In this window, choose where to store the billing export (project and BigQuery dataset). :::note It may take up to 48 hours for new billing data to appear after configuring the export. ::: To ensure a smooth implementation, Attribute provides a Terraform module that automates the required setup and sensor registration. Detailed Terraform documentation and examples can be found in the [README] within the Terraform module. ## GCP Account Types The module supports installation on both a GCP organizational project and sub-projects. When running the module, specify whether you're deploying to the GCP Organization management project or to a sub-project where a sensor will be installed, using the `account_type` parameter. **Please note the following:** - Supported Terraform version is **1.9 and above**. - Whenever the sensor needs to be deployed, the module must be deployed on each sub-project. Additionally, if using an organizational billing project, the module must be deployed on both the billing project and its associated sub-projects to ensure full cost visibility. - The module **does not** deploy the Attribute sensor on the compute infrastructure. That process is done with different tools per compute cluster (see Attribute's installation guide). ## Resources Created by This Module **When running on a GCP organization management account**, the following resources are created: - Service account to allow secure access to the billing data. - BigQuery Data Viewer permissions on the billing export dataset. **When running on a GCP sub-project**, the following resources are created: - Service account to allow secure access to the billing data. The sensor registration process is fully automated within the module. For more information, refer to the module README. ## Appendix A: Detailed Installation Instructions This appendix walks you through the entire setup process, from the management account configuration to sensor deployment on a member account. ### Step 1 — Billing Integration #### 1.1 Creating Billing Export Data This is the same Billing Export configuration described above. If you've already configured the export, skip to step 1.2. 1. Access the billing dashboard by selecting **Billing** in the console's navigation panel. If you have more than one billing account and see the "You have multiple billing accounts" message, click **GO TO LINKED BILLING ACCOUNT**. 2. In the side panel, navigate to **Billing export**, locate the **Detailed usage cost** section, and click **EDIT SETTINGS**. 3. Choose where to store the billing export (project and BigQuery dataset). :::note It may take up to 48 hours for new billing data to appear. ::: #### 1.2 Running the Terraform for Billing Integration The following steps should be done **only on the management (payer) account**. 1. Verify your Terraform version is 1.9 or above: ```bash terraform version ``` 2. Update the following variables in the `main.tf` file you received from Attribute: 1. Update the Terraform profile you're using so it points to the correct GCP account. 2. Update the `project` and `region` information. 3. Verify the alias is set to `"management"`. 4. Do **not** change the `organization_id` and `token` — leave them as is. 5. Update the `billing_export_dataset_name`. 6. Update the `billing_export_table_name`. ```hcl terraform { required_providers { google = { source = "hashicorp/google" version = ">= 6.0, <7.0" } } } provider "google" { project = "my-main-1234" region = "us-central1" alias = "management" } # provider "google" { # project = "my-sub-account-1234" # region = "us-central1" # alias = "sub1" # } module "attribute_management" { source = "ZouzIO/attribute-sensor/gcp" version = "~> 3.0" token = "XXXXXXXXXXXXXXXXXX" organization_id = "XXXXXXXXXXXXXXXXXXXXX" account_type = "management" billing_export_dataset_name = "your_billing_export_dataset_name" billing_export_table_name = "your_billing_export_table_name" providers = { google = google.management } } # module "attribute_sub1" { # source = "ZouzIO/attribute-sensor/gcp" # version = "~> 3.0" # # token = "XXXXXXXXXXXXXXXXXXXXX" # organization_id = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" # account_type = "sub" # billing_info = module.attribute_management.billing_info # # providers = { # google = google.sub1 # } # } ``` 3. Apply the Terraform: ```bash terraform init terraform apply ``` ### Step 2 — Sensor Implementation Configure each project (sub-account) where you plan to deploy a sensor. This involves two parts: running Terraform to create the prerequisites (once per sub-account), and then deploying the sensor on each GKE cluster using a Helm chart. #### Step 2.1 — Terraform Prerequisite Setup (Member Account) The following steps should be run **once per project (sub-account)**. 1. Update the `main.tf` file you received from Attribute to reflect the member account: 1. Update the Terraform profile to point to the correct GCP project. 2. Uncomment the additional provider with the alias of the sub-account (you can have several sub-account providers as needed). 3. Uncomment the sub-account module and update the project name from `"my-sub-account-1234"` to your project name, plus the region info. 4. Do **not** change the `organization_id` and `token` — leave them as is. 5. Make sure the billing information is preserved — do not delete the `billing_info` data. ```hcl terraform { required_providers { google = { source = "hashicorp/google" version = ">= 5.0, < 8.0" } } } provider "google" { project = "my-main-1234" region = "us-central1" alias = "management" } provider "google" { project = "my-sub-account-1234" region = "us-central1" alias = "sub1" } module "attribute_management" { source = "ZouzIO/attribute-sensor/gcp" version = "~> 3.0" token = "XXXXXXXXXXXXXXXXXXXXX" organization_id = "XXXXXXXXXXXXXXXXXXXXXXXXXX" account_type = "management" billing_export_dataset_name = "your_billing_export_dataset_name" billing_export_table_name = "your_billing_export_table_name" providers = { google = google.management } } module "attribute_sub1" { source = "ZouzIO/attribute-sensor/gcp" version = "~> 3.0" token = "XXXXXXXXXXXXXXXXXXXX" organization_id = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" account_type = "sub" billing_info = module.attribute_management.billing_info providers = { google = google.sub1 } } ``` 2. Apply the Terraform: ```bash terraform apply ``` #### Step 2.2 — Deploying the Sensor with Helm on GKE The following steps should be repeated on every GKE cluster where you want to deploy the sensor. 1. Save the values file provided by Attribute (`values.yaml`). This file contains a unique ephemeral token. 2. Review the Java instrumentation settings in the values file. The file includes the following flags by default: ```yaml # Java instrumentation settings sensorDisableAutoJavaInstrumentation: true javaAutoInject: enabled: true ``` This configuration is supported on Kubernetes **1.28 and above**. The injection backend is selected automatically, so no version-specific adjustment is needed. To use the sensor's dynamic Java instrumentation instead of admission-time injection, set `javaAutoInject.enabled` to `false` **and** set `sensorDisableAutoJavaInstrumentation` to `false`. The two must never be enabled together. For a full explanation of both modes, see the [Attribute Java Instrumentation Guide](https://help.doit.com/docs/attribute/integrations/cloud-integrations/attribute-java-instrumentation-guide). 3. Verify your Helm version — version 3.8.0 or above is supported: ```bash helm version ``` 4. Install the Helm chart: ```bash helm upgrade -i attribute \ oci://quay.io/attribute/operator-chart \ -f \ -n attribute \ --create-namespace ``` 5. **Verification.** Run the following to verify the Helm release and that the operator and sensor are running: ```bash helm list -n attribute kubectl get pods -n attribute ``` Example expected output: ![Terminal output of helm list -n attribute showing the attribute release deployed with the operator-chart](@site/assets/png/attribute/tf-helm-list.png) ![Terminal output of kubectl get pods -n attribute showing five attribute pods all in Running state with READY 1/1](@site/assets/png/attribute/tf-kubectl-pods.png) :::note If you'd like to deploy the sensor on other compute resource types (such as standalone), refer to the relevant sensor deployment documentation. ::: --- *Trademarks: Google Cloud is a trademark of Google LLC. Terraform is a registered trademark of HashiCorp, Inc. Kubernetes is a registered trademark of The Linux Foundation. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/cloud-integrations/gcp/attribute-sesnsor-for-gke-autopilot # Attribute Sensor for GKE Autopilot In the ever-evolving landscape of cloud-native technologies, Google Kubernetes Engine (GKE) Autopilot is simplifying Kubernetes operations by managing the underlying infrastructure. We are thrilled to announce that the **Attribute Sensor is now officially certified for GKE Autopilot**, empowering GCP customers with deep, real-time cost and resource utilization visibility for Autopilot workloads. This certification means Google Cloud customers using Autopilot can now easily adopt Attribute's FinOps zero-tagging technology and access granular application-layer costs across teams, products, and customers. ## eBPF on GKE Autopilot GKE Autopilot streamlines cluster management by abstracting away node configuration and management. This managed environment, however, presents unique considerations for monitoring and security tools that require deeper access to the underlying kernel. This is where the power of **[eBPF](http://ebpf.io/) (extended Berkeley Packet Filter)** comes in. The Attribute Sensor is built on eBPF technology, which allows it to gain deep visibility into resource consumption at the application level through packet inspection. This technology operates within a secure, sandboxed environment in the kernel with read-only permissions, ensuring both advanced security and low operational risk. Our support for GKE Autopilot is made possible through Google's partner program, which allows select, verified solutions to run with the necessary privileges in Autopilot clusters. This means you can benefit from the Attribute Sensor's capabilities without compromising the security and managed nature of your Autopilot environment. ## Why Attribute Sensor for Your GKE Autopilot Clusters? As you embrace the operational efficiencies of GKE Autopilot, understanding your cost drivers becomes even more critical. The Attribute Sensor provides the missing piece of the puzzle by: - **Holistic cost understanding:** Move beyond basic infrastructure costs and attribute expenses to specific features, applications, teams, and customers. - **Granular resource utilization:** By inspecting network packets, the sensor generates and aggregates usage metrics across all your workloads, including shared resources. For instance, it can pinpoint the resources consumed by a specific microservice's API call. - **Optimized for performance:** The sensor is designed for high-traffic environments, aggregating usage metrics within the cluster before transmitting data to the Attribute backend. This minimizes data transfer costs and is optimized for large-scale deployments. Performance tests have shown the sensor has a negligible impact on application performance, with CPU usage remaining within a 5% cap even under peak loads. - **Security-first design:** The Attribute Sensor operates with a security-first approach. All data is transferred over TLS-encrypted connections, and any sensitive information is stripped within your environment before transmission. The eBPF program itself undergoes strict verification to prevent any potential exploits. ## Getting Started with Attribute on GKE Autopilot Deploying the Attribute Sensor in your GKE Autopilot environment is straightforward. The sensor is deployed using an operator, and our dynamic configuration support extends to environments leveraging GCP Autopilot. To learn more and get installation documentation specific to your environment, please contact our support team at [support@attrb.io](mailto:support@attrb.io). --- *Trademarks: Google Cloud is a trademark of Google LLC. Kubernetes is a registered trademark of The Linux Foundation. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/third-party/attribute-anthropic-integration-guide # Anthropic Integration ## Introduction The Attribute platform can be integrated with different third-party cloud services in order to assure a consolidated cost view and complete cost attribution. This document describes the required steps to complete the integration with Anthropic billing. ## Requirements Attribute supports integration with both types of Anthropic organization: - **Claude Platform Organization** — API-based usage, with models accessed via the Anthropic API. - **Claude Enterprise Organization** — seat-based claude.ai products (such as Claude Code, Cowork, etc.). In order to obtain secure access to Anthropic billing information, the proper integration keys should be provided according to your Anthropic organization type. ## Integration Steps for Claude Platform Organization For Claude Platform organizations, an Admin API key is required to grant read access to your organization's usage and cost reporting endpoints. The key will start with `sk-ant-admin...`. This key cannot be used to make model API calls or modify your organization settings. Please follow the steps below to generate this key and securely provide it to Attribute. ### Generating a New Admin API Key 1. Sign in to your [Anthropic Console](https://console.anthropic.com). You will need **Admin** or **Owner** permissions in your organization. 2. Navigate to **API keys**. In the left sidebar, click on **Admin keys**. 3. Create a new admin key: - Name your key. - Make sure you keep the key information, as you will not be able to access it again. ![Claude Console Admin keys page, with arrows pointing to "API keys" in the left sidebar, "Admin keys" in the settings nav, and the "Create admin key" button](@site/assets/png/attribute/claude-console-admin-keys.png) 4. Verify the key has the correct permissions using the following command. The expected result is a JSON response with a `data` array: ```bash curl -sG "https://api.anthropic.com/v1/organizations/cost_report" \ --data-urlencode "starting_at=2026-03-10T00:00:00Z" \ --data-urlencode "ending_at=2026-04-01T00:00:00Z" \ --data-urlencode "bucket_width=1d" \ -H "x-api-key: sk-ant-admin..." \ -H "anthropic-version: 2023-06-01" \ -H "anthropic-beta: fast-mode-2026-02-01" ``` 5. Securely share the admin key with Attribute. :::note If you prefer not to share your Admin API key with Attribute directly, you can create an internal proxy that makes the request to the billing API on your behalf. The Admin API key never leaves your environment in that case. ::: ## Integration Steps for Claude Enterprise Organization For Claude Enterprise organizations, an Enterprise Analytics API key is required to grant read access to your organization's usage and cost reporting endpoints. The key will start with `sk-ant-api...`. This key cannot be used to make model API calls or modify your organization settings. Please follow the steps below to generate this key and securely provide it to Attribute. ### Generating a New Enterprise Analytics API Key 1. Sign in to [claude.ai](https://claude.ai) with a **Primary Owner** account of your Enterprise organization. 2. Navigate to the [Analytics API keys page](https://claude.ai/analytics/api-keys). 3. Create a new analytics API key: - Name your key. - The key is created with the `read:analytics` scope. - Make sure you keep the key information, as you will not be able to access it again. 4. Verify the key has the correct permissions using the following command. The expected result is a JSON response with a `data` array: ```bash curl -sG "https://api.anthropic.com/v1/organizations/cost_report" \ --data-urlencode "starting_at=2026-03-10T00:00:00Z" \ --data-urlencode "ending_at=2026-04-01T00:00:00Z" \ --data-urlencode "bucket_width=1d" \ -H "x-api-key: " \ -H "anthropic-version: 2023-06-01" \ -H "anthropic-beta: fast-mode-2026-02-01" ``` 5. Securely share the Analytics API key with Attribute. ## Contact If you require any additional assistance, please contact Attribute's support at [support@attrb.io](mailto:support@attrb.io). Alternatively, you can request to join a shared Slack channel for support. To request access, email [support@attrb.io](mailto:support@attrb.io) with your details. --- *Trademarks: Anthropic and Claude are trademarks of Anthropic, PBC. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/third-party/attribute-mongo-atlas-integration-guide # MongoDB® Atlas Integration For a successful MongoDB Atlas integration, all you need is an API key. This page covers: - Generating an API key using the MongoDB Atlas user interface. - Generating an API key using Attribute's automated CLI tool. - Handling Atlas's API Access List for API keys. When creating an API key, keep the following in mind: 1. **Use organization-level authentication.** Atlas supports both organizational and project-level authentication. To ensure visibility across your entire MongoDB Atlas deployment, the API key must be created at the **organization** level. 2. **Permissions required.** The API key must include both **Organization Billing Viewer** and **Organization Read Only**. 3. **Role required.** To generate an API key, you need the **Organization Owner** role. ## Generating an API Key ### Using the MongoDB Atlas UI 1. Browse and sign in to [MongoDB Cloud](https://cloud.mongodb.com). 2. Using the drop-down organization selector at the top-left of your screen, select the Atlas organization you'd like to create the deployment for. ![MongoDB Atlas organization selector dropdown showing a list of organizations](@site/assets/png/attribute/mongo-atlas-org-selector.png) 3. Select **Access Manager** on the left sidebar. If you can't find it, click the **gear icon** to the right of your organization name (next to the organization selector). 4. On the Access Manager page, look for the **Add new** button in the top-right and select **API Key**. ![MongoDB Atlas Access Manager with the "Add new" dropdown open, "API Key" highlighted](@site/assets/png/attribute/mongo-atlas-add-new-api-key.png) 5. Provide a description such as `Attribute`, then select both **Organization Billing Viewer** and **Organization Read Only** permissions. ![Create API Key form with description "Attribute" and the Organization Billing Viewer and Organization Read Only checkboxes both ticked](@site/assets/png/attribute/mongo-atlas-create-api-key-form.png) 6. Click **Next**, then copy both the **Public Key** and the **Private Key**. ![Save API Key Information page showing the public key and private key fields with the Done button highlighted](@site/assets/png/attribute/mongo-atlas-save-api-key.png) :::caution The private key is only displayed once. Submit it to Attribute immediately — and also share your **Organization ID**. If you can't share it right away, store it somewhere safe. ::: 7. If your Atlas organization enforces an IP Access List for the Atlas API, you'll need to add access list entries for the new key. See [API Access List](#api-access-list) below to check whether your organization enforces this, and how to add entries. ### Using Attribute's Automated Tool 1. Make sure you have the **Atlas CLI** installed. See the [Atlas CLI documentation](https://www.mongodb.com/docs/atlas/cli/) if you need to install it. 2. Execute the script and follow the on-screen instructions. The tool walks you through logging in with the Atlas CLI, prompts you to choose the organization to create the key for, creates the key, and applies Attribute's IP addresses to the new key's IP Access List automatically. Read the tool's instructions and messages closely. ## API Access List ### Check API Access List Status To find out whether your Atlas organization requires an IP access list for the Atlas Administration API, navigate to your organization's **Settings** using the left menu. ![MongoDB Atlas Organization Settings page with the Settings menu item highlighted on the left sidebar](@site/assets/png/attribute/mongo-atlas-organization-settings.png) Then check the **Require IP Access List for the Atlas Administration API** toggle: ![Require IP Access List for the Atlas Administration API setting, shown with the toggle turned off](@site/assets/png/attribute/mongo-atlas-ip-access-list-toggle.png) - If the toggle is **off** (as in the example above), no further action is needed — submit your keys to Attribute. - If the toggle is **on**, continue to the next section to add IP access entries. ### Adding IP Access Entries 1. Go back to the **Access Manager** page, click the three dots next to the new API key, and choose **Edit Permissions**. ![Access Manager Actions menu showing Edit Permissions and View Details options](@site/assets/png/attribute/mongo-atlas-edit-permissions-menu.png) 2. Click **Next**, then **Add Access List Entry**. ![Edit API Key page showing the API Access List section with the Add Access List Entry button circled](@site/assets/png/attribute/mongo-atlas-add-access-list-entry.png) 3. Add the following IP addresses: - `34.41.229.120` - `35.224.163.103` ![API Access List with both Attribute IP addresses added as entries](@site/assets/png/attribute/mongo-atlas-access-list-entries.png) 4. Click **Done** — and that's it. Submit your keys to Attribute. ## Contact If you require any additional assistance, please contact Attribute's support at [support@attrb.io](mailto:support@attrb.io). Alternatively, you can request to join a shared Slack channel for support. To request access, email [support@attrb.io](mailto:support@attrb.io) with your details. --- *Trademarks: MongoDB is a registered trademark of MongoDB, Inc. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/third-party/attribute-openai-integration-guide # OpenAI Integration ## Introduction The Attribute platform can be integrated with various third-party cloud services to provide a consolidated cost view and complete cost attribution. This document describes the steps required to complete the integration with OpenAI billing. ## Requirements To obtain secure access to OpenAI billing information, Attribute needs an **Admin API key** with **Usage API scope** permissions. Follow the steps below to generate this key and securely share it with Attribute. ## Generating a New Admin API Key 1. [Sign in to your OpenAI account](https://platform.openai.com/docs/overview). :::note You'll need billing permissions for your organization — typically the **Admin** role. ::: 2. Click the **settings** (gear) icon in the top-right corner, then navigate to **Admin keys**. ![OpenAI developer platform with the settings gear icon in the top-right corner highlighted by a red box and arrow](@site/assets/png/attribute/openai-settings-icon.png) ![OpenAI Organization settings page with the "Admin keys" item highlighted in the left sidebar](@site/assets/png/attribute/openai-admin-keys-sidebar.png) 3. Click **Create new Admin key** and configure the key: 1. Choose **Restricted** permissions. 2. Change **Usage API Scope** to **Read**. 3. Click **Create admin key**. ![Create new admin key dialog with four numbered annotations: (1) the Create new Admin key button at top-right, (2) the Restricted permissions tab selected, (3) Usage API Scope set to Read, and (4) the Create admin key button](@site/assets/png/attribute/openai-create-admin-key-form.png) 4. Save your secret key in a safe place — **you won't be able to view it again**. ![Save your key dialog showing the new sk-admin-... key with the Copy button highlighted](@site/assets/png/attribute/openai-save-your-key.png) 5. Verify the key has the correct permissions using the following command (replace `YOUR_API_KEY` with the key you just generated): ```bash curl --location 'https://api.openai.com/v1/usage?date=2025-06-22' \ --header 'Authorization: Bearer YOUR_API_KEY' ``` 6. Securely share the key with Attribute. ## Contact If you require any additional assistance, please contact Attribute's support at [support@attrb.io](mailto:support@attrb.io). Alternatively, you can request to join a shared Slack channel for support. To request access, email [support@attrb.io](mailto:support@attrb.io) with your details. --- *Trademarks: OpenAI is a trademark of OpenAI. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/third-party/attribute-slack-integration-guide # Slack Integration ## Introduction The Attribute platform can be integrated with various notification channels in order to provide productive integration with our customers' regular business notification workflows. The Attribute platform currently supports two options for Slack integration: Slack Webhooks, or the full Attribute for Slack app. :::note Triggering actions from Slack is only available with the Attribute for Slack app. ::: ## Integration Using Attribute for Slack The following steps complete the Slack integration using Attribute for Slack: 1. Navigate to the **Setup** section in the Attribute Dashboard and click **Integrations** in the left sidebar. ![Attribute Setup → Integrations page showing the empty "No Output Integration yet" state](@site/assets/png/attribute/slack-setup-integrations-empty.png) 2. Click **Create an Integration**, choose **Slack Connection** as the integration type, then click **Connect to Slack**. ![New Integration dialog with Slack Connection selected and the Connect to Slack button visible](@site/assets/png/attribute/slack-new-connection-dialog.png) 3. You will be redirected to the Slack integration page to grant Attribute permission to access channels and conversations and perform actions in them. Click **Allow**. ![Slack permissions screen: "Attribute is requesting permission to access the Attribute Slack workspace" with Cancel and Allow buttons](@site/assets/png/attribute/slack-permissions-allow.png) 4. If you don't have permission to authorize the application, send the link `https://slack.app.attrb.io/slack/install` to an admin who can complete the integration: 5. Click **Confirm Integration** to finish. ![Finish Integration dialog confirming the Slack Connection to the Attribute workspace](@site/assets/png/attribute/slack-finish-integration-dialog.png) 6. The new integration now appears in your Slack connections list. ![Integrations list showing the Slack Connection with "Attribute" integration created by Attribute Team](@site/assets/png/attribute/slack-integration-list-connection.png) ## Integration Using Slack Webhook The following steps complete the Slack integration using a Slack Webhook: 1. Navigate to the **Setup** section in the Attribute Dashboard and click **Integrations** in the left sidebar. ![Attribute Setup → Integrations page showing the empty "No Output Integration yet" state](@site/assets/png/attribute/slack-setup-integrations-empty.png) 2. Click **Create an Integration** and choose **Slack Webhook** as the integration type. ![New Integration dialog with the Integration Type dropdown open, showing both Slack Connection and Slack Webhook options](@site/assets/png/attribute/slack-new-integration-type-dropdown.png) 3. Enter an **Integration Name** of your choosing and the **Webhook URL** from Slack, then click **Connect**. ![New Integration dialog filled in with integration name "Test" and a Slack webhook URL](@site/assets/png/attribute/slack-new-webhook-dialog.png) 4. The new integration now appears in your Slack connections list. ![Integrations list showing both a Slack Connection and a Slack Webhook entry](@site/assets/png/attribute/slack-integration-list-both.png) ## Create a Notification Now that the integration is set up, you can start creating notifications. 1. Navigate to **Setup → Notifications**. 2. Click **Create a Notification**. From here, you can create a new alert, choose the notification channel, set conditions, and configure the trigger. ![Create a Notification dialog with sections for Settings (alert name, type, channel), Conditions (accounts, resource types, anomaly type, affected items), and Trigger (severity)](@site/assets/png/attribute/slack-create-notification-dialog.png) ## Contact If you require any additional assistance, please contact Attribute's support at [support@attrb.io](mailto:support@attrb.io). Alternatively, you can request to join a shared Slack channel for support. To request access, email [support@attrb.io](mailto:support@attrb.io) with your details. --- *Trademarks: Slack is a trademark of Slack Technologies, LLC, a Salesforce company. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/integrations/third-party/attribute-snowflake-integration-guide # Snowflake Integration ## Introduction The Attribute platform can be integrated with different 3rd party cloud services in order to assure consolidated cost view and complete cost attribution. This document describes the required step to complete the integration with Snowflake billing. ## Requirements To provide detailed information for the entire organization, Attribute requires access to an [organization account]. In order to obtain this access securely the following is required: - A RSA key pair for authentication. - A dedicated warehouse to ensure no interruptions to your operations. - A new role to encapsulate all of the required privileges. - Assignment of the required privileges for the new role. - [USAGE] privilege for the new warehouse. - [ORG_USAGE_ADMIN] application role an organization account. - A network policy to secure user access. - A new service user, assigned the new role and network policy. ## Integration Steps - Generating a RSA key pair using openssl. - Integration using an existing organization account. - Creating a new organization account. All of the Snowflake SQL commands can be executed using a *Snowsight* worksheet, *Snowflake*'s UI web interface: ![Snowsight worksheet interface](@site/assets/png/attribute/snowsight_worksheet.png) ### 1. Generating a New RSA Key Pair The following steps will guide you through creating a new RSA key pair and converting it as required by Snowflake. **1.1.** Open a command shell where openssl is available. **1.2.** Generate a new private key (`key.p8`) using the following command. Make sure to choose a strong passphrase. ```bash openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 des3 -inform PEM -out key.p8 ``` **1.3** Generate a public key (`key.pub`) using the following command. Make sure to use the private key generated in step 1.2. Specify the passphrase you used when creating the private key. ```bash openssl rsa -in key.p8 -pubout -out key.pub ``` Your public key, `key.pub`, should look something like this: ![Example public key output](@site/assets/png/attribute/public_key_example.png) **1.4.** Convert the public key format to match Snowflake requirements. Using the public key in Snowflake requires removing the delimiters and line breaks. Convert your public key (`key.pub`) to snowflake format using the following command: ```bash sed '1d;$d' key.pub | tr -d '\n' > key.snowflake.pub ``` You will use the public key, `key.snowflake.pub`, when creating the new user. To be able to login to the new user, we will need the following: - The private key. - The passphrase you've chosen for the private key. ## Integration Using an Existing Organization Account The following walkthrough covers the integration process using an **organization account**. Make sure to run the commands using a user under the organization account, and that the user can use both the **GLOBALORGADMIN** and **ACCOUNTADMIN** roles. If you need to create an organization account - refer to appendix B - creating a organization account. Following are the steps required to complete the integration. For your convenience, you can find the integration script - Appendix B - Integration script, which can be used as copy / paste. Make sure to use the role ACCOUNTADMIN for running the commands: ```sql USE ROLE ACCOUNTADMIN; ``` ### 1. Creating a Warehouse Creating a new warehouse ensures that Attribute queries do not block any of your operations. Create a new warehouse which is optimized to minimize costs using the following command: ```sql CREATE OR ALTER WAREHOUSE attributeWarehouse WITH WAREHOUSE_SIZE = 'XSMALL' WAREHOUSE_TYPE = 'STANDARD' AUTO_SUSPEND = 30 INITIALLY_SUSPENDED = TRUE COMMENT = "Attribute's Warehouse"; ``` ### 2. Creating a Role Create a new role which will encapsulate all of the required privileges using the following command: ```sql CREATE ROLE attributeRole COMMENT = "Encapsulates privileges required for Attribute's service"; ``` ### 3. Assigning the Required Privileges You will need to assign the application role `ORG_USAGE_ADMIN` to the new role created in step 2. In order to do that, you need to use the role `GLOBALORGADMIN`. Additionally, you will need to grant usage privileges on the new warehouse: ```sql USE ROLE GLOBALORGADMIN; GRANT APPLICATION ROLE ORG_USAGE_ADMIN TO ROLE attributeRole; USE ROLE ACCOUNTADMIN; GRANT USAGE ON WAREHOUSE attributeWarehouse TO ROLE attributeRole; ``` ### 4. Creating a Network Policy Create a new network policy, enabling access from Attribute IP addresses using the following command: ```sql CREATE OR REPLACE NETWORK POLICY attributeAccess ALLOWED_IP_LIST = ('34.41.229.120', '35.224.163.103'); ``` ### 5. Creating a User Create a new service type user using the following command. Use the public key in Snowflake's required format (contents of `key.snowflake.pub`) for `RSA_PUBLIC_KEY` field, which was created in section 1 - generating the RSA key. ```sql CREATE OR REPLACE USER attributeSVC TYPE = SERVICE DEFAULT_ROLE = attributeRole DEFAULT_WAREHOUSE = attributeWarehouse NETWORK_POLICY = attributeAccess RSA_PUBLIC_KEY = '' COMMENT = "Attribute's Service User"; ``` Finally, grant the role to the account: ```sql GRANT ROLE attributeRole TO USER attributeSVC; ``` ### Collect the Information Required for the Integration Along with the private key and its passphrase, include the output for the following query, which displays the account identifier: ```sql SELECT CURRENT_ORGANIZATION_NAME() || '-' || CURRENT_ACCOUNT_NAME(); ``` ## Appendix A - Organization Account Integration Script The following script contains all of the commands mentioned above. Replace the placeholder in `RSA_PUBLIC_KEY` with the public key, and run the entire script as is. ```sql -- Using the appropriate role USE ROLE ACCOUNTADMIN; -- Creating a warehouse CREATE OR ALTER WAREHOUSE attributeWarehouse WITH WAREHOUSE_SIZE = 'XSMALL' WAREHOUSE_TYPE = 'STANDARD' AUTO_SUSPEND = 30 INITIALLY_SUSPENDED = TRUE COMMENT = "Attribute's Warehouse"; -- Creating a role CREATE ROLE attributeRole COMMENT = "Encapsulates privileges required for Attribute's service"; -- Assigning privileges USE ROLE GLOBALORGADMIN; GRANT APPLICATION ROLE ORG_USAGE_ADMIN TO ROLE attributeRole; USE ROLE ACCOUNTADMIN; GRANT USAGE ON WAREHOUSE attributeWarehouse TO ROLE attributeRole; -- Creating a network policy CREATE OR REPLACE NETWORK POLICY attributeAccess ALLOWED_IP_LIST = ('34.41.229.120', '35.224.163.103'); -- Creating a user CREATE OR REPLACE USER attributeSVC TYPE = SERVICE DEFAULT_ROLE = attributeRole DEFAULT_WAREHOUSE = attributeWarehouse NETWORK_POLICY = attributeAccess RSA_PUBLIC_KEY = '' COMMENT = "Attribute's Service User"; GRANT ROLE attributeRole TO USER attributeSVC; -- Retrieving account identifier SELECT CURRENT_ORGANIZATION_NAME() || '-' || CURRENT_ACCOUNT_NAME(); ``` ## Appendix B - Creating a New Organization Account The following walkthrough covers creating a new organization account. Replace the placeholders in the command and execute it in order to create the account. Make sure to run the queries using a user under an *ORGADMIN*-enabled account, and that the user can use the *ORGADMIN* role. ```sql USE ROLE ORGADMIN; CREATE ORGANIZATION ACCOUNT ADMIN_NAME = ADMIN_PASSWORD = '' EMAIL = '' EDITION = enterprise; ``` ## Contact If you require any additional assistance, please contact Attribute's support at [support@attrb.io](mailto:support@attrb.io). Alternatively, you can request to join a shared Slack channel for support. To request access, email [support@attrb.io](mailto:support@attrb.io) with your details. --- *Trademarks: Snowflake is a registered trademark of Snowflake Inc. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/overview/access-from-dci # Access Attribute from the console Open Attribute from the console. Attribute loads within the console, so you stay in one place. :::note Attribute is only available when your DoiT plan includes Attribute. If you're unsure whether Attribute is included for you, contact your DoiT account manager or review your [Cloud Intelligence plan](https://www.doit.com/pricing/). ::: ## Required permissions To open Attribute from the console, your DoiT account must have one of the following permissions: | Permission | Description | | :--- | :--- | | Attribute Admin | Full administrative access to Attribute. | | Attribute Editor | Edit access to Attribute. | | Attribute Reader | Read-only access to Attribute. | The pre-built [Admin](https://help.doit.com/docs/user-management/manage-roles#admin) role includes **Attribute Admin**. **Attribute Editor** and **Attribute Reader** can be assigned through [custom roles](https://help.doit.com/docs/user-management/manage-roles#custom-roles). ## Open Attribute 1. Sign in to the DoiT console. 1. Select **Workload optimization** from the top navigation mega menu, and then select **Attribute**. 1. Wait for Attribute to load. The first time your organization opens Attribute, setup may take a few moments. 1. When setup completes, the Attribute dashboard appears within the console page. :::note First-time setup The first time anyone in your organization opens Attribute from the console, setup runs for your organization. A progress indicator is displayed while setup runs. Any user who opens Attribute during that time sees the same progress indicator until setup completes. This is a one-time process. After setup finishes, the Attribute dashboard appears in the console. ::: ## Troubleshooting If something goes wrong while opening Attribute, the console displays a message describing the issue and a **Try again** button. - **You don't see the option to open Attribute**: Verify that Attribute is included in your DoiT plan and that your DoiT account has an Attribute permission (**Attribute Admin**, **Attribute Editor**, or **Attribute Reader**). - **"Setup is taking longer than expected"**: Setup hasn't completed within the expected time. Select **Try again** to retry. - **"We couldn't set up Attribute"**: Setup failed. Select **Try again**, and if the issue persists, contact [DoiT support](https://support.doit.com). - **"Something went wrong opening Attribute"**: An unexpected error occurred. Select **Try again**. If the problem continues, contact [DoiT support](https://support.doit.com). --- URL: https://help.doit.com/docs/attribute/overview/attribute-data-flow # Data Flow This document outlines how the Attribute platform securely collects, processes, and analyzes your data to provide granular cloud cost insights. Our architecture is built on a foundation of robust security and transparency, ensuring your data is handled with the utmost care at every stage. ## Data Flow Stages The Attribute data flow can be broken down into three main stages: - Data Collection within customers' environment. - Data Processing in the Attribute backend. - Data Presentation through the Attribute Dashboard. ![Attribute data flow architecture: customer environment connects to the Attribute backend on GCP via Parquets, OpenTelemetry, and API calls](@site/assets/png/attribute/data-flow-architecture.png) ### Data Collection To provide detailed cost allocations, Attribute utilizes three primary data sources: - **Consumption Data:** Collected via the proprietary Attribute Sensor deployed within customers' environment. - **Finance Data:** Pulled from your cloud billing reports. - **Telemetry Data:** Sourced from cloud APIs and other telemetry sources for resource utilization. The core of our data collection within your environment is the Attribute Sensor. To assure the security and stability of the customers' environment, the Attribute Sensor was designed and developed with a modern security-first approach: - **Technology:** The sensor is built on eBPF (extended Berkeley Packet Filter) technology, which safely inspects network packets from within the kernel of your systems. It operates in a read-only, sandboxed environment, ensuring minimal operational risk. - **Deployment:** You can deploy the sensor on your compute entities, such as Kubernetes clusters or standalone virtual machines. Deployment is highly configurable, allowing you to choose precisely which workloads to monitor. - **Function:** By inspecting network packets, the sensor aggregates usage metrics. For example, it can identify a specific service running in a Kubernetes cluster and measure the resources consumed by a particular query. The sensor only analyzes network traffic for specific protocols explicitly agreed upon with the customer (whitelist). - **Anonymization and Security:** Critically, any sensitive or private information is stripped from the data **within customers' environment** before it is transmitted. This ensures no sensitive data ever leaves your premises. The aggregated, anonymized data is then securely transmitted to the Attribute backend. - **Transmission:** Data is sent using the encrypted OpenTelemetry protocol, which offers full transparency into every piece of data collected. This secure transmission is authenticated using JWT and protected by TLS encryption. In addition, the use of OpenTelemetry ensures full transparency into collected data and allows customers to implement additional restrictions for enhanced security by implementing an optional OpenTelemetry endpoint. ### Data Processing Once customers' anonymized usage data and billing information arrive at the Attribute backend, the processing stage begins. This entire process runs on our secure Google Cloud Platform (GCP) infrastructure. - **Data Consolidation:** Data from the sensor and your cloud billing reports are consolidated and parsed to accurately determine true costs. - **Core Processing:** We use a robust set of GCP services for processing: - **Data Processing:** Complex ETL (Extract, Transform, Load) jobs are handled by SparkApplication and Big Data solutions. - **Compute:** Containerized applications are managed using Kubernetes Engine. - **Event Streaming:** A Pub/Sub service is used for event streaming. - **Data Security:** To ensure the security of your data within our backend, we implement multiple measures, including: - Data encryption both at rest and in transit. - Separated datasets for each customer within our data stores. - A strict least-privilege access methodology. - **Scalability and Reliability:** All backend components are designed to be redundant and auto-scaling to ensure high availability, reliability, and an optimal user experience. ### Data Presentation The final stage is the delivery of calculated data and cloud cost insights through the Attribute Dashboard. - **Secure Infrastructure:** The Dashboard application layer is also built on a secure and scalable GCP infrastructure. - **Data Repositories:** ClickHouse, BigQuery, and Atlas MongoDB® serve as the data backbone for the dashboard, maintaining the same high standards of security, data segmentation, and encryption as our backend. - **User Access:** Access to the dashboard is managed through secure Single Sign-On (SSO) authentication, ensuring strict data governance. - **High Availability:** The dashboard components are designed for redundancy and auto-scaling to ensure they are always available and reliable. ## Appendix A — Secure Handling of Sensitive Data This appendix explains the strict security measures built into the Attribute platform to address concerns around data privacy and transmission. No sensitive data from your environment is ever sent to us. The platform is designed to process data locally, within your environment, and only transmits minimal, non-sensitive metadata necessary for cost analysis. This architecture ensures that proprietary or confidential information never leaves your system. We take a security-first, zero-trust approach, anchored in the principle of data minimization. ### 1. Protocol Parsing and Event-Based Transmission The Attribute Sensor does not transmit raw network packets. Instead, it serves as an intelligent data processor within your environment. - **Selective Protocol Analysis:** The sensor inspects network traffic for specific protocols that have been explicitly agreed upon and whitelisted. Any traffic not matching these protocols is ignored. - **Event Generation, Not Packet Forwarding:** For the whitelisted protocols, the Attribute sensor parsers extract only the specific metadata required for cost allocation. This metadata is used to construct structured "events." It is these purpose-built, minimal events, not the original network packets, that are transmitted. This process ensures that superfluous or sensitive data from the network traffic is discarded at the source. For reference, Section 3 includes an excerpt of the code used for building a sample event. ### 2. Proactive Exclusion of Sensitive Information The sensor is explicitly designed to detect and exclude sensitive data during analysis. This exclusion occurs entirely within the customer's environment, ensuring that such data is never transmitted to Attribute's backend. - **Secrets and Credentials:** The Attribute sensor does not parse or transmit secrets, API keys, passwords, or authentication tokens. - **Cookies:** All cookie data within network traffic is ignored. - **Personally Identifiable Information (PII):** Any PII that may reside within queries is redacted using common libraries. ### 3. Example Code for Building an Event ```go r.metricBuilder.BuildCompoundMetric(func(metric metricbuilder.CompoundMetric) { metric = setMetricResourceAttributesFromEnvInfo( metric, envInfo.Region, envInfo.Host, metricDescriptor.Name, ) for fields, values := range data.Values { wl := fields.Workload scope := metric.NewScope("workload", "") scope = setScopeAttributeFromWorkload(scope, wl) scope = setScopeAttributeFromEnvInfo(scope, envInfo.Name, envInfo.Type) scopeFillAttributesFromMetricFields(&fields, scope) gauge := scope.NewGauge("metric") measurement := gauge.NewMeasurement() measurement.SetTimestamp(eventTime) measurement.SetAttribute("attributes", map[string]interface{}{ "host": fields.F0, "method": fields.F1, "path": fields.F2, "request.count": values.Count, "request.total.time.ns": values.V0, }) } }) ``` --- *Trademarks: Google Cloud is a trademark of Google LLC. MongoDB is a registered trademark of MongoDB, Inc. Kubernetes and OpenTelemetry are trademarks of The Linux Foundation. Apache Spark is a trademark of the Apache Software Foundation. ClickHouse is a registered trademark of ClickHouse, Inc. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute/overview/overview # Overview As organizations deepen their reliance on cloud-native infrastructure and microservices, the complexity of cost attribution grows exponentially. Traditional cloud cost management solutions — built on manual tagging, static rules, and siloed visibility — can no longer keep pace with the dynamic nature of today's infrastructure. After 15 years that all FinOps industry leverages the same data, Attribute introduces a modern, automated, no-tagging, and observability-driven approach to FinOps. Leveraging **eBPF-based telemetry, automated microservices discovery, and real-time cost attribution**, our platform equips engineering and finance teams with the tools they need to optimize cloud spend, understand cost-to-serve, and align infrastructure decisions with business value. ## FinOps in the Age of Distributed Systems Cloud cost visibility is no longer just a financial concern — it's an operational imperative. As teams adopt containerized workloads and multi-tenant approaches, cost allocation becomes harder and more ambiguous. Organizations are struggling with: - **Manual tagging overhead** that doesn't scale. - **Shared resources** that can't be neatly attributed. - **Poor visibility** into microservices and team-specific spend. - **Blind spots in customer-level cost modeling**. - **Limited interoperability** with evolving data and analytics stacks. ## Key Product Capabilities ### eBPF-Based Observability At the core of our solution is an ultra-lightweight, kernel-level **eBPF sensor** that operates at runtime with minimal code instrumentation. This sensor: - Captures real-time infrastructure and network activity. - Ties usage to services, APIs, or customers based on live behavior. - Adds no performance overhead or architectural complexity. ### Automated Microservices Discovery No more static service catalogs or brittle configurations. The platform: - Automatically identifies microservices and dependencies. - Adapts in real-time to ephemeral or newly deployed workloads. - Maps services to teams, business units, or environments. ### Cost Attribution to Unit Economics Using packet inspection and runtime metadata, our system can: - Attribute costs directly to features, teams, or customers. - Support **multi-tenant environments** and dynamic workloads. - Enable unit economics such as **cost-per-feature, cost-per-team, or cost-per-customer**. ### Shared Resource Allocation We intelligently allocate shared resources (e.g., databases, message queues) using weighted models informed by actual runtime usage — removing guesswork and improving accuracy. ## Main Features - Custom groupings on runtime and metadata. - Holistic cost visibility across different third-party SaaS providers, including **Snowflake and MongoDB® Atlas**. - **Token cost attribution for OpenAI:** fine-grained tracking of inference and endpoint usage. - Usage-based anomaly detection. - Cost insights based on Attribute's data. - Advanced data transfer attribution to workloads, including destination transparency. - Sensor installation for many compute infrastructures: EKS, ECS, EC2 (standalone), Auto Scaling groups. - Many supported dissectors by our sensor, including: RDS, S3, ElastiCache, ElasticSearch, MSK, SQS. ## API Support The Attribute API enables you to interact with the data programmatically, extract large amounts of data, and integrate it with your internal systems. API tokens can be generated through our platform. The API was developed with a security-first approach, allowing generation and management of tokens via the Attribute dashboard application (including token expiration management, IP restrictions, etc.). The main API endpoints include: - Advanced workloads cost attribution, including breakdown to consumed cloud resources. - Full customers cost. - Anomaly detection. - Cloud resources cost. The API is queried asynchronously. ## Core Benefits - Deep visibility across the stack. - Zero manual tagging. - Improved unit economics. - Smooth transition from current tools. - Designed for DevOps and FinOps. ## Availability Attribute is available to DoiT customers who have the Attribute entitlement, including [PartnerOps customers](https://help.doit.com/docs/partnerops/overview). ## Forward-Looking Capabilities We're actively expanding the platform to support: - **Dynamic Widget Builder:** empower users to build their own dashboards from raw and processed data. - **AI-based FinOps assistant**. - **Additional integrations**. Our team is here to provide any further information needed about our product and technical stack. --- *Trademarks: AWS is a trademark of Amazon.com, Inc. or its affiliates. Snowflake is a registered trademark of Snowflake Inc. MongoDB is a registered trademark of MongoDB, Inc. OpenAI is a trademark of OpenAI. All other trademarks are the property of their respective owners.* --- URL: https://help.doit.com/docs/attribute-slo # Attribute Service Level Objective (SLO) for Support ## Definitions - "**Business Day**" means every day of the week, other than Friday, Saturday, or recognized public or religious holiday in Israel when banks are open for business. - "**Business Support Hours**" means 9:00AM to 5:00PM IST, during a Business Day. - "**Fault**" means an error or failure in the Services to operate in all material respects with the then-applicable Services’ documentation. - "**Support**" means the point of contact that is made available to Customer for resolution of Faults as set out in this SLA. - "**Scheduled Downtime**" means any period of scheduled maintenance used to perform any changes in the Services from time to time. Scheduled Downtime comprises: (a) planned and scheduled maintenance periods, as notified by Attribute from time to time with reasonable notice; and (b) where necessary, scheduled additional maintenance windows, as agreed with Customer, to implement Customer-approved changes or patches. - "**Services**" access and use of Attribute Platform together with related services as described in the principal agreement entered into between the parties to which this SLA is made part. ## Support Services Faults may be reported by Customer to the following email address: [support@attrb.io](mailto:support@attrb.io). The support services shall be provided only in the English language. When a new Fault is properly submitted to Support, Support shall use reasonable commercial efforts to try to identify the origins of the Fault and to respond to the Customer within the time periods specified in the table below, according to the Fault’s severity level. A Fault’s severity level may be re-evaluated upon submission of a workaround. | Severity Level | Description | Response Time (Business Hours) | | :------------- | :---------- | :----------------------------- | | Critical (P1) | Service is completely unavailable | 1 hours | | High (P2) | Major functionality impacted, no workaround | 4 hours | | Medium (P3) | Minor issue, partial impact, workaround is available | 1 business day | | Low (P4) | General inquiries, feature requests | 1 business days | For the purposes of the table above "**Response Time**" means the duration between the time from the Fault being reported by Customer or detected by Attribute, until the time that the on-call engineer has begun to work on the Fault. ## SLO Exclusions Attribute’s obligations hereunder are based on and subject to the Customer: (i) complying with Attribute’s instructions, if any, for performing any corrective action; and (ii) maintaining the connectivity (with acceptable bandwidth) of the Customer’s workstations to the main internet, as well as creating and maintaining firewall definitions and opening required ports that permit access to the Services. ## General Support Terms Attribute’s obligations under this SLO do not include on-site services or training. On-Site services and/or training services shall be provided to Customer by Attribute subject to agreement and an additional payment. --- URL: https://help.doit.com/docs/billing/billing-explained/aws-support # AWS support billing DoiT calculates AWS support charges based on your contract type and support plan. ## Contract type When signing a contract with DoiT, you choose the type of support on the management account level (see [AWS Resold Support](https://aws.amazon.com/premiumsupport/aws-resold-support/) for more information): - **Partner-Led**: You get high quality support through DoiT. - **AWS Resold**: You work directly with AWS Support and DoiT. ## Support plan AWS support charges are generally calculated on the management account level. Each account should belong to one of the [AWS support levels](https://aws.amazon.com/premiumsupport/plans/): _Basic_, _Developer_, _Business_, _Business+_, _Enterprise On-Ramp_, _Enterprise_, or _Unified Operations_. :::note As of December 2nd, 2025, Developer Support and Business Support are no longer available for new subscriptions. Enterprise On-Ramp is also deprecated. See [AWS Support Frequently Asked Questions](https://aws.amazon.com/premiumsupport/faqs/) for more information. ::: On top of these plans, DoiT offers _Partner-Led Enterprise Support (PLES)_, which is a special deal on which you pay Business Support pricing and get the benefits of DoiT's Enterprise Support. To determine the support plan of your account, we use the following sources, in hierarchal order: 1. The account is part of DoiT Partner-Led enterprise support program. 1. The account's support plan is defined in the MPA Ops page, which only applies to the DoiT account on the payer. 1. The account's support plan is defined on the CUR files. 1. If none of the above is true, the support plan is set to Basic Support. In addition: - If the account is labeled as Basic Support in the CUR files but as Enterprise in DoiT, then the account is considered as Enterprise for billing purposes. - If the account is labeled as Developer in the MPA Ops page but is part of DoiT Partner-Led enterprise support program, then the account is considered as Basic Support. ## Support pricing calculation DoiT applies [AWS Support Plan pricing tiers](https://aws.amazon.com/premiumsupport/pricing/) to the base cost for support. This section explains factors that affect the calculation of support charges. ### Contract type ### Discounts, EDP, and credits - The base cost for support comes before EDP, credits, and discounts (PPA is included for some). - Discounts are applied for all support levels and are shown in the billing as **PPA savings** on the support line description. - Credits and EDP related to support for your accounts are part of the DoiT contract with AWS; they are not passed to you. ### Reserved resources - When you prepay for reserved AWS resources and have a paid AWS Support plan, the upfront and recurring costs for these resources are included in your AWS Support fees. - If you already have reserved resources when you start a paid AWS Support plan, the prorated upfront costs are included in the first month of your AWS Support fee calculation. See [AWS Support Plan Pricing](https://aws.amazon.com/premiumsupport/pricing/) for more information about support for reserved resources. ### Flexsave for compute - DoiT uses the base cost of Flexsave applied (before EDP) as a 1-year rate. Flexsave comes before the base cost for support. - Flexsave account charges contribute to the calculation of your base cost for support. ### Limitations - We cannot change billing that comes from [CloudHealth on shared payer accounts](https://help.doit.com/docs/amazon-web-services/set-up-cloudhealth). ## Billing account and billing date Support charges are connected to an account. When the cost of support is aggregated from several accounts, by default, DoiT attaches the support charges to the account that has the highest cost eligible for support charges. ### Store support billing To allocate AWS support costs to a specific account: 1. Sign in to the DoiT console, select **Data ingestion and integrations** > **Integrations** from the top navigation mega menu. 1. Select **Amazon Web Services** from the left-hand menu. 1. Select the kebab menu (**⋮**) at the rightmost end of the AWS account to which you want to allocate AWS Support costs. 1. Select **Store support billing to this account**. ![Store support billing to this AWS account](@site/assets/png/aws-support-billing.png) If successful, the **Store support billing** field of the AWS account changes to **Enabled**. To reallocate AWS support costs, first remove the original allocation by repeating the steps above. Then, you can enable support billing on another account. ### Billing date The support billing is always set to the last day of the calendar month. ### Support billing on invoices AWS support charges are always tied to a specific AWS account on invoices, even when multiple accounts use the AWS support (you can run a Cloud Analytics report to find out the exact cost incurred by each account). By default, AWS support charges are embedded in the invoice line item of the designated account, in the drill down section of the [invoice details page](https://help.doit.com/docs/billing/invoices-and-payments/managing-invoices). If you need the support charges to appear as a shared cost in the summary section, for example, you're a parent company with subsidiaries, you have to open an expert inquiry and work with your DoiT account manager to update the invoice setting. Note that this only affects how the support charges appear on the invoice, not how the charges are stored in the system. ## AWS support charges in reports Cloud Analytics reports help you get a better understanding of how you're charged for AWS support. Below are a few examples. - Check discounts or rates of your AWS support plans, using the [**aws/item_desc**](https://help.doit.com/docs/cloud-analytics/reports/report-dimensions-groupings-and-filters#by-aws) system label: ![AWS support charge measured by cost](@site/assets/png/aws-support-charge-cost.png) - Check the base cost, using the **Usage** metric. ![AWS support charge measured by usage](@site/assets/png/aws-support-charge-usage.png) - Check the base cost for support by service, using the [**Base Cost for Support**](https://help.doit.com/docs/operate/metrics/predefined-metrics#base-cost-for-support) extended metric. ![Base cost for AWS support](@site/assets/png/aws-support-charge-base-cost.png) - Check the base cost for support charges that are grouped under specific accounts, using the [**doit/aws_support_group_id**](https://help.doit.com/docs/cloud-analytics/reports/report-dimensions-groupings-and-filters#by-doit) system label. ![Base cost for AWS support](@site/assets/png/aws-support-group-id.png) ## FAQ ### How to check whether my discount for support was applied? Go to **Reports** under **Analyze** and filter by `aws/item_desc`. If a discount has been applied, you'll see: `With discount of X%`. ### For accounts belong to PLES, how to check whether I'm charged with Business support rates? Business support rates for accounts belonging to Partner-Led enterprise support are only available for Partner-Led contracts. If your accounts are charged with Business rates, in **Reports** under **Analyze**, you'll see the `Charged as Business Support rate due to DoiT PLES program.` description for the `aws/item_desc` values. ### Why are there accounts with Basic Support in my reports? Accounts with Basic Support are included to provide complete visibility across all accounts. --- # DoiT and AWS invoice differences URL: https://help.doit.com/docs/billing/billing-explained/billing-differences If you buy AWS cloud through DoiT, the costs you see in AWS sometimes differ from those in the DoiT console. This is mainly due to the recalculation of Saving Plans into Flexsave, support costs and other billing items. The AWS invoice consists of three sections: a summary breakdown, detailed cost breakdown by service, and detailed cost breakdown by linked accounts. ## AWS invoices When DoiT is your cloud reseller, your AWS invoice represents what DoiT pays AWS on your behalf. The invoice includes fees that DoiT pays and discounts DoiT gets as a cloud reseller, and not all of them are passed onto you. - For a given calendar month, DoiT pays AWS invoices in the following month. That is, in May DoiT processes April's billing period invoices. In general, DoiT prepares payment lists and sends them to AWS for approval around the 17th of each month. AWS starts taking CC payments manually from the 17th up until the end of the month. Wire payments are usually made around the 20th of the month and marked as paid the following week. - If your AWS distributor is [Ingram Micro](https://www.ingrammicro.com/), be aware that Ingram Micro has specific payment arrangements with AWS. If an invoice appears as `Past due` in your AWS Management Console, rest assured that your account is not at risk of suspension. The invoice will be settled according to the payment terms between Ingram Micro and AWS. ### Account is at risk of suspension You can safely dismiss the `account is at risk of suspension` notification in your AWS account due to non-payment of invoices that are handled by DoiT. DoiT and AWS (including when your AWS distributor is Ingram Micro) have a payment schedule that differs from what you see in the AWS console. The invoice will be paid, and the account will not be suspended. However, you must take care of your AWS invoices for the period prior to you joining DoiT. If you're onboarded with DoiT, where we created a new management account for you and invited your existing accounts to the new AWS Organization, you are responsible for the invoices issued by AWS up until the date you consolidated with DoiT. :::seealso [Invoice posting dates](https://help.doit.com/docs/billing/invoices-and-payments#invoice-posting-dates) ::: ## General billing items In any given month, there are different factors that may result in cost discrepancies in AWS when compared directly with DoiT: - **Bundled discount**: Usage-based discount with a conditional logic associated with usage. This discount is passed onto your DoiT invoice. - **Credit**: Credits are automatically applied by AWS to cover your costs associated with eligible services. These credits are passed onto your Cloud Analytics. - **Distributor discount**: These discounts are given to your cloud distributor by AWS. Distributor discounts are similar to Solution Provider Program (SPP) discounts but apply only to customers on the ChannelOps Essentials plan. - **Private Pricing Agreement (PPA) discount**: It's a contractual agreement which offers cross-service discount in return for an annual or multi-year commitment. You're rewarded with higher discounts for additional contract years you commit to. PPA (formerly EDP) is mainly targeted to customers with a high annual usage spend. - **Fee**: Private Pricing Agreement on upfront charges and exchange charges. - **Out-of-Cycle Billing (OCB)**: Separate line items for one-time purchases, such as the Registrar fee, or APN fees billed upfront or following a private offer schedule. - **Private Rate Card discount or Private Pricing Agreement (PPA)**: An agreement which provides discounted prices for specific services. - **Recurring reservation fees**: Monthly fee for Reserved Instances that are purchased partially upfront or no upfront. - **Refund**: Refund applied to the invoice. - **Reservation applied usage**: Covered usage by Reserved Instances. It's always represented as 0, since AWS represents the covered cost as 0. - **Solution Provider Program (SPP) discounts**: These discounts are given to DoiT by AWS, as we're an authorized reseller of their services. - **Support fees**: If you have a paid support level, the costs may differ from AWS to DoiT. If you use [Flexsave](https://help.doit.com/docs/optimize/flexsave/aws), in AWS, these fees are calculated factoring in a Saving Plans 3-year discount rate, whereas in DoiT, they're based on a Saving Plans 1-year discount rate. - **Tax**: If applicable. Tax is not passed from AWS and is always recalculated in the DoiT console based on your billing profile. - **Usage**: On-Demand charges. ## Flexsave billing items :::note This section applies only if you have a [dedicated resold account](https://help.doit.com/docs/optimize/flexsave/aws#account-types) that benefits from Flexsave savings. ::: - **Flexsave adjustment**: Financial adjustment based on the difference in costs between one-year and three-year commitments. - **Flexsave charges**: The charge for the Flexsave service. - **Flexsave covered usage**: On-Demand costs covered by Flexsave. - **Flexsave negation**: Savings provided by Flexsave. ## Savings Plans billing items Savings Plans can differ between DoiT and AWS, which means the billing amount you see in AWS may differ from what you see in DoiT. ### AWS Savings Plans items - **Savings Plans (SP) covered usage**: On-Demand costs covered by DoiT Savings Plans. If you've purchased SPs directly from AWS, this is a combination of eligible On-Demand costs covered by both your own Saving Plans and DoiT Saving Plans. - **Savings Plans (SP) negation**: Savings provided by DoiT Savings Plans. If you've purchased SPs directly from AWS, this is a combination of eligible savings from both your own Saving Plans and DoiT Saving Plans. - **Savings Plans (SP) recurring fees**: Recurring charges related to DoiT Savings Plans. If you've purchased SPs directly from AWS, these fees are a combination of both DoiT and AWS SPs. DoiT Saving plans recurring fees are removed when we pull your monthly details through the Monthly Cost and Usage Report (CUR). - **Savings Plan (SP) upfront fee**: This is added to your bill when you purchase an All Upfront or Partial Upfront Savings Plan. ### DoiT Savings Plans items - **Savings Plans (SP) covered usage**: On-Demand costs covered by your own Savings Plans. - **Savings Plans (SP) negation**: Savings provided by your own Savings Plans. - **Savings Plans (SP) recurring fees**: Recurring charges related to your own Savings Plans. --- URL: https://help.doit.com/docs/billing/billing-explained/invoice-explainer # Invoice explainer When you purchase AWS services from DoiT, the invoice we send to you often differs from the invoice AWS sends to us on your behalf, due to differences in layout and pricing structure. The Invoice explainer lets you easily compare the monthly AWS billing of your usage and services with and without DoiT. ## Key features - **Invoice comparison**: The Invoice explainer allows you to: - Understand and compare your cost as billed by DoiT (**DoiT's invoice to you**) with what your AWS costs would have been without DoiT (**AWS cost without DoiT**). - Understand what AWS charges DoiT (**AWS' invoice to DoiT**) for your usage. - **Detailed breakdown**: The Invoice explainer provides a detailed breakdown of your costs for a given invoice. It helps you understand where your costs are coming from and how they are distributed across different resources. - **Charges by service**: See the cost for each service you've used in AWS and reasons for differences between the AWS and DoiT invoices if applicable. - **Charges by account**: See all the AWS service costs for each of your AWS accounts and reasons for differences between the AWS and DoiT invoices if applicable. ## Limitations - The Invoice explainer is available only on [dedicated payer accounts](https://help.doit.com/docs/amazon-web-services/import-aws-orgs#am-i-on-a-doit-consolidated-billing-account-or-a-dedicated-payer-account). - The Invoice explainer does not apply if your AWS invoice has manual adjustments after being issued. - The Invoice explainer does not provide separate items for AWS Marketplace purchases, even if you get [a separate invoice for them](https://help.doit.com/docs/billing/billing-profiles/changing-invoice-settings#marketplace). The marketplace charges are included in their corresponding line items, such as credits, usage, or fees. - If you use [invoice bucketing](https://help.doit.com/docs/billing/billing-profiles/changing-invoice-settings#invoice-bucketing) and Flexsave, Flexsave AWS charges are assigned to your [default bucket](https://help.doit.com/docs/billing/billing-profiles/changing-invoice-settings#set-as-default-bucket) for AWS. - The base currency of an invoice is US dollars (USD). If your billing currency is Japanese yen (JPY), line items in the generated invoices are rounded to the nearest 10 yen, while figures in the Invoice explainer are converted using the same [exchange rates](https://help.doit.com/docs/vendor-information/exchange-rates) but not rounded, which may result in small discrepancies. ## Launch the Invoice explainer The Invoice explainer focuses on key elements such as usage, Savings Plans, support costs, and discounts. To launch the Invoice explainer: 1. Sign in to the DoiT console, select **Billing** > **Invoices** from the top navigation mega menu. 1. Select an AWS invoice to open its details page, and then select **Understand your AWS billing** to launch the Invoice explainer. ![Launch Invoice explainer](@site/assets/png/invoice-explainer-button.png) The Invoice explainer has three sections: [Summary of your invoice](#summary-of-your-invoice), [Charges by service](#charges-by-service), and [Charges by account](#charges-by-account). When working with the Invoice explainer, you can expand each row for a detailed breakdown of individual line items, or hover over any item with a dotted underline to see more information. ### Summary of your invoice The summary page displays a three-column comparison table for a side-by-side view: - **AWS' invoice to DoiT**: The amount AWS charged DoiT for your usage. It contains all discounts DoiT applies to customers' AWS invoices. - **AWS cost without DoiT**: An estimate of what your AWS costs would have been without DoiT services. - **DoiT's invoice to you**: The amount DoiT charged you. ![Invoice explainer summary](@site/assets/png/invoice-explainer-summary.png) Below the comparison table, an effective savings summary shows the total amount and percentage you saved, based on the difference between the **AWS cost without DoiT** and the **DoiT's invoice to you**, both excluding tax. #### Support charges AWS bills support against the payer account, while DoiT attaches support charges to the account that has the highest cost eligible for support charges, or the linked account that has been specified to [store support billing](https://help.doit.com/docs/billing/billing-explained/aws-support#store-support-billing). ![Invoice explainer summary - Support charges](@site/assets/png/invoice-explainer-summary-support-charges.png) #### Export invoice summary You can export the invoice summary to a Google Sheets file and share it with others. Select the download icon on the summary page, and then select **Export to Google Sheets**. If this is your first time exporting the Invoice explainer to Google Sheets, you may be asked to grant DoiT permission to create Google Drive files. ### Charges by service To understand what services are causing a difference between your AWS and DoiT invoices, select **Charges by service**. ![Invoice explainer - charges per service](@site/assets/png/invoice-explainer-charges-per-service.png) The **Comparing services** page provides the following options: - **Filter**: Search for a specific service. For example, Amazon CloudFront, Elastic Load Balancing. - **Reasons for difference**: Check what services are affected by a specific reason such as Flexsave or Savings Plans. See [DoiT and AWS invoice differences](https://help.doit.com/docs/billing/billing-explained/billing-differences) for more information. - **Currency**: Convert the charges to a different currency. ### Charges by account To see in which accounts there's a difference between your AWS and DoiT invoice, select **Charges by account**. If your organization uses consolidated billing with multiple linked AWS payer accounts, you'll see a per-payer breakdown view. ![Invoice explainer - charges per account](@site/assets/png/invoice-explainer-charges-per-account.png) The **Comparing accounts** page provides the following options: - **Filter**: Search for a specific account by name or ID. - **Reasons for difference**: Check what accounts are affected by a specific reason such as Flexsave or Savings Plans. See [DoiT and AWS invoice differences](https://help.doit.com/docs/billing/billing-explained/billing-differences) for more information. - **Currency**: Convert the charges to a different currency. ## See also - [General billing items](https://help.doit.com/docs/billing/billing-explained/billing-differences#general-billing-items) - [Savings Plans billing items](https://help.doit.com/docs/billing/billing-explained/billing-differences#savings-plans-billing-items) - [Flexsave billing items](https://help.doit.com/docs/billing/billing-explained/billing-differences#flexsave-billing-items) --- URL: https://help.doit.com/docs/billing/billing-profiles/bacs-direct-debit # Bacs Direct Debit [Bacs Direct Debit](https://www.bacs.co.uk/services/bacs-schemes/direct-debit/) is commonly used for bank-to-bank transfers in the UK. DoiT supports Bacs Direct Debit and works with [Stripe](https://stripe.com/), our payment service provider, to process Bacs Direct Debit payments. :::note Required Permission - Billing Profile Admin ::: ## Set up Bacs Direct Debit payment If your [billing currency](https://help.doit.com/docs/billing/billing-profiles/changing-your-billing-currency) is GBP, you can set up Bacs Direct Debit payment when [creating or editing a billing profile](https://help.doit.com/docs/billing/billing-profiles/setting-up-a-new-billing-profile#create-a-new-billing-profile). To set up Bacs for an existing billing profile: 1. Sign in to the DoiT console, select **Billing** from the top navigation mega menu, and then select **Billing profiles**. 1. Select the billing profile name, or select the kebab menu (**⋮**) at the rightmost end of the billing profile entry and then select **Edit**. 1. Go to the **Payment method** section, select **Credit Card or Bank account** from the payment method drop-down. 1. Select **Add new payment method**, select **Bacs Direct Debit** and provide the information for a [mandate](https://stripe.com/docs/payments/payment-methods/bacs-debit#mandates) that gives us authorization to debit an account, including: - Email - Sort code - Bank account number - Full name (First and last name) - Country or region - Address ## Pay with Bacs Direct Debit We automatically initiate Bacs Direct Debits when your invoice is due. :::note Bacs Direct Debit is a delayed notification payment method. It takes 3 business days to confirm the success or failure of a payment when a mandate is already in place and 6 business days when a new mandate must be collected. During this period, the status of your [invoice](https://help.doit.com/docs/billing/invoices-and-payments) will remain `processing`. ::: --- URL: https://help.doit.com/docs/billing/billing-profiles/bill-com # Bill.com Bill.com provides automated, cloud-based software for financial operations and is a popular payment method. :::note Required Permission - Billing Profile Admin ::: ## Add DoiT as a vendor After [creating a billing profile](https://help.doit.com/docs/billing/billing-profiles/setting-up-a-new-billing-profile) with the payment method **Bill.com**, add the BILL account of DoiT as a connection: 1. Log in to your BILL account. 1. Select **Vendors** in the navigation menu. 1. Select the vendor name `DoiT International USA Inc`. 1. From the **More actions** list, select **Enter PNI** and paste the Payment Network ID (PNI) of DoiT International `0190518948494939`. :::seealso bill.com: [Connect by Payment Network ID](https://help.bill.com/hc/en-us/articles/360000024826-Connecting-by-Payment-Network-ID) ::: ## Pay directly from Bill.com With Bill.com, you need to initiate the payment: 1. Navigate to the [vendor page of DoiT International USA Inc](https://app01.us.bill.com/network/doitintl) in your web browser. 1. Sign in with your BILL account. 1. Select **Pay**. --- URL: https://help.doit.com/docs/billing/billing-profiles/canadian-pad # Canadian pre-authorized debits DoiT supports [Canadian pre-authorized debits (PAD)](https://www.canada.ca/en/financial-consumer-agency/services/banking/preauthorized-debit.html) and works with [Stripe](https://stripe.com/), our payment service provider, to process payments from customers with a Canadian bank account using the Automated Clearing Settlement System (ACSS). :::note Required Permission - Billing Profile Admin ::: ## Set up Canadian pre-authorized debits If you have a Canadian bank account, you can set up Canadian pre-authorized debits payment when [creating or editing a billing profile](https://help.doit.com/docs/billing/billing-profiles/setting-up-a-new-billing-profile#create-a-new-billing-profile). :::tip Canadian pre-authorized debits support both CAD and USD. Unless your account accepts USD debits, we recommend choosing CAD as your billing currency to avoid payment failures. ::: To set up Canadian pre-authorized debits for an existing billing profile: 1. Sign in to the DoiT console, select **Billing** from the top navigation mega menu, and then select **Billing profiles**. 1. Select the billing profile name, or select the kebab menu (**⋮**) at the rightmost end of the billing profile entry and then select **Edit**. 1. Go to the **Payment method** section, select **Credit Card or Bank account** from the payment method drop-down. 1. Select **Add new payment method**, select **Canadian pre-authorized debits** and provide the information for a [mandate](https://stripe.com/docs/payments/acss-debit#mandates) that gives us authorization to debit an account, including: - Email - Institution number - Transit number - Bank account number - Full name (First and last name) ## Pay with Canadian pre-authorized debits We automatically initiate Canadian pre-authorized debits when your invoice is due. :::note Canadian pre-authorized debits is a delayed notification payment method. It can take 3 calendar days to initiate a payment after collecting a mandate for the first time, and up to 5 business days after initiating a payment to confirm the success or failure of the payment. During this period, the status of your [invoice](https://help.doit.com/docs/billing/invoices-and-payments) will remain `processing`. ::: --- URL: https://help.doit.com/docs/billing/billing-profiles/changing-invoice-settings # Invoice settings and bucketing Invoice settings allow you to control how your cloud asset invoices are generated. You can also use the invoice bucketing feature to generate granular invoices for chargebacks. ## Required permission - Billing Profile Admin ## Invoice settings To check the invoice settings of a specific billing profile, select its name on the main **Billing profiles** screen, then go to the **Invoice settings** section. ![The Invoice settings section](@site/assets/png/doit-invoice-settings.png) There are two parts of invoice settings: [General](#general) and [Marketplace](#marketplace). ### General General settings provide two options: - **Separate invoice by asset type**: Generates one invoice per asset type. - **Invoice using custom bucketing**: Generates one invoice per custom bucket, also known as [invoice bucketing](#invoice-bucketing). You can always switch between the two options. Unless you explicitly delete a custom bucket, the platform retains the bucket configuration, including the asset assignments. ### Marketplace The **Marketplace** setting allows you to specify whether you want to receive dedicated invoices for AWS and Google Cloud Marketplace purchases. For each cloud provider, there are two options: - **Create individual invoices for each purchase**: Generates one invoice per item purchased via the provider's marketplace. - **Create a single invoice with line items for each purchase**: Generates one invoice that includes all the items purchased via the provider's Marketplace. ## Invoice bucketing Choosing **Invoice using custom bucketing** allows you to create subgroups of assets of the same type and generate granular invoices for chargeback. It's typically used in the following scenarios: - You have several cost centers in the same billing profile, and you want separate invoices for each cost center. (Cost centers are entities in your organization to which costs can be allocated. For example, products, environments, teams.) - You have many projects in the same billing profile, and you want separate invoices for different groups of projects. Instead of creating more billing profiles, you can assign assets to different custom buckets. You will then receive separate invoices for each bucket, billed to the same billing profile. ### Supported asset types Invoice bucketing is available to the following asset types: - **Amazon Web Services**: AWS accounts - **Google Workspace**: Google Workspace subscriptions - **Google Cloud (GCP)**: Google Cloud projects, Google Cloud billing accounts (_for costs charged at the Cloud Billing account level, such as support costs_) - **Microsoft Azure**: Microsoft Azure subscriptions - **Office 365**: Microsoft 365 subscriptions If you choose to use custom bucketing, the console will display a list of asset types without default buckets. You must set a default bucket for each of them. Note that an invoice bucket is a grouping of assets of the same type. It's not allowed to mix asset types in the same bucket (Google Cloud projects and Google Cloud billing accounts are of the same asset type and can be placed in one bucket). ![The options for custom bucketing.](@site/assets/png/doit-invoice-custom-bucketing.png) ### Create an invoice bucket To create an invoice bucket: 1. Select **Create new invoice bucket**. 1. Configure the new bucket. ![Create new invoice bucket](@site/assets/png/doit-invoice-new-bucket.png) 1. Enter a bucket name. You can change the bucket name afterward. 1. Select the asset type of the bucket. 1. (Optional) Select the **Set as default bucket for this asset type** checkbox if needed. 1. Select **Create bucket** to finish. If successful, the new bucket will appear on the bucket list. ### Set as default bucket With custom bucketing, it's mandatory to set a default bucket per [supported asset type](#supported-asset-types). You can set a bucket as the default when creating it or afterward. To set an existing bucket as the default: 1. Locate the target bucket on the bucket list. 1. Select the star icon () that precedes **Set as default bucket for `ASSET_TYPE`**. ![Set as default](@site/assets/png/doit-invoice-bucketing-set-default.png) To switch to a different bucket, simply set the new bucket as the default. It will automatically take over the default role. ### Assign assets When using custom bucketing for granular invoices, you should manually assign assets to the relevant buckets (unassigned assets will appear in the default bucket for their type on the invoice). To manually assign an asset: 1. Locate the target bucket on the bucket list. 1. Select the asset from the drop-down list to assign to the bucket. 1. Save the changes. ### Delete an invoice bucket To delete a bucket: 1. Locate the target bucket from the bucket list. 1. Hover over the bucket box to reveal the bin icon and then select the icon. ![Delete a bucket](@site/assets/png/doit-invoice-bucketing-delete.png) 1. Confirm the deletion. - If you're deleting a default bucket, you'll be asked to choose a new default before proceeding. - Assets assigned to the bucket will become unassigned once the bucket is deleted. ### Auto-assign new Google Cloud projects Under **Custom bucketing settings**, the _Auto-assign any newly created Google Cloud project to the bucket that holds its linked billing account_ checkbox is selected by default. ![Auto-assign new Google Cloud projects](@site/assets/png/doit-invoice-custom-bucketing-gcp.png) The **Auto-assign** option applies to projects created _after_ you enable invoice bucketing. For existing projects, you have to manually assign them to your target bucket. ## Example invoices ### Invoice of a custom bucket If you've set up invoice bucketing, you'll receive one invoice per custom bucket. Below is an example invoice issued on a custom bucket named `Invoice Bucket 1`. ![An example invoice of a custom bucket.](@site/assets/png/doit-invoice-bucketing-example.png) - The first line item is always **Invoice Bucket** / _`bucket_name`_. It is associated with the SKU `INFOSKU` and has a quantity (Units) 0, which means you do not pay for the bucket itself. - The following line items correspond to the member assets in the bucket. ### Marketplace purchases If you've chosen to separate Marketplace purchases in the [invoice settings](#invoice-settings), you'll receive dedicated invoices for marketplace spending. #### Single invoice with line items for each purchase In the example below, the billing profile has been set to _create a single invoice_ with line items for each AWS Marketplace purchase. Therefore, one invoice is issued with multiple line items. ![An invoice of AWS Marketplace purchases](@site/assets/png/doit-invoice-marketplace-single.png) #### Individual invoices for each purchase In this example, the billing profile has been set to _create individual invoices_ for each Google Cloud Marketplace purchase. Therefore, the Datadog and Elastic Services invoices are issued separately. ![An invoice of a GCP Marketplace purchase](@site/assets/png/doit-invoice-mkp-gcp-datadog.png) ![An invoice of another GCP Marketplace purchase](@site/assets/png/doit-invoice-mkp-gcp-elastic.png) ### Flexsave savings in buckets If [Flexsave](https://help.doit.com/docs/optimize/flexsave) has been activated on your account, starting with March 2023 invoices, you'll see relevant **Flexsave** line items on bucket invoices. Below is an example invoice with Flexsave AWS savings. ![An example invoice with Flexsave AWS savings](@site/assets/png/doit-invoice-bucketing-FS-AWS.png) See [Flexsave invoicing](https://help.doit.com/docs/optimize/flexsave/aws/flexsave-aws-invoicing) for more information. ## See also - [View invoices details](https://help.doit.com/docs/billing/invoices-and-payments/managing-invoices) - [Understand your invoice with reports](https://help.doit.com/docs/billing/invoices-and-payments/invoice-breakdown-reports) --- URL: https://help.doit.com/docs/billing/billing-profiles/changing-your-billing-currency # Change billing currency ## Change billing currency To change your company's billing currency, you must set up a new billing profile in the DoiT console. You can't change the currency of existing billing profiles. :::caution To avoid billing issues, we recommend that you open an expert inquiry to get the help of our Finance team. DoiT Rep. needs to deactivate the old billing profile, open a new one with the requested currency, and reassign contracts, assets (including projects) and credits to the new billing profile. ::: 1. Follow the instructions to [create a new billing profile](https://help.doit.com/docs/billing/billing-profiles/setting-up-a-new-billing-profile). 2. In the **Payments** section, choose the new billing currency. ## Supported currencies - $ USD (United States Dollar) - ₪ ILS (Israeli Shekels) - € EUR (The Euro) - £ GBP (Pound sterling) - A$ AUD (Australian Dollar) - C$ CAD (Canadian dollar) - kr DKK (Danish krone) - kr NOK (Norwegian krone) - kr SEK (Swedish krona) - R$ BRL (Brazilian real) - S$ SGD (Singapore dollar) - MX$ MXN (Mexican peso) - Fr. CHF (Swiss franc) - RM MYR (Malaysian ringgit) - NT$ TWD (New Taiwan dollar) - E£ EGP (Egyptian pound): If you choose EGP as the billing currency, you can pay only with a credit card. The processing fee is 4.9%. - R ZAR (South African Rand) - ¥ JPY (Japanese yen): If your billing currency is JPY, line items in the generated invoices are rounded to the nearest 10 yen. - Rp IDR (Indonesian Rupiah) - ฿ THB (Thai Baht) - COL$ COP (Colombian Peso) :::seealso [Exchange rates](https://help.doit.com/docs/vendor-information/exchange-rates) ::: ## Currencies for Google Cloud Billing accounts Changing currencies in the DoiT console doesn't affect the currency of your Cloud Billing account in Google Cloud billing console. DoiT's Google Cloud sub-billing accounts are charged in USD, which means Google Cloud Billing console will show reports in USD. It is not possible to change the currency of Google Cloud sub-billing accounts. :::seealso Google Cloud Docs: [Supported currencies and payment methods](https://cloud.google.com/billing/docs/resources/currency#about-currencies) ::: --- URL: https://help.doit.com/docs/billing/billing-profiles # Billing profiles Billing profiles maintain billing information for products and services you purchase from DoiT, including: - billing address - invoices contact - payment method - [billing currency](https://help.doit.com/docs/billing/changing-your-billing-currency) - [invoice settings](https://help.doit.com/docs/billing/changing-invoice-settings) If your organization has entities with different invoice requirements such as different payment methods or currencies, you'll need to set up multiple billing profiles. ## Access billing profiles To access billing profiles, sign in to the DoiT console, select **Billing** from the top navigation mega menu, and then select **Billing profiles**. ![The Billing profiles screen.](@site/assets/png/doit-billing-profile.png) You can select the name of a billing profile to view its configuration. --- URL: https://help.doit.com/docs/billing/billing-profiles/prepayments # Pay in advance If you'd like to pay in advance, contact our support team to set up account credit and prepayment process. :::note Please communicate with us via our [expert inquiry system](https://help.doit.com/docs/consulting-support/create-support-request) (e.g., when sending a PO) so that our whole team is available to assist you and keep track of the conversation. Our support team will route your inquiries to our finance team when necessary. ::: ## Prepayment process Different organizations may use different accounting methods. We tailor the prepayment process to suit your needs. Here's an example of a typical prepayments process: 1. You send a _Purchase Order_ (PO) for the amount you want to prepay. After receiving your first PO, we may need to request changes for accounting purposes. We will discuss with you while setting you up. 1. We send you an invoice for the PO. 1. You pay the invoice using your [preferred payment method](https://help.doit.com/docs/billing/billing-profiles/setting-up-a-new-billing-profile#choose-your-payment-method), then contact us to confirm the payment. 1. We confirm payment receipt and credit the funds to your account. --- URL: https://help.doit.com/docs/billing/billing-profiles/sepa-direct-debit # SEPA Direct Debit The [Single Euro Payments Area (SEPA)](https://www.europeanpaymentscouncil.eu/about-sepa/sepa-timeline) is a European Union initiative to harmonize euro payments. It allows direct debiting of every EUR-denominated bank account within the SEPA region. DoiT supports SEPA Direct Debit and works with [Stripe](https://stripe.com/), our payment service provider, to process SEPA Direct Debit payments. :::note Required Permission - Billing Profile Admin ::: ## Set up SEPA Direct Debit payment If your [billing currency](https://help.doit.com/docs/billing/billing-profiles/changing-your-billing-currency) is EUR, you can set up SEPA Direct Debit payment when [creating or editing a billing profile](https://help.doit.com/docs/billing/billing-profiles/setting-up-a-new-billing-profile#create-a-new-billing-profile). To set up SEPA for an existing billing profile: 1. Sign in to the DoiT console, select **Billing** from the top navigation mega menu, and then select **Billing profiles**. 1. Select the billing profile name, or select the kebab menu (**⋮**) at the rightmost end of the billing profile entry and choose **Edit**. 1. Select the section of **Payments**, choose **Credit Card or Bank account** from the payment method drop-down. 1. Select **Add new payment method**, select **SEPA Debit** and provide the required payment information. ![Select SEPA Debit as the payment method.](@site/assets/png/doit-sepa-payment.png) In addition, you must read and accept the [SEPA Direct Debit mandate](https://www.europeanpaymentscouncil.eu/what-we-do/sepa-schemes/sepa-direct-debit/sdd-mandate). ## Pay with SEPA Direct Debit We automatically initiate SEPA Direct debits when your invoice is due. In addition, once you set up SEPA Direct Debit payment in your billing profile, you can use it to pay an outstanding or overdue invoice anytime. See [Pay now](https://help.doit.com/docs/billing/invoices-and-payments/pay-now) for more information. :::note SEPA Direct Debit is a delayed notification payment method. A payment typically takes 5 business days to process. During the period, the status of your [invoice](https://help.doit.com/docs/billing/invoices-and-payments) will remain `processing`. ::: ## Limitations - With DoiT, SEPA direct debit transactions have a limit of 1,000,000 EUR each. :::seealso Stripe Docs: [SEPA Direct Debit payments](https://stripe.com/docs/payments/sepa-debit), [Accept a SEPA Direct Debit payment](https://stripe.com/docs/payments/sepa-debit/accept-a-payment) ::: --- URL: https://help.doit.com/docs/billing/billing-profiles/setting-up-a-new-billing-profile # Create and edit billing profiles ## Required permission - Billing Profile Admin ## Create a new billing profile To create a billing profile: 1. Sign in to the DoiT console, select **Billing** from the top navigation mega menu, and then select **Billing profiles**. 1. Select **Create new billing profile** in the upper-right corner. (If there are no existing billing profiles, you'll see a **Create billing profile** option.) ![The Billing profiles screen.](@site/assets/png/doit-billing-profile.png) 1. Provide the necessary information on the **Create new billing profile** page. - **Billing address**: The billing address of your organization. - **Company details**: Your company name and registration details. The company name is also used as the billing profile name. - **Contact details**: The accounts payable contact information for your billing profile. - **Payment method**: Your billing currency. 1. Select **Create billing profile** once you've entered the required information and proceed to choosing a payment method. ## Choose your payment method We support the following payment methods (the options present to you in the console depend on your billing currency and country): - **Wire transfer** (IBAN/SWIFT) - **Bill.com**: See [Bill.com](https://help.doit.com/docs/billing/billing-profiles/bill-com) for how to set it up. - **Credit card or Bank account**: - **Card** (2.9% processing fee or 4.9% for Egyptian Pound): See [Credit card fees](https://help.doit.com/docs/billing/invoices-and-payments/credit-card-fees) for more information. - **ACH Debit**: Available if you're billed in USD and you have a US bank account. See [ACH Debit](https://help.doit.com/docs/billing/billing-profiles/setting-up-ach-payments) for how to set it up. - **Bacs Direct Debit**: Available if you're billed in GBP and you have a UK bank account. See [Bacs Direct Debit](https://help.doit.com/docs/billing/billing-profiles/bacs-direct-debit) for how to set it up. - **Canadian pre-authorized debits**: Available if you have a Candian bank account. See [Canadian pre-authorized debits](https://help.doit.com/docs/billing/billing-profiles/canadian-pad) for how to set it up. - **SEPA Direct Debit**: Available if your billing currency is EUR. See [SEPA Direct Debit](https://help.doit.com/docs/billing/billing-profiles/sepa-direct-debit) for how to set it up. Confirm the chosen payment method to complete the billing profile creation. After you create a new billing profile, we will send a confirmation email to your accounts payable contact. Then, at the beginning of every month, we send an invoice to your accounts payable contact for the previous month. ### Automatic payments For billing profiles with payment methods of **Credit card or Bank account**, we automatically process payments when the invoices are due. In some countries, you can set up a credit card, debit card, or bank account as your primary payment method. You can also add a backup credit or debit card, which is stored for your convenience but is not charged automatically. When invoices are due, DoiT automatically charges the primary payment method. If your primary payment method fails, you must manually pay the invoices, for example, by using your backup card. ## Edit a billing profile To edit a billing profile: 1. select **Billing** from the top navigation mega menu, and then select **Billing profiles**. 1. Locate the billing profile of interest, select its name, or select **Edit** from the kebab menu (**⋮**) at the rightmost end of the billing profile entry. You can update the following information: - **Billing and company details**: Except _Country_, you can modify all the information provided when creating the billing profile. - **Contact details** - **Payments**: You can change your payment method when editing a billing profile. To [change billing currency](https://help.doit.com/docs/billing/billing-profiles/changing-your-billing-currency), you must create a new billing profile. - **Invoices setting**: To specify how your invoices are issued. See [Invoice settings and bucketing](https://help.doit.com/docs/billing/billing-profiles/changing-invoice-settings) for details. 1. Save your changes. ## See also - [General vendor information](https://help.doit.com/docs/vendor-information/general-vendor-information) - [Invoice posting dates](https://help.doit.com/docs/billing/invoices-and-payments#invoice-posting-dates) --- URL: https://help.doit.com/docs/billing/billing-profiles/setting-up-ach-payments # ACH Debit If you're billed in USD and you have a US bank account, you can pay your invoices by using ACH (Automated Clearing House) via the platform. :::note Required Permissions: **Billing Profile Admin**, **Invoice Viewer** ::: ## Set up ACH payment You can set up an ACH Payment when [creating or editing a billing file](https://help.doit.com/docs/billing/billing-profiles/setting-up-a-new-billing-profile). To set up ACH for an existing billing profile: 1. Sign in to the DoiT console, select **Billing** from the top navigation mega menu, and then select **Billing profiles**. 1. Select the billing profile name, or select the kebab menu (**⋮**) at the rightmost end of the billing profile entry and choose **Edit**. 1. Select the section of **Payments**, choose **Credit Card or Bank account** from the payment method drop-down. 1. Select **Add new payment method**, and then select **US bank account**. ![Select ACH Debit as the payment method.](@site/assets/png/doit-ach-payment.png) 1. Select a bank or enter the bank details manually. We work with [Stripe](https://stripe.com) to perform secure ACH payments authorizations. ![Connect via Stripe.](@site/assets/png/doit-stripe-connect.png) 1. Select **Agree** to continue. 1. Log in to your bank and select a _Checking_ or _Saving_ account to link. If successful, your bank account is linked and saved for future ACH Payments. ## Pay with ACH We automatically initiate ACH debits when your invoice is due. The saved ACH method is also available if you want to [pay in advance](https://help.doit.com/docs/billing/billing-profiles/prepayments). :::note ACH payments take 4–7 days to process. During the period, the status of your [invoice](https://help.doit.com/docs/billing/invoices-and-payments) will remain `processing`. ::: --- URL: https://help.doit.com/docs/billing/contracts/access-contracts # Access contracts In the console, you can view details of your company contracts or download contract documents in PDF. ## Required permission - Contracts Viewer ## Access contracts To access your contracts with DoiT, sign in to the DoiT console, select **Billing** from the top navigation mega menu, and then select **Contracts**. ![Contracts screen](@site/assets/png/console-contracts-screen.png) ## View a contract To view the details of a contract: 1. Navigate to the main **Contracts** screen, locate the contract of interest. 1. Select the kebab menu (**⋮**) at the rightmost end of the contract entry, and then select **View contract**. Below is an example Cloud Intelligence Enhanced plan contract, purchased [via AWS Marketplace](https://help.doit.com/docs/connect-cloud/marketplace/subscribe-via-aws-marketplace). Note that the contract items vary based on the products and services you purchase. ![Example contract](@site/assets/png/console-contract-dci-example.png) ## Download signed contract To download the signed contract in PDF, select **Download signed contract** in the kebab menu (**⋮**) at the rightmost end of the contract entry. --- URL: https://help.doit.com/docs/billing/contracts/commitment-contracts # Commitment Contracts You have the option to enroll in an _Enterprise Agreement_ with DoiT International and tailor your agreement (also known as a _Commitment Contract_) to best suit your needs. :::note For more information about Enterprise Agreements, please get in touch with your sales representative. ::: --- URL: https://help.doit.com/docs/billing/contracts # Contracts --- URL: https://help.doit.com/docs/billing/dci-billing # Cloud Intelligence billing This page explains the scope of Cloud Intelligence charges and invoices. ## DCI charges scope The Cloud Intelligence (DCI) Enhanced and Enterprise tiers charge the greater of a fixed **Minimum service fee** and a **Monthly cloud spend percentage**, as specified in your DCI [contract](https://help.doit.com/docs/billing/contracts/access-contracts#view-a-contract). The scope of monthly cloud spend is defined below: - It's your net spend after discounts. - It includes charges for Flexsave and Partner-Led Support (PLS). - It includes the total spend of all [connected clouds](https://help.doit.com/docs/connect-cloud) (AWS, Azure, Google Cloud), regardless of whether you purchase them directly through DoiT. - It excludes the following: - Credits, marketplace subscriptions, and taxes. - Platform licensing, subscriptions, and consulting: [Looker](https://help.doit.com/docs/integrations/looker), [Google Workspace](https://help.doit.com/docs/integrations/google-workspace/purchase-licenses), [Microsoft 365](https://help.doit.com/docs/integrations/microsoft-365), Apigee (all tiers), and Google Cloud Consulting. - Google Security Operations (SecOps): Google SecOps SIEM (Chronicle). - Google Cloud Invoice. ## Split DCI costs When you purchase a DCI Enhanced or Enterprise plan directly from DoiT, your invoices are issued as follows by default: - All DCI costs are charged in a single primary DCI invoice, under the billing profile to which the contract is assigned. - Expenditures for AWS, Azure, and Google Cloud assets purchased from DoiT (via a reseller agreement) are charged in separate invoices, each under the billing profile to which the assets are assigned. If you prefer to allocate DCI costs across billing profiles, select **Split DCI costs across all billing profiles proportionally to their cloud spend** in the DCI contract. In this case, your cloud asset invoices are issued as before, while your DCI invoices are issued in a more granular manner: - DCI costs related to AWS, Azure, and Google Cloud assets purchased from DoiT are split into multiple DCI invoices, one per billing profile and proportional to the cloud spend in each profile. - DCI costs related to other charges, such as expenditures for cloud assets not purchased from DoiT, remain on the primary DCI invoice. If there are no such costs, no primary DCI invoice is issued. Note that the **Split DCI costs** option is not available if you purchase a DCI plan via the marketplace. Below is an example Cloud Intelligence Enhanced plan contract, purchased directly from DoiT. ![Example contract with split DCI costs](@site/assets/png/console-contract-dci-split-costs.png) ## DCI billing via marketplace If you purchase a DCI Enhanced or Enterprise plan via a marketplace, for example, [via AWS Marketplace](https://help.doit.com/docs/connect-cloud/marketplace/subscribe-via-aws-marketplace), the total cloud spend used to calculate [DCI charges](#dci-charges) is based on the previous billing period. If, in a given month, the **Monthly cloud spend percentage** exceeds the fixed **Minimum service fee**, the additional cost is not charged in the same billing period but in the next one. Below is an example that demonstrates the steps you can take to understand DCI charges. :::note This example is provided for reference purposes. Except for the conditions explicitly stated, it does not take into account any other agreements you may have or any special scenarios that may apply. ::: Suppose you have an active DCI contract with a minimum service fee of US$`3500` and a monthly cloud spend percentage of `3`%. 1. Create a report to get the monthly spend of the three cloud providers: AWS, Azure, and Google Cloud, excluding credits and marketplace spend (filter by `Cost Type not equals Credit` and `Marketplace not equals true`). ![Total cloud spend](@site/assets/png/console-invoice-dci-extra-calc.png) 1. Take the spend in April as an example: the 3% cloud spend is `181,314.72` × `0.03` = `5439.44`, which exceeds the minimum fee of `3500` by `1939.44`. 1. Create another report for a full view over your DCI marketplace spend, grouping data by **Service** (`Service equals Cloud Intelligence`) and **aws/item_desc**. ![DCI marketplace extra charges](@site/assets/png/console-invoice-dci-aws-mkp.png) The `AWS Marketplace software usage|us-east-1|Usage above contractual agreement` item in May is the rounded value of the extra cost in April. --- URL: https://help.doit.com/docs/billing/google-cloud-billing-report # Google Cloud Billing report When comparing the total cost in your monthly invoice with that in the Google [Cloud Billing report](https://cloud.google.com/billing/docs/reports), you are likely to see discrepancies due to the fact that DoiT recalculates the Google billing data to apply DoiT discounts, custom pricing, and other relevant items. To build a Cloud Analytics report that strips out DoiT recalculation and closely matches the Cloud Billing report, you need to make adjustments on both sided. :::note Starting January 1, 2026, DoiT auto-forwards promotional credits from Google Cloud to eligible customers by default. See [Promotional credits](https://help.doit.com/docs/cloud-analytics/reports/editing-your-cloud-report#promotional-credits). ::: :::note Starting with the March 2026 invoices (issued in April), DoiT transitions Google Cloud billing from a `usage_start_time` basis to an `invoice.month` basis. This change ensures that DoiT invoices fully align with Google’s invoicing cycle and data. See [example reports of invoice month](https://help.doit.com/docs/cloud-analytics/tutorials/example-reports#google-cloud-invoice-month) for how to verify your billing during this transition. ::: ## Part 1: Adjust Google Cloud Billing report 1. Set the [Time range](https://cloud.google.com/billing/docs/how-to/reports#time-range) for the report data. - For invoices issued before March 2026, select the **Usage date** time range type. - For invoices issued from March 2026 onward, select the **Invoice month** time range type. 1. Clear the checkbox of **Promotions and others**. These are promotional credits from Google Cloud. Their application depends on your contract with DoiT. 1. Filter out the Looker service if applicable. DoiT issues Looker invoices separately from other Google Cloud services. 1. Filter out DoiT marketplace products if applicable. ## Part 2: Adjust Cloud Analytics report 1. Filter [Billing account](https://help.doit.com/docs/cloud-analytics/reports/report-dimensions-groupings-and-filters#hierarchy-groups) to include only the one for which you're viewing the Cloud Billing report. 1. Select the preset custom metric [GCP Cost w/o Discounts](https://help.doit.com/docs/operate/metrics/predefined-metrics#gcp-cost-wo-discounts). 1. For invoices issued from March 2026 onward, in the **Group by** section, select **Invoice month**. Be aware that discounts applied to individual SKUs depend on your contract with DoiT. It's possible that within the same project, some SKUs have higher discounts than others. ## See also - [Billing data export](https://help.doit.com/docs/google-cloud/gcp-billing-export) - [View invoices details](https://help.doit.com/docs/billing/invoices-and-payments/managing-invoices) - [Example reports of invoice month](https://help.doit.com/docs/cloud-analytics/tutorials/example-reports#google-cloud-invoice-month) --- URL: https://help.doit.com/docs/billing/invoices-and-payments/access-invoices # Access invoices ## Required permission - Invoice Viewer ## Access invoices To access your invoices in the DoiT console, select **Billing** > **Invoices** from the top navigation mega menu. ![The main Invoices page.](@site/assets/png/console-invoices-screen.png) You can filter the invoices by billing profile, invoice period, invoice status, and service. To [view the details](https://help.doit.com/docs/billing/invoices-and-payments/managing-invoices) of a specific invoice, select its invoice number to open the invoice details page. By default, invoices of the last three months that are not [proforma](#proforma-invoices) or cancelled are displayed. ## Invoice status Each invoice displays a color-coded status chip. An invoice can be in one of the following statuses: - **Open** - **Paid** - **Partially Paid** - **Past Due** - **Processing** - **Proforma**: [Proforma invoices](#proforma-invoices) are provided for informational purposes only. You don't need to pay them. - **Canceled** :::seealso - [Automatic payments](https://help.doit.com/docs/billing/billing-profiles/setting-up-a-new-billing-profile#automatic-payments) ::: ## Proforma invoices A proforma invoice is a preliminary bill based on the available data up to the current day of the month. It helps you verify your billing information and contact us for corrections before the final invoice is issued. - Proforma invoices are updated daily until the final invoices are issued. You cannot download proforma invoices. - You can identify proforma invoices in the invoice list by the `PF` prefix in the invoice ID. - When calculating billing charges for proforma invoices, we use the exchange rate of the day you check the invoice, which may differ in the final invoice. ## See also - [Download PDF invoice](https://help.doit.com/docs/billing/invoices-and-payments/pdf-invoices) - [Download CSV](https://help.doit.com/docs/billing/invoices-and-payments/invoice-reconciliation-file) --- URL: https://help.doit.com/docs/billing/invoices-and-payments/credit-card-fees # Credit card fees :::info Starting April 1, 2023, we apply a 2.9% payment processing fee to invoices paid with _credit cards_ and _debit cards_ in jurisdictions (decided by the billing address in your [billing profile](https://help.doit.com/docs/billing/billing-profiles)) where charging processing fees complies with applicable laws. In rare circumstances, the processing fee may vary. Currently, the credit card processing fee for invoices paid in Egyptian Pound (EGP) is 4.9%. ::: ## Fees calculation The credit card processing fee is calculated as below: ``` fee = (invoice_total / (1 - processing_fee_percentage)) - invoice_total ``` - The `invoice_total` is the total amount after taxes (Total W/ Tax). - The fee itself is subject to taxes. See the following section for an example. ## Fees invoices The credit card fee is applied and collected at the time of payment. You are charged for the sum of invoice and fee, both with taxes if applicable. For a successful payment, you'll find a fee invoice in a column called **Linked invoices** on the main **Invoices** page. ![Linked fees invoices on the main Invoices page.](@site/assets/png/doit-invoice-credit-card-link.png) In the example invoice above: - Your original invoice total amount with tax is €`11.90`. - Your final invoice total amount with credit card fees is €`12.33`. To view the details of the credit card fee, select the linked invoice. ![Credit card processing fees invoice details.](@site/assets/png/doit-invoice-credit-card-fee.png) The example fee invoice shows that: - Your credit card fee (SKU `PMCCFEE`): `11.90/(1 - 0.029) - 11.90 = 0.36` - Your credit card fee with tax: `0.36 + 0.07 = 0.43` Therefore, your final invoice total amount with credit card fees is `11.90 + 0.43 = 12.33`. --- URL: https://help.doit.com/docs/billing/invoices-and-payments # Invoices Invoices are issued monthly based on your [contracts](https://help.doit.com/docs/billing/contracts) with DoiT and your [billing profiles](https://help.doit.com/docs/billing/billing-profiles). ## Key features - [**Invoice bucketing**](https://help.doit.com/docs/billing/billing-profiles/changing-invoice-settings#invoice-bucketing): Organize and separate cloud costs into custom groups (buckets). Invoice bucketing allows you to receive separate invoices for different cost centers or entities without creating multiple billing profiles, aligning invoices with your internal structure. - [**Separate Marketplace purchases**](https://help.doit.com/docs/billing/billing-profiles/changing-invoice-settings#marketplace): Receive separate invoices for AWS and Google Cloud Marketplace purchases to compare marketplace services versus core cloud usage easily. - [**Split DCI costs**](https://help.doit.com/docs/billing/dci-billing#split-dci-costs): Split DCI costs related to AWS, Azure, and Google Cloud assets purchased from DoiT across billing profiles proportionally to their spend. - [**Tag assets**](https://help.doit.com/docs/integrations/asset-management/tag-assets): Show custom tags in the invoices. For example, you can tag an asset with the Purchase Order (PO) number or other information critical to your operation. - [**Store AWS support billing**](https://help.doit.com/docs/billing/billing-explained/aws-support#billing-account-and-billing-date): Allocate AWS support charges to an account of your choice to better represent the account's total spending, enable more accurate budgeting and simplify reporting. - [**Proforma invoices**](https://help.doit.com/docs/billing/invoices-and-payments/access-invoices#proforma-invoices): Review and confirm billing and transaction details before the final invoice is issued. - **Invoice breakdown**: [Understand your invoices using reports](https://help.doit.com/docs/billing/invoices-and-payments/invoice-breakdown-reports), or launch the [AWS Invoice Explainer](https://help.doit.com/docs/billing/billing-explained/invoice-explainer) to compare your costs and the charges we receive from AWS. - **Invoice line items**: Show up to 250 individual [projects/accounts in a single invoice](https://help.doit.com/docs/billing/invoices-and-payments/managing-invoices#projects-and-accounts-in-invoices). - **Download**: Download [invoice reconciliation files](https://help.doit.com/docs/billing/invoices-and-payments/invoice-reconciliation-file) in CSV, or download [invoices in PDF](https://help.doit.com/docs/billing/invoices-and-payments/pdf-invoices). ## Invoice posting dates Monthly invoices contain all the costs incurred during a billing period. Due to the billing data latency in clouds and cloud products, invoices are posted with a delay. Below are the invoice posting dates for a given calendar month. ### DoiT products and services - **Cloud Intelligence** - **Enhanced CloudOps**, **Enterprise CloudOps**: For direct purchases (not via a marketplace), invoices are issued on the 10th of the following month, or the next business day if it falls on a weekend. - **Essentials CloudOps**, **Essentials+ CloudOps**: The Essentials plan doesn't issue invoices per se. You only receive invoices for your [cloud assets](#cloud-assets) based on their respective posting dates. - **Single Purchase**: On the first day of the following month, or the next business day if it falls on a weekend. This applies if you are on the Cloud Intelligence Essentials tier and purchased the one-time service for individual inquiries during the billing period. - **DoiT Cloud Advantage**: The Advantage plan doesn't issue invoices per se. You only receive invoices for your [cloud assets](#cloud-assets) based on their respective posting dates. - **DoiT Cloud Navigator**: On the first day of the following month, or the next business day if it falls on a weekend. - **DoiT Cloud Solve**: On the 10th of the following month, or the next business day if it falls on a weekend. - **DoiT One-Time Service**: On the first day of the following month, or the next business day if it falls on a weekend. This applies if you purchased [DoiT accelerators professional service](https://help.doit.com/docs/services/proserv) during the billing period. ### Cloud assets - **Amazon Web Services**: AWS accounts. - [Dedicated payer account](https://help.doit.com/docs/amazon-web-services/import-aws-orgs#am-i-on-a-doit-consolidated-billing-account-or-a-dedicated-payer-account): Within the first three business days after the 3rd of the following month, or on the 10th (or the next business day if it falls on a weekend) if there is a delay in billing data or manual adjustments are required. - [Consolidated billing account](https://help.doit.com/docs/amazon-web-services/import-aws-orgs#am-i-on-a-doit-consolidated-billing-account-or-a-dedicated-payer-account): On the first business day after the 10th of the following month - **Google Cloud**: Google Cloud billing accounts and Google Cloud projects. On the first business day after the 5th of the following month (see also [Google Docs: Billing](https://cloud.google.com/billing/docs/how-to/billing-cycle#overview)). - **Looker**: Google Cloud [Looker subscriptions](https://help.doit.com/docs/integrations/looker). Within the first two business days of the following month. - **Google Workspace**: [Google Workspace subscriptions](https://help.doit.com/docs/integrations/google-workspace/google-workspace-invoice). Within the first two business days of the following month. - **Microsoft Azure**: Microsoft Azure subscriptions. On the first business day after the 5th of the following month. - **Office 365**: [Microsoft 365 subscriptions](https://help.doit.com/docs/integrations/microsoft-365). Within the first two business days of the following month. --- URL: https://help.doit.com/docs/billing/invoices-and-payments/invoice-breakdown-reports # Understand invoices with reports To get a detailed view of your costs for a specific invoice or during a selected period, you often need to run a Cloud Analytics report. ## Allocation: Invoices The **Invoices** allocation is used to analyze invoices issued to the following asset types, each invoice corresponds to an individual allocation rule: - Amazon Web Services, Google Cloud: For costs incurred by _AWS accounts_, _Google Cloud billing accounts_ and _Google Cloud projects_ - If you're using [custom bucketing](https://help.doit.com/docs/billing/billing-profiles/changing-invoice-settings), allocations follow the naming convention `[{billing_profile_id}] {billing_profile_name} - {bucket_name}`. - Otherwise, allocation rules follow the naming convention `[{billing_profile_id}] {billing_profile_name} - {asset_type}`. - Looker: Looker invoices appear in the entry named `Looker`. For other asset types, only Microsoft Azure billing data is available in Cloud Analytics; it will stay in the `Unallocated`. ### Example The example report below uses the **Invoices** allocations for invoices issued to a fictitious company: ![Invoices allocation](@site/assets/png/console-report-invoice-buckets-bp.png) - The company has a Billing profile _US123123 – Example.com_ with custom buckets. - The company has three custom buckets with the supported asset types. You can add more dimensions to further break down the invoice. Below is an example of the invoice issued to assets in the bucket `Dev`. ![Invoices allocation - one bucket](@site/assets/png/console-report-invoice-buckets.png) The example below combines all three [group allocations for Billing and invoicing](https://help.doit.com/docs/operate/allocations/preset-allocations#billing-and-invoicing-group) for a breakdown of cost categories and savings. ![Invoices group allocations](@site/assets/png/console-report-invoice-breakdown.png) ## Limitations - If your billing currency is Japanese yen (JPY), each invoice line item is first converted to JPY and then rounded to the nearest 10 yen. The invoice total is the sum of the rounded line items. By contrast, Cloud Analytics reports do not apply rounding, which may result in small discrepancies. --- URL: https://help.doit.com/docs/billing/invoices-and-payments/invoice-reconciliation-file # Invoice reconciliation files An invoice reconciliation file provides a summary of all your invoices, including paid, outstanding and overdue invoices. ## Required permissions - Invoice Viewer ## Download reconciliation files You can download a reconciliation file as a CSV file: 1. Sign in to the DoiT console, select **Billing** > **Invoices** from the top navigation mega menu. 1. Review the billing profile and the time range of invoices. These two settings define the scope of invoices in the reconciliation file. 1. Select the download icon in the upper-right corner of the page. ![The main Invoices page.](@site/assets/png/cmp-invoices-download-csv.png) ## Reconciliation file fields | Field | Description | | :------------- | :------------------------------------------------------------------------------------------------------------------------- | | Invoice Number | Invoice number, also called document number. You may need this number to make payments. | | Status | Status of the invoice. For example, `Open`, `Paid`, `Past Due`, etc. | | Entity | The _company name_ in the corresponding [billing profile](https://help.doit.com/docs/billing/billing-profiles). | | Invoice Date | The last day of the calendar month in the billing period. | | Due Date | The date on which we expect to receive the payment. | | Currency | The [billing currency](https://help.doit.com/docs/billing/billing-profiles/changing-your-billing-currency) of the corresponding billing profile. | | Total | The total amount of the invoice. | | Balance | The remaining amount on the invoice. It can be positive or negative. | --- URL: https://help.doit.com/docs/billing/invoices-and-payments/managing-invoices # View invoices details ## Required permission - Invoice Viewer ## View an invoice An invoice includes all charges and applicable credits/discounts for the corresponding billing period. To review an invoice: 1. Sign in to the DoiT console, select **Billing** > **Invoices** from the top navigation mega menu. 1. Locate the invoice of interest, select its **Invoice** number to open the invoice details page. The invoice details page consist of two parts: a _summary_ and a _drill down with itemized invoice lines_. Below is an example invoice details page: ![The Invoice details page.](@site/assets/png/cmp-invoices-details.png) ## Invoice summary - **Invoice Number**: Also called document number. You may need this number to make payments. - **Billing Profile**: The _company name_ in the corresponding [billing profile](https://help.doit.com/docs/billing/billing-profiles). - **Billing Profile ID**: An automatically generated unique identifier of the billing profile. - **Invoice Details**: A brief description of the purpose of the invoice. Below are some examples: - `Covering MONTH YEAR`: The billing period covered by the invoice. - `CC Fees`: The invoice is issued for [Credit card fees](https://help.doit.com/docs/billing/invoices-and-payments/credit-card-fees). - `Credit for Tax`: The invoice is issued to apply a reduction to the taxes you need to pay. - **Invoice Date**: The last day of the calendar month in the billing period. - **Due Date**: The date on which we expect to receive the payment. - **Status**: Status of the invoice. For example, `Open`, `Paid`, `Past Due`. - **Amount W/O Tax**: The total amount of the invoice before taxes. - **Balance**: The remaining amount on the invoice. It can be positive or negative. - **Documents**: Download the [PDF invoice](https://help.doit.com/docs/billing/invoices-and-payments/pdf-invoices). ## Invoice line items - **Description**: A short description of the purchased product/service. This field has the following possible values: - `Invoice Bucket`: If you have set up [Invoice bucketing](https://help.doit.com/docs/billing/billing-profiles/changing-invoice-settings#invoice-bucketing), the description of the first line in the drill down will be _Invoice Bucket_. The actual bucket name is shown in the **Details** column. See [Example invoices](https://help.doit.com/docs/billing/billing-profiles/changing-invoice-settings#example-invoices). - `Amazon Web Services`, `Google Cloud`, `Microsoft Azure`, `Office 365`, or other asset types: The type of the asset being charged. - `Cloud Intelligence Enhanced`, `Cloud Intelligence Enterprise`: If you purchase a DCI Enhanced or Enterprise plan directly with DoiT, on your invoice you'll see a corresponding line item with an appendix indicating how the amount is decided. For example, `DCI Enhanced CloudOps - Minimum Fee` means you're charged the fixed minimum fee, while `DCI Enhanced CloudOps - 3.00% cloud spend` means you're charged 3% of your monthly cloud spend during the billing period. See [Cloud Intelligence charges](https://help.doit.com/docs/billing/dci-billing#dci-charges) for more information. :::tip If you purchase a DCI Enhanced or Enterprise plan [via AWS Marketplace](https://help.doit.com/docs/connect-cloud/marketplace/subscribe-via-aws-marketplace), the charge is handled the same as your other AWS Marketplace purchases (see [Invoice settings](https://help.doit.com/docs/billing/billing-profiles/changing-invoice-settings#invoice-settings) and [an example of DCI charges](https://help.doit.com/docs/billing/dci-billing#dci-billing-via-marketplace)). ::: - `Flexsave`, `Flexsave Compute Savings`, `Flexsave SageMaker Savings`, `Flexsave RDS Savings`: See [Flexsave AWS invoicing](https://help.doit.com/docs/optimize/flexsave/aws/flexsave-aws-invoicing). - `Single Accelerator Purchase`: You purchased [DoiT accelerators professional service](https://help.doit.com/docs/services/proserv) during the billing period. - `Single Ticket Purchase`: (Cloud Intelligence™ Essentials only) You purchased the one-time service for individual inquiries during the billing period. - **Details**: A more detailed description of the product/service. The value of this field varies with products/services. - For AWS assets, this field contains the AWS Account ID; for Google Cloud assets, this field contains the Project ID (you might also see Cloud Billing account in this field when there are costs that cannot be directly attributed to a specific project). - If you have tagged assets, the tags appear after a vertical bar ( | ) and are the ending part of the description. See an [example invoice with tagged assets](https://help.doit.com/docs/integrations/asset-management/tag-assets#example-invoice). - For Google Cloud assets, if [your contract with DoiT](https://help.doit.com/docs/billing/contracts/access-contracts) includes a discount, the discount will be displayed in this field. For example, `Project 'example-project-1' with 7.00% discount`. Note that the actual discounts applied to individual SKUs depend on the contract; it's possible that within the same project, some SKUs have higher discounts than others. - `Adjustment for Discount`: The applied [Google Cloud adjustments](https://help.doit.com/docs/billing/invoices-and-payments/understand-your-invoice#google-cloud-adjustments). - `Additional projects` or `Additional accounts`: Projects/accounts billed by the invoice but not listed separately. See [Projects and Accounts in invoices](#projects-and-accounts-in-invoices). - `Correction`: An auto-generated balancing line to satisfy invoice and rounding rules. A `Correction` line brings the total sum of an invoice to -US$0.10 or -JP¥11.00. It is not a charge. - **SKU**: The purchasable Stock Keeping Unit (SKU) of the product/service. - **Units**: The quantity of billing units of the product/service. A negative quantity, for example `-1`, indicates a credit, discount, or other types of savings; the corresponding PPU amount is subtracted from the total cost. - **PPU**: Price Per Unit. - **Rate**: The [exchange rate](https://help.doit.com/docs/vendor-information/exchange-rates) at which you're charged. - **Price**: The total cost of the billing units of the product/service. - **Total**: The total amount of the invoice before taxes. - **Tax**: The total tax for the charges. - **Total W/Tax**: The total amount of the invoice after taxes. ## Projects and Accounts in invoices By default, an invoice contains up to 10 line items that are related to specific Google Cloud projects or AWS accounts, i.e., the top 10 Google Cloud projects or AWS accounts by cost. In case there are more than 10 projects/accounts billed by the invoice, the aggregated cost of the rest projects/accounts is shown in a separate line with a description of `Additional projects` or `Additional accounts`. If you need to show more than 10 projects/accounts in your invoices, open an expert inquiry. Also be aware of the following constraints: - One invoice can show at most 250 lines of individual projects/accounts. - Changes to the number of line items do not apply to historical invoices. ## See also - [Access contracts](https://help.doit.com/docs/billing/contracts/access-contracts) - [AWS billing explained: Invoice explainer](https://help.doit.com/docs/billing/billing-explained/invoice-explainer) - [Understand Google Workspace invoices](https://help.doit.com/docs/integrations/google-workspace/google-workspace-invoice) --- URL: https://help.doit.com/docs/billing/invoices-and-payments/pay-now # Pay now You can pay an outstanding or overdue invoice anytime with a credit card or using [SEPA Direct Debit](https://help.doit.com/docs/billing/billing-profiles/sepa-direct-debit) if it's configured in your billing profile. :::info Credit card fees Starting April 1, 2023, we charge a 2.9% processing fee for credit card payments where processing fee surcharges comply with applicable laws. See [Credit card fees](https://help.doit.com/docs/billing/invoices-and-payments/credit-card-fees) for more information. Note that our system does not distinguish between credit cards and debit cards. Paying with a debit card incurs the same surcharge of credit card payments. ::: ## Required permissions - Your DoiT account must have the **Invoice Viewer** permission. - You must have access to the [billing profile](https://help.doit.com/docs/billing/billing-profiles) associated with the invoice to pay. ## Pay an outstanding or overdue invoice To pay an outstanding (including _open_ and _partially paid_) or overdue invoice: 1. Sign in to the DoiT console, select **Billing** from the top navigation mega menu, and then select **Invoices**. 1. Locate the invoice of interest, select its **Invoice** number to open the invoice details page. 1. Select the **Pay now** button in the upper-right corner. ![The main Invoices page.](@site/assets/png/doit-invoices-pay-now.png) 1. Select your payment method in the **Pay Invoice** window. - SEPA: Available if you've set up [SEPA Direct Debit payment](https://help.doit.com/docs/billing/billing-profiles/sepa-direct-debit) in your billing profile. - Credit cards: Choose an existing credit card or fill in the necessary information to pay with a new credit card. ![Pay Invoice dialog.](@site/assets/png/doit-invoice-pay-method.png) 1. Review the **Payment amount**. It's possible to make a partial payment by changing the payment amount. 1. Select **Pay now** to confirm your payment. Once we receive the response from our payment service provider or your credit card processor, we'll notify you in the console of the transaction's status. If the payment is successful, the invoice will be marked as **Paid** or **Partially Paid**. --- URL: https://help.doit.com/docs/billing/invoices-and-payments/pdf-invoices # PDF invoices ## View your PDF invoice At the beginning of each month, we send a PDF invoice for the previous month's costs to the accounts payable contact specified in your [billing profile](https://help.doit.com/docs/billing/billing-profiles/setting-up-a-new-billing-profile). In general, a PDF invoice is organized into three main sections: _legal information_, _usage costs_, and _payment instructions_. Note that the specific content may vary based on the country of issuance and local jurisdictional requirements. ### Section 1: Legal information Legal information includes the registered company name, address, and tax IDs. This section of a PDF invoice shows the legal information of the [appropriate DoiT entity](https://help.doit.com/docs/vendor-information/general-vendor-information) and your billing address and company details specified in your [billing profile](https://help.doit.com/docs/billing/billing-profiles/setting-up-a-new-billing-profile). ### Section 2: Invoice summary, usage costs, and payment information Invoice summary is shown in the upper-right corner of the invoice. It contains: - **Invoice Date**: The last day of the calendar month in the billing period. - **Print Date**, **Print Time**: The date and time the invoice is posted. See [Invoice posting dates](https://help.doit.com/docs/billing/invoices-and-payments#invoice-posting-dates). - **Document Number**: Also called invoice number. You may need this number to make payments. - **Details**: A brief description of the purpose of the invoice. Example: `Covering MONTH YEAR`. Detailed usage costs for the month are displayed using a table. It contains: - **Description**: A short description of the purchased product/service. - **Details**: A more detailed description of the product/service. - **Quantity**: The quantity of billing units of the product/service. - **Unit Price** or **PPU**: Price per unit (PPU). - **Total**: The total cost of the billing units of the product/service. - **Total Before**: The total amount of the invoice _before_ taxes (Amount W/O Tax). - **Tax** or **VAT**: The total tax or VAT for the charges. - **TOTAL**: The total amount of the invoice _after_ taxes (Total W/Tax). Payment information contains: - **Payment Terms**: The number of days before the payment is due. - **Balance Owed**: The running balance of your account. ### Section 3: Payment instructions This section contains DoiT banking information and payment instructions. ### Example PDF invoice Below is an example PDF invoice by [DoiT International USA, Inc](https://help.doit.com/docs/vendor-information/general-vendor-information#united-states). ![An example PDF invoice](@site/assets/png/doit-invoice-pdf.png) ## Download your PDF invoice Users with the **Invoice viewer** permission can download PDF invoices from the console by: - Selecting the download icon next to an invoice entry on the main [Invoices](https://help.doit.com/docs/billing/invoices-and-payments) page, or - Selecting the attached PDF **Documents** on the [Invoice Details](https://help.doit.com/docs/billing/invoices-and-payments/managing-invoices) page --- URL: https://help.doit.com/docs/billing/invoices-and-payments/understand-your-invoice # Credits and discounts on invoices Depending on your contracts with DoiT and your cloud providers, you may see different items on your invoices, for example, credits, discounts, support charges, and adjustments. ## Required permission - Invoice Viewer ## Credits and discounts Credits are applied on the _undiscounted_ consumption. If there are both credits and discounts on your consumption, DoiT applies the following models when calculating the total amount of your monthly invoice before taxes (_Amount W/O Tax_). ### Google Cloud adjustments For Google Cloud, we calculate the total amount as below: **Total** = (`Consumption` − `Discounts` − `Credits`) + _Adjustment_(`Credits` × `Discount`) Where: - `Consumption`: Your total usage of the products/services on the invoice. - `Discounts`: Applicable DoiT discounts or custom pricing. - `Credits`: Applicable DoiT credits and credits from your cloud providers. You'll see an extra line item of `Adjustment for Discount` on your invoice. Suppose your Google Cloud consumption cost in January 2022 is US$ `100`, you have a `10%` discount and a credit of US$ `15`. The total amount on your Google Cloud invoice will be: **Total** = (100 − (100 × 10%) − 15) + (15 × 10%) = US$76.5 ### AWS PPA discounts The AWS Private Pricing Agreement (PPA, formerly EDP) discount is applied after credits. For AWS, we calculate the total amount as below: **Total** = (`Consumption` − `Credits`) × `Discount_rate` Suppose your AWS consumption cost is US$ `100`, you have a credit of US$ `15` and a `10%` PPA discount (discount rate `90%`). The total amount on your AWS invoice will be: **Total** = (100 − 15) × 90% = US$76.5 ### Caveats Be aware that the formula above is mainly for informative purposes. DoiT takes a more granular approach to reflecting discounts and credits in real-world situations, for example, when: - The discount changes during the month. - You're using services that are not eligible for discounts (preemptible instances, spot instances, Marketplace services, etc.). - The credit applies only to specific SKUs which may or may not be eligible for discounts. ## View account credits ### Credits widget To track your account credits, you can add a credits [widget](https://help.doit.com/docs/dashboards/custom-dashboards/widgets) to your [dashboard](https://help.doit.com/docs/dashboards/custom-dashboards). ### Promotional credits in reports When viewing your credits in Cloud Analytics reports, be aware that not including DoiT [promotional credits](https://help.doit.com/docs/cloud-analytics/reports/editing-your-cloud-report#promotional-credits) for Google Cloud customers and AWS customers on [DoiT consolidated billing accounts](https://help.doit.com/docs/amazon-web-services/import-aws-orgs#am-i-on-a-doit-consolidated-billing-account-or-a-dedicated-payer-account) may cause discrepancies between your monthly invoices and reports. #### Google Cloud invoices before January 2026 The example monthly invoice below contains two line items related to promotional credits: `Migration Credit` and its `Adjustment for Discount`. ![Invoice with promotional credits](@site/assets/png/console-invoices-promotional-credits.png) To have the same figures in your report, you must select the checkbox **Include promotional credits**. ![Cloud Analytics report with promotional credits](@site/assets/png/console-report-promotional-credits.png) #### Google Cloud invoices from January 2026 onwards Starting January 1, 2026, DoiT auto-forwards promotional credits from Google Cloud to eligible customers by default, which means: - Credits of the `PROMOTION` type are applied to billing data directly; they no longer appear as separate line items on invoices. - You can check the application of such credits in Cloud Analytics reports, using the **Credit type** `PROMOTION`. See below an example report. ![Cloud Analytics report with GCP auto-forwarded promotional credits](@site/assets/png/console-report-gcp-promotion.png) ## See also - [AWS Private Pricing Agreement (PPA) analysis](https://help.doit.com/docs/cloud-analytics/tutorials/example-reports#aws-enterprise-discount-program-edp-analysis) - [Google Cloud Billing data export](https://help.doit.com/docs/google-cloud/gcp-billing-export) - [Promotional credits](https://help.doit.com/docs/cloud-analytics/reports/editing-your-cloud-report#promotional-credits) - [Credits and discounts](https://help.doit.com/docs/cloud-analytics/reports/report-dimensions-groupings-and-filters#credits-and-discounts) --- URL: https://help.doit.com/docs/billing/perks # ISV marketplace DoiT ISV (independent software vendor) solutions are service-based benefits available to DoiT customers on demand at no extra cost, including promotions, special offers, pricing packages, and more. ## Required permission - Perks Viewer ## Access offers To access currently available offers: 1. Sign in to the DoiT console. 1. select **Billing** from the top navigation mega menu, and then select **ISV marketplace**. ![The ISV solutions page](@site/assets/png/doit-services-isv.png) You can filter offers by **Solution types** and the **Cloud marketplace** where they are listed. ## Register interest If you're interested in an offer, select it to view the details, then select **Register interest** on the offer page. Once you registered interest, we will contact you with more information. --- URL: https://help.doit.com/docs/changelog # Documentation changelog This page highlights the main changes in Cloud Intelligence documentation. For API updates, refer to the [Developer Hub changelog](https://developer.doit.com/changelog); for the latest feature releases, see the [Product changelog](https://changelog.doit.com/). ## August 2026 - **Anomaly detection**: Updated [Anomalies Manager access](https://help.doit.com/docs/governance/cloud-anomalies/access-anomalies) with a dedicated permission role. - **AI assistant**: Updated [AI assistant capabilities](https://help.doit.com/docs/general/ava/capabilities). - **AWS Intelligence**: Added a [FOCUS variant](https://help.doit.com/docs/dashboards/aws-intelligence) of the AWS Intelligence dashboard. - **Azure**: Updated [Azure one-click onboarding](https://help.doit.com/docs/connect-cloud/standalone-account/console-azure-one-click) documentation for the streamlined Azure tenant connection flow. - **CLI**: Published the [DCI CLI v2 guide](https://help.doit.com/docs/cli) with a [migration reference](https://help.doit.com/docs/cli/before-after-v2), [command cheatsheet](https://help.doit.com/docs/cli/cheatsheet), and [what's new in v2](https://help.doit.com/docs/cli/whats-new-v2-1). Updated [CLI query guidance](https://help.doit.com/docs/cli). - **Cloud Analytics**: Added [chart report drilldown](https://help.doit.com/docs/cloud-analytics/reports/view-reports#drill-down-into-report-charts) in view reports. Updated [sharing reports](https://help.doit.com/docs/cloud-analytics/reports/sharing-cloud-reports) with a shareable configuration link. Updated [report views](https://help.doit.com/docs/cloud-analytics/reports/view-reports) with averages in the series totals panel. Updated [supported AWS cost allocation tags](https://help.doit.com/docs/cloud-analytics/tutorials/supported-aws-cost-allocation-tags). Added [report annotation from chart context menus](https://help.doit.com/docs/cloud-analytics/annotations). - **CloudFlow**: Added [OpenAI and Anthropic Admin API connections](https://help.doit.com/docs/operate/cloudflow/connections/create-connection/connect-ai-providers), [OpenAI](https://help.doit.com/docs/operate/cloudflow/nodes/openai-node) and [Anthropic](https://help.doit.com/docs/operate/cloudflow/nodes/anthropic-node) nodes, and tutorials for [auditing AI API keys](https://help.doit.com/docs/operate/cloudflow/tutorials/tutorial-audit-ai-keys) and [disabling keys over a spend threshold](https://help.doit.com/docs/operate/cloudflow/tutorials/tutorial-anthropic-api-key-spend-threshold). Added documentation for the [Parallel paths node](https://help.doit.com/docs/operate/cloudflow/nodes/parallel-paths). Added support for triggering flows from [inbound email](https://help.doit.com/docs/operate/cloudflow/triggers/email-trigger) with attachment content parsing. Added an [AWS Health Notifications tutorial](https://help.doit.com/docs/operate/cloudflow/tutorials/tutorial-aws-health-notifications) and an [AI governance solution brief](https://help.doit.com/docs/operate/cloudflow/tutorials/tutorial-ai-governance-webhook). Documented [switch node routing](https://help.doit.com/docs/operate/cloudflow/nodes/switch) with an example flow. Expanded [Azure connections](https://help.doit.com/docs/operate/cloudflow/connections/create-connection/connect-azure) documentation and added a [disk management tutorial](https://help.doit.com/docs/operate/cloudflow/tutorials/tutorial-azure-unattached-managed-disks). Updated [templates](https://help.doit.com/docs/operate/cloudflow/templates) with deep-link support. - **Commitment Manager**: Updated [Manage commitments](https://help.doit.com/docs/optimize/commitment-manager/manage-commitment): Soft-deleted commitments preserve history. - **Composer**: Updated [Recipe results](https://help.doit.com/docs/composer/recipe-builder/view-recipe). Added per-class [instance counts](https://help.doit.com/docs/composer/recipe-builder) in the recipe builder Resources panel when filtering to owned resources. - **Dashboards**: Updated [custom dashboard widgets](https://help.doit.com/docs/dashboards/custom-dashboards/widgets), [carousel](https://help.doit.com/docs/dashboards/custom-dashboards/carousel), and [Add reports](https://help.doit.com/docs/dashboards/custom-dashboards/add-reports) with updated Add button behavior. - **Early Access Features**: Added a guide for the self-serve [Early Access Features](https://help.doit.com/docs/system-management/early-access-features) page. Added feature deep-link support. Updated [support documentation](https://help.doit.com/docs/consulting-support/intro) to note that early access features fall outside support SLA coverage. - **Fastly**: Updated [Fastly](https://help.doit.com/docs/connect-third-party/connect-fastly) integration dimension labels. - **General Settings**: Added [domain ownership verification](https://help.doit.com/docs/system-management/general-settings) for controlling which domains are approved for sharing and access. Added [Allowed invite domains](https://help.doit.com/docs/system-management/general-settings) for restricting user invitations to specified email domains. Added [customer-wide MFA requirement](https://help.doit.com/docs/system-management/general-settings) setting. - **GenAI Intelligence**: Updated [GenAI Intelligence dashboard](https://help.doit.com/docs/dashboards/genai/genai-intelligence) documentation. - **GitHub**: Updated [Connect GitHub](https://help.doit.com/docs/connect-third-party/connect-github) integration documentation. - **Google Cloud**: Updated [GCP service account connection](https://help.doit.com/docs/integrations/cloud-connect/connect-google-cloud-service-account) documentation. - **Insights**: Added [Compliance category](https://help.doit.com/docs/optimize/insights/proprietary) documentation to proprietary Insights pages. - **Integrations**: Updated [integrations catalog](https://help.doit.com/docs/integrations/catalog-overview) overview. Updated [Anthropic integration](https://help.doit.com/docs/integrations/connect-anthropic) card labels. Restored [Terraform PR Agent](https://help.doit.com/docs/terraform-pr-agent/introduction) in the integrations catalog. - **Kubernetes Intelligence**: Removed the legacy `container.clusters.connect` permission from the [GCP Cloud Connect permissions](https://help.doit.com/docs/vendor-information/security-and-data-access-policy) table for Kubernetes Intelligence. - **MFA**: Added guidance for [requiring MFA for individual users](https://help.doit.com/docs/user-management/multi-factor-authentication). - **Metrics**: Updated [Create a metric](https://help.doit.com/docs/operate/metrics/create-metric) and [View metrics](https://help.doit.com/docs/operate/metrics/view-metrics): Cloud Analytics Users and Read-Only roles can view but not manage metrics. - **MongoDB**: Updated [MongoDB data](https://help.doit.com/docs/mongodb/mongodb-data): the Resource ID for MongoDB Atlas now combines the Atlas project ID and cluster name to avoid cross-project merging. - **OCI**: Added Oracle Cloud Infrastructure to [cost anomaly detection](https://help.doit.com/docs/governance/cloud-anomalies) supported providers. Updated [Investigate anomalies](https://help.doit.com/docs/governance/cloud-anomalies/investigate-anomalies) with OCI tenancy and compartment hierarchy labels. - **PerfectScale for Commitments**: Added [fee structure documentation](https://help.doit.com/docs/perfectscale-for-commitments/understand-ps-for-commitments-fees). - **Users and access**: Updated [Manage roles](https://help.doit.com/docs/user-management/manage-roles) with contract management permissions and an Anomalies Manager role. ## July 2026 - **Amazon Web Services**: Updated [AWS standalone account connection](https://help.doit.com/docs/connect-cloud/standalone-account/console-aws) to clarify S3 prefix setup for CUR 2.0 data exports. Clarified that the [StackSet deployment target](https://help.doit.com/docs/integrations/cloud-connect/link-aws-account/link-account) can be an organizational unit (OU) or the organization root. - **Anomaly detection**: Added Anthropic Analytics to [supported cost anomaly detection integrations](https://help.doit.com/docs/governance/cloud-anomalies). Added guidance for [resolving missing IAM permissions](https://help.doit.com/docs/governance/cloud-anomalies/investigate-anomalies) when real-time anomaly detection shows a Partially enabled status. - **Audit logs**: Updated [audit logs](https://help.doit.com/docs/system-management/audit-logs) to clarify actor types in audit log events. - **AI assistant**: Added [thinking timeline](https://help.doit.com/docs/general/ava/using-ava) showing step-by-step progress while the AI assistant processes questions. Updated [rate limits](https://help.doit.com/docs/general/ava/using-ava#ask-questions). The AI assistant can now surface [cloud service quotas](https://help.doit.com/docs/general/ava/capabilities) nearing their limits for Google Cloud and AWS. Added [expert inquiries](https://help.doit.com/docs/general/ava/capabilities#expert-inquiries) in the AI assistant conversations. - **Budgets**: Added a [Budget Suggestions widget](https://help.doit.com/docs/governance/budgets/create-budget#ai-suggestions) on the Home page. Updated [budget scope](https://help.doit.com/docs/governance/budgets/create-budget) to support multiple dimension filters. - **CLI**: Updated [CLI authentication](https://help.doit.com/docs/cli) to add guidance on choosing between personal and service account API tokens, permission scopes, and secure setup. - **Cloud Analytics**: Added [series totals panel](https://help.doit.com/docs/cloud-analytics/reports/view-reports#series-totals) to report chart interactions. Added live [Grafana integration](https://help.doit.com/docs/cloud-analytics/tutorials/grafana). - **Cloud Diagrams**: Added [Overview layer](https://help.doit.com/docs/cloud-analytics/cloud-diagrams/layers/overview). - **CloudFlow**: Clarified [variable management constraints](https://help.doit.com/docs/operate/cloudflow/variables/create). Updated [templates](https://help.doit.com/docs/operate/cloudflow/templates) and [connections](https://help.doit.com/docs/operate/cloudflow/connections) to note that availability is filtered by cloud provider access. - **Commitment Manager**: Added audit events for commitment [operations](https://help.doit.com/docs/system-management/audit-logs) and commitment [adjustment changes](https://help.doit.com/docs/system-management/audit-logs). Added [commitment deletion](https://help.doit.com/docs/optimize/commitment-manager/manage-commitment). - **Composer**: Added a validation limit to the [snooze reason input](https://help.doit.com/docs/composer/recipe-builder/resource-details). Added [scan timing and manual scan guidance](https://help.doit.com/docs/composer/recipe-builder/account-coverage) for account coverage. Clarified supported resource types for the [Extended Support cost function](https://help.doit.com/docs/composer/recipe-builder/create-recipe). Added [Understanding recipes](https://help.doit.com/docs/composer/understanding-recipes) concept page and [Tutorial: Your first recipe](https://help.doit.com/docs/composer/tutorial-first-recipe) step-by-step walkthrough. - **DCI Billing**: Updated the list of excluded Google Cloud services in [DCI charges](https://help.doit.com/docs/billing/dci-billing). - **Expert Inquiries**: Added support for [attaching multiple accounts or projects](https://help.doit.com/docs/consulting-support/create-support-request) to a single inquiry. Updated [Create expert inquiries](https://help.doit.com/docs/consulting-support/create-support-request). - **Fastly**: Corrected [Fastly](https://help.doit.com/docs/connect-third-party/connect-fastly) reporting dimensions and system labels. - **General Settings**: Updated [General Settings](https://help.doit.com/docs/system-management/general-settings) with a new URL slug field for a human-readable alias in DoiT console URLs. - **GenAI Intelligence**: Updated [GenAI data](https://help.doit.com/docs/dashboards/genai/genai-data) to include Cursor user names for team members. Added [Kiro](https://help.doit.com/docs/dashboards/genai) (Amazon AI coding agent) as a supported GenAI provider for AWS customers. Added [Snowflake Cortex AI cost attribution](https://help.doit.com/docs/dashboards/genai/genai-data). - **GitHub**: Updated [GitHub integration](https://help.doit.com/docs/connect-third-party/connect-github) to reflect the supplementary GitHub App flow. - **Google Cloud**: Added instructions to [remove a Google Cloud feature](https://help.doit.com/docs/integrations/cloud-connect/connect-google-cloud-service-account#update-role) via the Google Cloud console. - **Insights**: Added a [financial metrics reference page](https://help.doit.com/docs/optimize/insights/proprietary/financial-metrics) covering Potential cost savings, Cost avoidance, Freed commitments, and Avoidable commitments. Added a [Highlights tab](https://help.doit.com/docs/optimize/insights/proprietary/insights-dashboard#highlights) to the Insights dashboard. Updated [Insights view](https://help.doit.com/docs/optimize/insights/proprietary/insights-view#insights-table) default table sorting by insights category. Added RDS DB instance reserved instances to [supported automated insights](https://help.doit.com/docs/optimize/insights/third-party/supported-insights) from AWS Cost Optimization Hub. Updated [Composer Insights](https://help.doit.com/docs/optimize/insights/proprietary/insights-dashboard) with billing data availability warnings. - **Kubernetes**: Added support for [multiple metrics in Kubernetes utilization reports](https://help.doit.com/docs/kubernetes/kubernetes-intelligence/kubernetes-utilization-data). - **MCP Server**: Updated [MCP Server connection steps](https://help.doit.com/docs/mcp/connections/connect) to reflect the current Claude connector interface. Updated per-client setup guides for [Cursor](https://help.doit.com/docs/mcp/connections/connect-cursor), [ChatGPT](https://help.doit.com/docs/mcp/connections/connect-chatgpt), [Codex](https://help.doit.com/docs/mcp/connections/connect-codex), [Gemini](https://help.doit.com/docs/mcp/connections/connect-gemini), and [VS Code](https://help.doit.com/docs/mcp/connections/connect-vscode). - **PerfectScale for Commitments**: Added [Accounts settings](https://help.doit.com/docs/perfectscale-for-commitments/account-settings) for configuring cloud providers, commitment types, and payer accounts. Added [linked account drill-down views](https://help.doit.com/docs/perfectscale-for-commitments/commitments-overview) for AWS payer accounts. Updated the [recommendations](https://help.doit.com/docs/perfectscale-for-commitments/recommendations) with calculation details and Flexsave exclusion notes. - **Sign-in**: Updated [sign-in documentation](https://help.doit.com/docs/general/sign-in) with the **Sign out of all devices** action, which revokes all active sessions from the avatar menu. - **Subprocessors**: Updated [third-party subprocessors](https://help.doit.com/docs/vendor-information/subprocessors) list; added Anthropic, Cloudflare, Fivetran, Glean, and other subprocessors. Added subprocessor sections for SELECT and Attribute. - **Users and access**: Free email domains can now be invited when a [per-customer setting](https://help.doit.com/docs/user-management/creating-a-new-user) is enabled. ## June 2026 - **Amazon Web Services**: Added support for [CloudFormation StackSets](https://help.doit.com/docs/integrations/cloud-connect/link-aws-account/link-account#create-a-role-automatically) and [Terraform](https://help.doit.com/docs/integrations/cloud-connect/link-aws-account/connect-aws-terraform) when linking AWS accounts. Added [CUR 2.0 upgrade](https://help.doit.com/docs/integrations/aws/upgrade-cur) instructions. - **Anomaly detection**: Added Amazon CloudWatch to [services with monthly billing spikes](https://help.doit.com/docs/governance/cloud-anomalies#spikes-at-the-beginning-of-the-month). Clarified [SKU-level and service-level anomaly evaluation frequency](https://help.doit.com/docs/governance/cloud-anomalies#billing-data-1). Updated AWS real-time anomaly setup with [least-privilege S3 bucket guidance](https://help.doit.com/docs/governance/cloud-anomalies/real-time-anomaly-detection/aws#s3-access). - **AI assistant**: Added [scheduled tasks](https://help.doit.com/docs/general/ava/scheduled-tasks), [pinned conversations](https://help.doit.com/docs/general/ava/managing-chats#pin-a-conversation), and [AI assistant rate limits](https://help.doit.com/docs/general/ava/using-ava#ask-questions). Added support information for [AI assistant interactions with Cloud Diagrams](https://help.doit.com/docs/general/ava/capabilities#cloud-diagrams). - **Cloud Analytics**: Added [report display settings](https://help.doit.com/docs/cloud-analytics/reports/display-settings), [compact mode](https://help.doit.com/docs/cloud-analytics/reports/view-reports#compact-mode), and [search in tabular reports](https://help.doit.com/docs/cloud-analytics/reports/view-reports#search-in-table). Clarified [Exclude partial intervals](https://help.doit.com/docs/cloud-analytics/reports/editing-your-cloud-report#exclude-partial-intervals) behavior. - **Cloud Diagrams**: Added [Azure diagram](https://help.doit.com/docs/cloud-analytics/cloud-diagrams/create/create-azure) support. Updated [diagram creation](https://help.doit.com/docs/cloud-analytics/cloud-diagrams/create) guidance for provider filtering in the wizard, [AWS ARN resource properties](https://help.doit.com/docs/cloud-analytics/cloud-diagrams/details/summary), and the AI assistant-powered [filtering](https://help.doit.com/docs/cloud-analytics/cloud-diagrams/actions/filter) and [cost overlay](https://help.doit.com/docs/cloud-analytics/cloud-diagrams/layers/costs) actions. - **CloudFlow**: Added guidance to [stop a running flow](https://help.doit.com/docs/operate/cloudflow/create-and-manage-flows/manage-flow#stop-a-running-flow), updated [run history](https://help.doit.com/docs/operate/cloudflow/run-history#stopped-runs) for stopped runs, documented [automatic local-variable value saving](https://help.doit.com/docs/operate/cloudflow/variables/create#local-variables), and [Google Cloud response field filtering](https://help.doit.com/docs/operate/cloudflow/nodes/gcp-node#filter-response-fields). - **Composer**: Updated [recipe builder](https://help.doit.com/docs/composer/recipe-builder/create-recipe) for cost functions and remediation detail. - **Dashboards**: Added [dashboard carousel widgets](https://help.doit.com/docs/dashboards/custom-dashboards/carousel), [report widget legends](https://help.doit.com/docs/dashboards/custom-dashboards/add-reports#report-legends), and [full screen mode](https://help.doit.com/docs/dashboards/manage-dashboard#dashboard-management-options). Clarified [My dashboards](https://help.doit.com/docs/dashboards/overview#categories-of-dashboards) grouping. - **GenAI Intelligence**: Added [Cursor support](https://help.doit.com/docs/connect-third-party/connect-cursor) in [GenAI Intelligence](https://help.doit.com/docs/dashboards/genai). Added [Anthropic connection-type guidance](https://help.doit.com/docs/integrations/connect-anthropic#which-integration). - **Insights**: Updated [Insight details](https://help.doit.com/docs/optimize/insights/proprietary/insight-details). - **Integrations**: Added a management option [Analyze](https://help.doit.com/docs/integrations/catalog-overview#management-options) action for healthy integrations in the **Others** category. - **Kubernetes**: Updated [Kubernetes documentation](https://help.doit.com/docs/kubernetes/intro) to distinguish Kubernetes Intelligence, EKS Intelligence, and GKE Intelligence. Updated [Kubernetes core](https://help.doit.com/docs/kubernetes/kubernetes-intelligence/get-started#enable-kubernetes-core) and [self-managed cluster connection](https://help.doit.com/docs/kubernetes/kubernetes-intelligence/connect-self-managed-clusters) instructions. - **MCP Server**: Updated [MCP Server connection methods](https://help.doit.com/docs/mcp/connections#connection-methods), authentication (Streamable HTTP OAuth vs local stdio `DOIT_API_KEY`), and required permissions guidance. - **Users and access**: Updated the instructions to [Create a new user](https://help.doit.com/docs/user-management/creating-a-new-user), [account assumption](https://help.doit.com/docs/user-management/account-assumption#prerequisites) prerequisites, and related [roles and permissions](https://help.doit.com/docs/user-management/manage-roles). ## May 2026 - **Alerts**: Clarified the **Last period actual cost** indicator when [creating or editing cost alerts](https://help.doit.com/docs/governance/alerts/create-alert). - **Anomaly detection**: Updated [anomaly notification](https://help.doit.com/docs/governance/cloud-anomalies/manage-anomaly-notifications) resend conditions and clarified the metadata shown when you acknowledge or edit acknowledged anomalies. - **AI assistant**: Added support to [investigate Cloud Analytics report and dashboard chart data with the AI assistant](https://help.doit.com/docs/general/ava/capabilities#reports). - **AI Workload Management**: Published [AI Workload Management](https://help.doit.com/docs/optimize/ai-workload-management) documentation: monitor AI and LLM workloads to track prompt caching, error rates, retry overhead, and RAG pipeline efficiency. - **Azure**: Updated [Azure standalone account connection](https://help.doit.com/docs/connect-cloud/standalone-account/console-azure) guidance with billing update timing, historical data backfill, expired client-secret troubleshooting, and export setup details. - **BigQuery Intelligence**: Clarified that BigQuery Intelligence reports run in your Google Cloud billing project, can consume BigQuery resources, and may need narrower filters or additional slots for large audit-log datasets. See [Set up BigQuery Intelligence](https://help.doit.com/docs/dashboards/bigquery-intelligence/set-up-bigquery-intelligence). - **Cloud Analytics**: Added support for [Cloud Analytics copilot report generation](https://help.doit.com/docs/cloud-analytics/reports/create-report#generate-a-report-with-copilot), shared [folder organization](https://help.doit.com/docs/cloud-analytics/reports/organize-reports#folders) across reports, metrics, and allocations, and the **GCP Cost at List Price** and **GCP On Demand Cost** extended metrics. Clarified scheduled report email attachments and invoice breakdown report behavior. - **Cloud Diagrams**: Added guidance for [VPC Service Controls issues during Google Cloud diagram creation](https://help.doit.com/docs/cloud-analytics/cloud-diagrams/create/create-gcp#vpc-service-controls). - **CloudFlow**: Added documentation for [workspaces](https://help.doit.com/docs/operate/cloudflow/create-and-manage-flows/workspaces), the updated AWS and GCP connection wizard, HTTP node pagination, timestamp parameters with custom relative dates, and Google Cloud Storage object-data limits in GCP and CLI nodes. - **Composer**: Updated Composer [resource details](https://help.doit.com/docs/composer/recipe-builder/resource-details) documentation. - **GenAI Intelligence**: Updated [GenAI data](https://help.doit.com/docs/dashboards/genai/genai-data) documentation with an Amazon Bedrock cost-by-user reporting example. - **Insights**: Updated [Insights](https://help.doit.com/docs/optimize/insights) documentation for unified proprietary and third-party insights, security insights, remediation details, dashboard tabs, historical charts, and Composer resource insight views. - **Integrations**: Added the [Anthropic Analytics API integration](https://help.doit.com/docs/connect-third-party/connect-anthropic-analytics), a centralized [data latency](https://help.doit.com/docs/integrations/data-latency) reference, and clarified [Cursor data refresh and usage mapping](https://help.doit.com/docs/connect-third-party/connect-cursor#cursor-data-in-cloud-analytics). - **Kubernetes**: Clarified [Kubernetes Intelligence agent](https://help.doit.com/docs/kubernetes/kubernetes-intelligence/get-started) connectivity, PerfectScale endpoint requirements, licensing, existing PerfectScale cluster mapping, and GKE cost tracking. - **MCP Server**: Updated the [MCP Server](https://help.doit.com/docs/mcp/mcp-server) tool list, troubleshooting guidance, required permissions, local connection recommendations, and connection instructions for VS Code and GitHub Copilot. - **Navigation**: Added [Keyboard shortcuts](https://help.doit.com/docs/general/keyboard-shortcuts). - **PerfectScale for Commitments**: Published [PerfectScale for Commitments](https://help.doit.com/docs/perfectscale-for-commitments) documentation. - **Users and access**: Added [multi-factor authentication](https://help.doit.com/docs/user-management/multi-factor-authentication), password reset, default organization, and [View as another user](https://help.doit.com/docs/user-management/account-assumption#view-as-admin) guidance. ## April 2026 - **Anomaly detection**: Added support for [cost anomaly detection](https://help.doit.com/docs/governance/cloud-anomalies) for ClickHouse Cloud, Cloudflare, Cursor, Elastic Cloud, GitHub, Grafana Cloud, and Vercel. Added **Maps Static API** to the list of [Services with cost spikes at the beginning of the month](https://help.doit.com/docs/governance/cloud-anomalies#spikes-at-the-beginning-of-the-month). Added instructions to [create report annotations from anomaly details](https://help.doit.com/docs/governance/cloud-anomalies/investigate-anomalies#annotate-report), [open Cloud Diagrams from anomaly details](https://help.doit.com/docs/governance/cloud-anomalies/investigate-anomalies#open-in-cloud-diagrams), and use AI analysis with preselected context. - **AI assistant**: Added support to [use the AI assistant in Slack](https://help.doit.com/docs/general/ava/ava-in-slack), [share the AI assistant conversations by email](https://help.doit.com/docs/general/ava/managing-chats#share-a-conversation), and [explore Cloud Analytics charts with the AI assistant](https://help.doit.com/docs/general/ava/capabilities#reports). - **Azure**: Clarified [Azure billing update timing](https://help.doit.com/docs/connect-cloud/standalone-account/console-azure#billing-update-frequency). - **Budgets**: Added support to compare budget spend with a previous period when [viewing budget progress](https://help.doit.com/docs/governance/budgets/view-budget). - **Cloud Analytics**: Added [Invoice month](https://help.doit.com/docs/cloud-analytics/reports/report-dimensions-groupings-and-filters#google-cloud-specific) dimension for GCP billing. Added [quick label filters](https://help.doit.com/docs/cloud-analytics/labels). Clarified [report rounding](https://help.doit.com/docs/cloud-analytics/reports#rounding-of-numbers). - **Cloud Diagrams**: Updated the [Cloud Diagrams dashboard](https://help.doit.com/docs/cloud-analytics/cloud-diagrams#cloud-diagrams-dashboard) with favorites, last sync status, cost trending, and signal enhancements. Updated [AWS diagram creation](https://help.doit.com/docs/cloud-analytics/cloud-diagrams/create/create-aws) for the new account onboarding flow. - **CloudFlow**: Added support for [budget threshold event triggers](https://help.doit.com/docs/operate/cloudflow/triggers/dci-event-trigger#budgets), [alert event triggers](https://help.doit.com/docs/operate/cloudflow/triggers/dci-event-trigger#alert-events), [event payload filters](https://help.doit.com/docs/operate/cloudflow/triggers/dci-event-trigger#event-payload-filter), [node deep links](https://help.doit.com/docs/operate/cloudflow/intro), [node menu actions](https://help.doit.com/docs/operate/cloudflow/create-and-manage-flows/manage-nodes), [CLI node connection variables](https://help.doit.com/docs/operate/cloudflow/nodes/cli), [`$variables` in Code and CLI nodes](https://help.doit.com/docs/operate/cloudflow/variables/access#use-variables-in-code-and-cli-nodes), and the **not every in** [filter operator](https://help.doit.com/docs/operate/cloudflow/nodes/filter#filter-operators). Clarified [output schema](https://help.doit.com/docs/operate/cloudflow/nodes/output-schema), [test node pagination](https://help.doit.com/docs/operate/cloudflow/nodes/test), [AWS node waiters](https://help.doit.com/docs/operate/cloudflow/nodes/aws-node), and LLM node **Suggest schema** behavior. - **Cloud Intelligence CLI**: Updated [CLI documentation](https://help.doit.com/docs/cli) to use the `dci` base command. - **Commitment Manager**: Clarified how to [include specific SKUs](https://help.doit.com/docs/optimize/commitment-manager/create-commitment) when a service is excluded. - **Composer**: Added [Composer dashboard](https://help.doit.com/docs/composer/dashboard) and [Recipe builder](https://help.doit.com/docs/composer/recipe-builder) documentation. Clarified how Composer is enabled for AWS, Azure, and Google Cloud. - **Google Cloud**: Clarified [Google Cloud billing account name defaults](https://help.doit.com/docs/google-cloud/create-google-cloud-billing-account). - **Integrations**: Added a centralized [Integrations catalog](https://help.doit.com/docs/integrations/catalog-overview). Updated [Slack integration](https://help.doit.com/docs/integrations/app-integrations/slack) and [shared Slack channel](https://help.doit.com/docs/integrations/app-integrations/shared-slack-channel) instructions. Updated [Microsoft Teams integration](https://help.doit.com/docs/integrations/app-integrations/msteams) requirements for private and shared channels. Added support to create [Linear threads from CloudFlow](https://help.doit.com/docs/operate/cloudflow/nodes/threads). Updated [Coralogix](https://help.doit.com/docs/connect-third-party/connect-coralogix) regional domains, [Fastly](https://help.doit.com/docs/connect-third-party/connect-fastly) token billing-access requirements, and [New Relic](https://help.doit.com/docs/connect-third-party/connect-newrelic) region limits. - **Kubernetes**: Clarified [Kubernetes Intelligence agent](https://help.doit.com/docs/kubernetes/kubernetes-intelligence) pricing, telemetry, private cluster support, and PerfectScale account requirements. Updated [EKS namespace](https://help.doit.com/docs/kubernetes/eks-intelligence/analyze-eks-costs) attribution guidance. - **MCP Server**: Updated [MCP Server](https://help.doit.com/docs/mcp/mcp-server) authorization, tools, workflow, and troubleshooting guidance. Removed the Customer ID step from the remote connector setup. - **Security and compliance**: Updated [Audit Logs](https://help.doit.com/docs/system-management/audit-logs) with the **Event name** column, event ID information, default sorting, and filter options. - **Users and access**: Clarified pre-built roles in [Manage roles](https://help.doit.com/docs/user-management/manage-roles) and admin sign-in behavior in [Authentication settings](https://help.doit.com/docs/user-management/settings). ## March 2026 - **Amazon Web Services**: Updated [AWS support billing](https://help.doit.com/docs/billing/billing-explained/aws-support) with the new AWS support plans. Added support for [AWS cost allocation tag](https://help.doit.com/docs/cloud-analytics/tutorials/supported-aws-cost-allocation-tags) `map-migrated`. - **Anomaly detection**: Added support to [resend notifications for active anomalies](https://help.doit.com/docs/governance/cloud-anomalies/manage-anomaly-notifications#resend-notifications-for-active-anomalies). Updated [allocations in anomaly notifications](https://help.doit.com/docs/governance/cloud-anomalies/manage-anomaly-notifications). Clarified the requirements for [AWS real-time anomaly SNS setup](https://help.doit.com/docs/governance/cloud-anomalies/real-time-anomaly-detection/aws). - **App integrations**: Added support for [Linear integration](https://help.doit.com/docs/integrations/app-integrations/linear). Clarified the required permissions to [Set up Jira integration](https://help.doit.com/docs/integrations/app-integrations/jira). - **AI assistant**: Added instructions to [share conversations](https://help.doit.com/docs/general/ava/managing-chats). Clarified [AI report creation availability](https://help.doit.com/docs/general/ava/capabilities). - **Benchmarks**: Published [Benchmarks](https://help.doit.com/docs/cloud-analytics/benchmarks) documentation: compare your FinOps maturity against anonymized peers using industry and spend-tier benchmarks. - **BigQuery Intelligence**: Added explanation about the [Costs update process](https://help.doit.com/docs/dashboards/bigquery-intelligence#queries-run-by-bigquery-intelligence). - **Billing and invoicing**: Clarified the [invoice handling when your AWS distributor is Ingram Micro](https://help.doit.com/docs/billing/billing-explained/billing-differences). - **Cloud Analytics**: Added support to [preview a report](https://help.doit.com/docs/cloud-analytics/reports/create-report#preview-a-report) using a sample of your data, [export reports from dashboards and the AI assistant](https://help.doit.com/docs/dashboards/custom-dashboards/add-reports), and [forecast with custom dates](https://help.doit.com/docs/cloud-analytics/tutorials/forecasting). Clarified the usage of [report default view](https://help.doit.com/docs/cloud-analytics/reports/create-report#set-as-default-view) and [report subscription permissions](https://help.doit.com/docs/cloud-analytics/reports/schedule-report). Removed the limit on custom metrics in [multi-metric reports](https://help.doit.com/docs/cloud-analytics/tutorials/multi-metric-report). - **Cloud Diagrams**: Updated [supported services](https://help.doit.com/docs/cloud-analytics/cloud-diagrams), [GCP onboarding flow](https://help.doit.com/docs/cloud-analytics/cloud-diagrams/create/create-gcp), and [costs tab and anomaly views](https://help.doit.com/docs/cloud-analytics/cloud-diagrams/layers/costs). Added a [FinOps signals column](https://help.doit.com/docs/cloud-analytics/cloud-diagrams#cloud-diagrams-dashboard) to the Cloud Diagrams dashboard. - **CloudFlow**: Added support for [Subflows](https://help.doit.com/docs/operate/cloudflow/subflows), [Folders](https://help.doit.com/docs/operate/cloudflow/create-and-manage-flows/folders), and [cost anomaly event triggers](https://help.doit.com/docs/operate/cloudflow/triggers/dci-event-trigger#cost-anomaly-events). Added instructions to [Query external BigQuery datasets in an SQL node](https://help.doit.com/docs/operate/cloudflow/nodes/sql#connect-to-external-bigquery-datasets) and [Delete a branch node](https://help.doit.com/docs/operate/cloudflow/nodes/branch#delete-a-branch-node). Updated configuration options for [variables](https://help.doit.com/docs/operate/cloudflow/variables/create). Updated waiter configurations in [AWS nodes](https://help.doit.com/docs/operate/cloudflow/nodes/aws-node) and [Google Cloud nodes](https://help.doit.com/docs/operate/cloudflow/nodes/gcp-node). Added support for the following nodes: - [AI Flow Builder](https://help.doit.com/docs/operate/cloudflow/agent-builder): Creates or updates flows using natural language. - [CLI node](https://help.doit.com/docs/operate/cloudflow/nodes/cli): Runs custom CLI commands as a step in your flow. - [Cloud Intelligence node](https://help.doit.com/docs/operate/cloudflow/nodes/doit): Runs Cloud Intelligence actions directly from your flow. - [Test node](https://help.doit.com/docs/operate/cloudflow/nodes/test): Tests data from individual nodes before publishing the whole flow. - **Composer**: Added onboarding instructions of the new [Composer](https://help.doit.com/docs/composer) feature. - **Insights**: Added support for Insights API. Updated the required permissions for [AWS Trusted Advisor insights](https://help.doit.com/docs/optimize/insights/third-party/permissions#aws-trusted-advisor-insights). - **Kubernetes**: Updated instructions to [Connect self-managed clusters](https://help.doit.com/docs/kubernetes/kubernetes-intelligence/connect-self-managed-clusters). - **Security and compliance**: Added support for [Audit Logs](https://help.doit.com/docs/system-management/audit-logs). Published [Open source licenses](https://help.doit.com/docs/vendor-information/licenses) for attribution notices for third-party open source software included in DoiT products and services. - **Third-party platforms**: Clarified the requirements to connect [Databricks](https://help.doit.com/docs/databricks/connect-databricks). Added information about [Datadog](https://help.doit.com/docs/datadog/datadog-data) rate limits. ## February 2026 - **Anomaly detection**: Updated the list of services that are assessed differently due to [Spikes at the beginning of the month](https://help.doit.com/docs/governance/cloud-anomalies#spikes-at-the-beginning-of-the-month). - **AI assistant**: Now you can ask the AI assistant to define custom labels for Cloud Intelligence features, generate Cloud Analytics reports, or interact with your dashboards. See [AI assistant capabilities](https://help.doit.com/docs/general/ava/capabilities). - **Amazon Web Services**: Clarified the [Cross-account AWS IAM role](https://help.doit.com/docs/integrations/cloud-connect/link-aws-account#cross-account-role) when linking AWS accounts to Cloud Intelligence. Added support for [cost allocation tags](https://help.doit.com/docs/cloud-analytics/tutorials/supported-aws-cost-allocation-tags): `karpenter.sh/nodeclaim`, `karpenter.sh/nodepool`, `karpenter.k8s.aws/c2nodeclass`, and `aws:lambda:capacity-provider`. - **Billing & invoicing**: Clarified the impact of [Google Cloud promotional credits on invoices](https://help.doit.com/docs/billing/invoices-and-payments/understand-your-invoice#promotional-credits-in-reports). - **Cloud Analytics**: Now you can add a custom metric when creating a [Multi-metric report](https://help.doit.com/docs/cloud-analytics/tutorials/multi-metric-report). - **Cloud Diagrams**: Added support for the [Security layer](https://help.doit.com/docs/cloud-analytics/cloud-diagrams/layers/security) that helps you visualize security insights and elements across your environment. - **CloudFlow**: Updated [Billing data schema](https://help.doit.com/docs/operate/cloudflow/nodes/sql/billing-data) for CloudFlow SQL nodes; added support for DataHub. Added support for new node types: [Sleep node](https://help.doit.com/docs/operate/cloudflow/nodes/sleep), [Sub flow node](/operate/cloudflow/subflows /subflow.mdx). Added support for the **Truncate** action in [Date/time Transform nodes](https://help.doit.com/docs/operate/cloudflow/nodes/date-time); added support for `