Skip to main content

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:

    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.
    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:

    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

      AWS Data Exports page showing AttributeCurExport with status Healthy, type CUR 2.0

    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

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.
    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:

    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:

    # 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.

  3. Verify your Helm version — version 3.8.0 or above is supported:

    helm version
  4. Install the Helm chart:

    helm upgrade -i attribute \
    oci://quay.io/attribute/operator-chart \
    -f <values.yaml> \
    -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:

    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:

    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

    Terminal output of kubectl get pods -n attribute showing five attribute pods all in Running state with READY 1/1

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.