# Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation This site has an agentic ask interface you may use to query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.north.cloud/docs/index.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. --- # North.cloud North.cloud gives you real-time savings, automated FinOps, and dynamic optimization across cloud providers. One platform built for control, savings, and scale.
Learn more about all our services at [North.cloud](https://north.cloud) and get started for free at [app.north.cloud](https://app.north.cloud) ! # Quickstart Create a consolidated view of all your cloud spend and enable better cost control using our savings and data services. Create an account in under 1 minute.

Get started now!

{% embed url="" %} {% hint style="info" %} **Use your work email address.** North creates your organization from the domain of the email you sign up with. Consumer mail domains and disposable mail domains are rejected, and the domain must have a working mail server. {% endhint %} Different onboarding options: {% content-ref url="/pages/jqc8Fi7nAxzdTp69ilNW" %} [AWS Onboarding](/docs/getting-started/quickstart/aws-onboarding) {% endcontent-ref %} {% content-ref url="/pages/t35IH0JkUviNEiZHrpH1" %} [GCP Onboarding](/docs/getting-started/quickstart/gcp-onboarding) {% endcontent-ref %} {% content-ref url="/pages/LPausUdn5nxQAuiRBlxX" %} [Azure Onboarding](/docs/getting-started/quickstart/azure-onboarding) {% endcontent-ref %} # AWS Onboarding Learn how to integrate your AWS account with North.cloud ## Connect Your AWS Account {% embed url="" %} {% hint style="info" %} Prerequisites: * [ ] If you don't have an account, we recommend you create a free account first at [app.north.cloud](https://app.north.cloud) * [ ] You need to have the appropriate permissions to create IAM permissions into the payer account * [ ] Enable cloudformation stackset. Guide from the [official AWS documentation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-activate-trusted-access.html). {% endhint %} {% stepper %} {% step %} ### Get your account information ready **AWS Account ID** {% hint style="info" %} If your AWS account is part of an AWS organization, please sign up using the billing account only (also called payer account). This will allow North to analyze usage throughout all your accounts and centralize savings opportunities into one view. {% endhint %} {% embed url="" %} **AWS Organizational Unit ID** {% hint style="info" %} You can find your Organizational Unit ID [here](https://us-east-1.console.aws.amazon.com/organizations/v2/home/accounts). {% endhint %}
{% endstep %} {% step %} ### Select your integration method **We recommend using the CloudFormation stack** which deploys all the required permissions. We also offer Terraform, CLI, or console commands. [Learn more about the permissions.](/docs/getting-started/permissions-required) {% hint style="info" %} If you are running the setup manually, make sure to replace the placeholder ADD\_ORG\_ID\_HERE with your Organizational Unit ID as shown [here](#add-your-payer-account-number-s). {% endhint %} {% tabs %} {% tab title="CloudFormation" %} * [Click here to open a pre-configured CloudFormation stack](https://us-east-1.console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/quickcreate?templateURL=https%3A%2F%2Fnorth-cloudformation-template-public.s3.us-east-1.amazonaws.com%2Fbilling-and-usage-read-only-cf-stack%2Fnorth-all-features.yaml\&stackName=NorthCloudformationAllFeatures\¶m_OrgId=ADD_ORG_ID_HERE) in a new tab. *This link has a placeholder for your Organizaitonal Unit ID, please add your own.* * Once in the page, scroll to the bottom and click "I acknowledge". * Finally, click "Create stack" to create the stack. {% endtab %} {% tab title="Terraform" %} * Create .tf file 

provider "aws" {
  region = "us-east-1"
}

variable "org_id" {
  type        = string
  description = "The OrgId you want to deploy this stack in"
}

locals {
  is_us_east_1 = data.aws_region.current.name == "us-east-1"
}

data "aws_region" "current" {}
data "aws_caller_identity" "current" {}

# IAM Role for Cost and Usage Access
resource "aws_iam_role" "north_cost_usage_role" {
  name = "NorthCostAndUsageRole"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::480850768557:root"
        }
        Action = ["sts:AssumeRole"]
      }
    ]
  })
}

resource "aws_iam_policy" "north_cost_usage_policy" {
  name = "NorthCostAndUsageReadOnlyPolicy"
  
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "NorthCostAndUsageReadOnlyPolicyID"
        Effect = "Allow"
        Action = [
          "ce:Get*",
          "ce:Describe*",
          "ce:List*",
          "ce:Start*",
          "account:GetAccountInformation",
          "billing:Get*",
          "payments:List*",
          "payments:Get*",
          "tax:List*",
          "tax:Get*",
          "consolidatedbilling:Get*",
          "consolidatedbilling:List*",
          "invoicing:List*",
          "invoicing:Get*",
          "cur:Get*",
          "cur:Validate*",
          "freetier:Get*",
          "ec2:DescribeCapacity*",
          "ec2:DescribeReservedInstances*",
          "ec2:DescribeSpot*",
          "rds:DescribeReserved*",
          "rds:DescribeDBRecommendations",
          "rds:DescribeAccountAttributes",
          "ecs:DescribeCapacityProviders",
          "es:DescribeReserved*"
        ]
        Resource = "*"
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "north_cost_usage_policy_attachment" {
  role       = aws_iam_role.north_cost_usage_role.name
  policy_arn = aws_iam_policy.north_cost_usage_policy.arn
}

# CloudWatch Cross-Account Access Role
resource "aws_iam_role" "cloudwatch_cross_account_access_role" {
  name = "NorthCloudWatchCrossAccountAccessRole"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = ["sts:AssumeRole"]
        Principal = {
          Service = "cloudwatch-crossaccount.amazonaws.com"
        }
      },
      {
        Effect = "Allow"
        Action = ["sts:AssumeRole"]
        Principal = {
          AWS = "arn:aws:iam::480850768557:role/NorthCURReadOnly"
        }
      }
    ]
  })
  
  path = "/"
  
  tags = {
    Purpose = "CrossAccountMonitoring"
  }
}

resource "aws_iam_policy" "cloudwatch_cross_account_access_policy" {
  name = "NorthCloudWatchCrossAccountAccessPolicy"
  
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = ["sts:AssumeRole"]
        Resource = "arn:aws:iam::*:role/NorthCloudWatchCrossAccountSharingRole"
      },
      {
        Effect = "Allow"
        Action = [
          "s3:GetObject",
          "s3:ListBucket",
          "s3:GetBucketLocation"
        ]
        Resource = [
          "arn:aws:s3:::north-cur-bucket-${data.aws_caller_identity.current.account_id}",
          "arn:aws:s3:::north-cur-bucket-${data.aws_caller_identity.current.account_id}/*"
        ]
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "cloudwatch_cross_account_access_policy_attachment" {
  role       = aws_iam_role.cloudwatch_cross_account_access_role.name
  policy_arn = aws_iam_policy.cloudwatch_cross_account_access_policy.arn
}

# CloudWatch Cross-Account Sharing Role
resource "aws_iam_role" "cloudwatch_cross_account_sharing_role" {
  name = "NorthCloudWatchCrossAccountSharingRole"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          AWS = [
            "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root",
            aws_iam_role.cloudwatch_cross_account_access_role.arn
          ]
        }
        Action = ["sts:AssumeRole"]
      }
    ]
  })
  
  path = "/"
  
  depends_on = [aws_iam_role.cloudwatch_cross_account_access_role]
}

resource "aws_iam_policy" "cloudwatch_cross_account_sharing_policy" {
  name = "NorthCloudWatchCrossAccountSharingPolicy"
  
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = ["cloudwatch:GetMetricData"]
        Resource = "*"
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "cloudwatch_cross_account_sharing_policy_attachment" {
  role       = aws_iam_role.cloudwatch_cross_account_sharing_role.name
  policy_arn = aws_iam_policy.cloudwatch_cross_account_sharing_policy.arn
}

# North Premium IAM Role
resource "aws_iam_role" "north_premium_role" {
  name = "NorthCostAndUsageRolePremium"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::480850768557:root"
        }
        Action = ["sts:AssumeRole"]
      }
    ]
  })
}

resource "aws_iam_policy" "north_premium_policy" {
  name = "NorthCostAndUsageReadOnlyPolicy"
  
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Sid      = "NorthPremiumPolicy1"
        Action   = "iam:CreateServiceLinkedRole"
        Resource = "arn:aws:iam::*:role/aws-service-role/compute-optimizer.amazonaws.com/AWSServiceRoleForComputeOptimizer*"
        Condition = {
          StringLike = {
            "iam:AWSServiceName" = "compute-optimizer.amazonaws.com"
          }
        }
      },
      {
        Effect   = "Allow"
        Sid      = "NorthPremiumPolicy2"
        Action   = "iam:PutRolePolicy"
        Resource = "arn:aws:iam::*:role/aws-service-role/compute-optimizer.amazonaws.com/AWSServiceRoleForComputeOptimizer"
      },
      {
        Effect = "Allow"
        Sid    = "NorthPremiumPolicy3"
        Action = [
          "compute-optimizer:*",
          "ec2:DescribeInstances",
          "ec2:DescribeVolumes",
          "ecs:List*",
          "autoscaling:DescribeAutoScalingGroups",
          "lambda:ListFunctions",
          "lambda:ListProvisionedConcurrencyConfigs",
          "organizations:ListAccounts",
          "cloudwatch:GetMetricStatistics",
          "rds:DescribeDBRecommendations",
          "rds:DescribeReservedDBInstances*"
        ]
        Resource = "*"
      },
      {
        Effect   = "Allow"
        Sid      = "NorthPremiumPolicy4"
        Action   = "organizations:EnableAWSServiceAccess"
        Resource = "*"
        Condition = {
          StringEquals = {
            "organizations:ServicePrincipal" = "compute-optimizer.amazonaws.com"
          }
        }
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "north_premium_policy_attachment" {
  role       = aws_iam_role.north_premium_role.name
  policy_arn = aws_iam_policy.north_premium_policy.arn
}

# CUR S3 Bucket
resource "aws_s3_bucket" "cur_bucket" {
  bucket = "north-cur-bucket-${data.aws_caller_identity.current.account_id}"
  
  tags = {
    Purpose = "CostAndUsageReports"
  }
}

resource "aws_s3_bucket_ownership_controls" "cur_bucket_ownership" {
  bucket = aws_s3_bucket.cur_bucket.id
  
  rule {
    object_ownership = "BucketOwnerEnforced"
  }
}

resource "aws_s3_bucket_public_access_block" "cur_bucket_public_access" {
  bucket = aws_s3_bucket.cur_bucket.id
  
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_versioning" "cur_bucket_versioning" {
  bucket = aws_s3_bucket.cur_bucket.id
  
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "cur_bucket_encryption" {
  bucket = aws_s3_bucket.cur_bucket.id
  
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_s3_bucket_lifecycle_configuration" "cur_bucket_lifecycle" {
  bucket = aws_s3_bucket.cur_bucket.id
  
  rule {
    id     = "expire365days"
    status = "Enabled"
    
    expiration {
      days = 365
    }
  }
}

resource "aws_s3_bucket_policy" "cur_bucket_policy" {
  bucket = aws_s3_bucket.cur_bucket.id
  
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "AWSBillingDeliveryPermissions"
        Effect = "Allow"
        Principal = {
          Service = "billingreports.amazonaws.com"
        }
        Action = [
          "s3:PutObject",
          "s3:GetBucketAcl",
          "s3:GetBucketLocation"
        ]
        Resource = [
          "arn:aws:s3:::${aws_s3_bucket.cur_bucket.id}/*",
          "arn:aws:s3:::${aws_s3_bucket.cur_bucket.id}"
        ]
      },
      {
        Sid    = "AllowCrossAccountAccess"
        Effect = "Allow"
        Principal = {
          AWS = aws_iam_role.cloudwatch_cross_account_access_role.arn
        }
        Action = [
          "s3:GetObject",
          "s3:ListBucket",
          "s3:GetBucketLocation"
        ]
        Resource = [
          "arn:aws:s3:::${aws_s3_bucket.cur_bucket.id}/*",
          "arn:aws:s3:::${aws_s3_bucket.cur_bucket.id}"
        ]
      }
    ]
  })
  
  depends_on = [
    aws_s3_bucket.cur_bucket,
    aws_iam_role.cloudwatch_cross_account_access_role
  ]
}

# CUR Report (conditionally created in us-east-1)
resource "aws_cur_report_definition" "cur_report" {
  count = local.is_us_east_1 ? 1 : 0
  
  report_name                = "aws-cost-report"
  time_unit                  = "HOURLY"
  format                     = "Parquet"
  compression                = "Parquet"
  additional_schema_elements = ["RESOURCES", "SPLIT_COST_ALLOCATION_DATA"]
  s3_bucket                  = aws_s3_bucket.cur_bucket.id
  s3_prefix                  = "cur-reports"
  s3_region                  = "us-east-1"
  report_versioning          = "CREATE_NEW_REPORT"
  refresh_closed_reports     = false
  
  depends_on = [aws_s3_bucket_policy.cur_bucket_policy]
}

# CloudWatch StackSet
resource "aws_cloudformation_stack_set" "north_cloudwatch_stackset" {
  name             = "NorthCloudWatchStackSet"
  permission_model = "SERVICE_MANAGED"
  
  auto_deployment {
    enabled                          = true
    retain_stacks_on_account_removal = false
  }
  
  capabilities = ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"]
  
  parameters = {
    ParentAccountId = data.aws_caller_identity.current.account_id
  }
  
  operation_preferences {
    failure_tolerance_percentage = 100
    max_concurrent_percentage    = 100
  }
  
  template_body = <<TEMPLATE
AWSTemplateFormatVersion: '2010-09-09'
Description: Propagates Stack to 'Enable CloudWatch in central monitoring account to assume permissions to view CloudWatch data in the downstream accounts'
Parameters:
  ParentAccountId:
    Type: String
Resources:
  NorthCloudWatchCrossAccountSharingRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: NorthCloudWatchCrossAccountSharingRole
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              AWS:
                - !Sub arn:aws:iam::${ParentAccountId}:root
                - !Sub arn:aws:iam::${ParentAccountId}:role/NorthCloudWatchCrossAccountAccessRole
            Action:
              - sts:AssumeRole
      Path: "/"
      Policies:
        - PolicyName: NorthCloudWatchCrossAccountSharingPolicy
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - cloudwatch:GetMetricData
                Resource: "*"
TEMPLATE
  
  depends_on = [aws_iam_role.cloudwatch_cross_account_access_role]
}

resource "aws_cloudformation_stack_set_instance" "north_cloudwatch_stackset_instance" {
  stack_set_name       = aws_cloudformation_stack_set.north_cloudwatch_stackset.name
  deployment_targets {
    organizational_unit_ids = [var.org_id]
  }
  region = "us-east-1"
}

# Outputs
output "cur_bucket_name" {
  description = "Name of the CUR S3 bucket"
  value       = aws_s3_bucket.cur_bucket.id
}

output "cur_bucket_arn" {
  description = "ARN of the CUR S3 bucket"
  value       = aws_s3_bucket.cur_bucket.arn
}

output "cross_account_role_arn" {
  description = "ARN of the CloudWatch cross-account access role"
  value       = aws_iam_role.cloudwatch_cross_account_access_role.arn
}

output "premium_role_arn" {
  description = "ARN of the North Premium IAM role"
  value       = aws_iam_role.north_premium_role.arn
}

output "cur_report_status" {
  description = "Status of CUR Report creation"
  value       = local.is_us_east_1 ? "Created in us-east-1" : "Not created - deploy in us-east-1"
}
{% endtab %} {% tab title="CLI" %} * Run the following command on the AWS CLI. *The code below has a placeholder for your Organizaitonal Unit ID, please add your own.* {% code overflow="wrap" %} ```bash aws cloudformation create-stack --stack-name NorthCloudformationAllFeatures --template-url https://north-cloudformation-template-public.s3.us-east-1.amazonaws.com/billing-and-usage-read-only-cf-stack/north-all-features.yaml --region us-east-1 --capabilities CAPABILITY_NAMED_IAM --parameters ParameterKey=OrgId,ParameterValue=ADD_ORG_ID_HERE ``` {% endcode %} {% endtab %} {% tab title="Console (manual)" %} * Deploy a CloudFormation stack in the AWS console that will create a read-only cross-account role. This will enable North to recommend the best savings posture based on your usage. * In the AWS Management Console, select CloudFormation and “Create Stack”. * Select the "Specify an Amazon S3 template URL" and enter the URL below: ```url https://north-cloudformation-template-public.s3.us-east-1.amazonaws.com/billing-and-usage-read-only-cf-stack/north-all-features.yaml ``` * On the "Specify stack details" page, enter the following information: * Stack name: Enter "NorthCloudformationAllFeatures" (or your desired stack name) * Click "Next" * Click “Create stack” {% endtab %} {% endtabs %} {% endstep %} {% step %} ### Verify your access North.cloud will automatically verify your access after your deployment and confirm if your onboarding has been completed successfully. You can also verify manually if any failures happen or need to run the processes asynchronously. {% embed url="" %} {% endstep %} {% step %} ### Start saving Once North.cloud completes your savings and data analysis, we'll send you a confirmation email. You'll then have access to all our AI-powered optimization features, the same tools that help leading companies achieve top 1% cloud efficiency. {% endstep %} {% endstepper %} ## Update Your North Stack Update your North stack when North needs a permission that your current stack does not grant. Your North stack is the CloudFormation stack that you deployed during onboarding. The update applies the current North template to your North stack. You will typically need to do this when North releases new features that you may want to use. {% hint style="info" %} Turn on trusted access for CloudFormation StackSets in AWS Organizations before you update your North stack. See the [official AWS documentation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-activate-trusted-access.html). {% endhint %} {% tabs %} {% tab title="CloudFormation" %} 1. Open CloudFormation in the AWS account and region where you deployed your North stack. 2. Select your North stack. The default name is `NorthCloudformationAllFeatures`. 3. Start an update of the stack. 4. Replace the current template with this Amazon S3 URL: `https://north-cloudformation-template-public.s3.us-east-1.amazonaws.com/billing-and-usage-read-only-cf-stack/north-all-features.yaml` 5. Keep the existing value of the `OrgId` parameter. 6. Acknowledge that the stack creates IAM resources. 7. Review the changes that AWS lists. 8. Submit the update. {% endtab %} {% tab title="CLI" %} Run the following command on the AWS CLI. If your North stack has a different name, replace `NorthCloudformationAllFeatures` with that name. {% code overflow="wrap" %} ```bash aws cloudformation update-stack --stack-name NorthCloudformationAllFeatures --template-url https://north-cloudformation-template-public.s3.us-east-1.amazonaws.com/billing-and-usage-read-only-cf-stack/north-all-features.yaml --region us-east-1 --capabilities CAPABILITY_NAMED_IAM --parameters ParameterKey=OrgId,UsePreviousValue=true ``` {% endcode %} {% endtab %} {% tab title="Terraform" %} 1. Copy the current Terraform file from the Terraform tab under Select your integration method. 2. Run `terraform apply` in the Terraform workspace that you used for your first deployment. Terraform reads the existing state of that workspace and updates your existing resources. A new workspace tries to create every resource again. That fails, because your Cost and Usage Report bucket already exists. {% endtab %} {% endtabs %} ### Member Accounts Your North stack adds the `NorthCloudWatchCrossAccountSharingRole` role to each member account in the Organizational Unit that you entered as `OrgId`. Member accounts that join that Organizational Unit later get the role automatically. To include an account outside that Organizational Unit, change `OrgId` to an Organizational Unit ID that contains the account. # GCP Onboarding Learn how to integrate your GCP account with North.cloud {% hint style="info" %} Based on your billing account's data volume, Google Cloud can take up to 5 days to fully migrate your data during billing export. If possible, start the billing export before you start onboarding. This speeds up the process. You can resume onboarding at any time. More from the [official GCP documentation](https://cloud.google.com/billing/docs/how-to/export-data-bigquery). {% endhint %} {% embed url="" %} {% hint style="info" %} Prerequisites: * [ ] If you do not have an account, we recommend that you create a free account first at [app.north.cloud](https://app.north.cloud) * [ ] Make sure you have the minimum role `BigQuery Data Owner` within the billing account. This role lets you create and share billing datasets. {% endhint %} {% stepper %} {% step %} ### Go to the [Billing Export](https://console.cloud.google.com/billing/export) Select the billing account you want to add and click **Edit Settings.**
{% endstep %} {% step %} ### Enable billing export for all You will repeat the step 3 below for all billing reports. * [ ] Standard usage cost * [ ] Detailed usage cost * [ ] Pricing
{% endstep %} {% step %} ### Select a project and billing dataset {% hint style="info" %} Selecting a project does not prevent other projects under your billing account from being included in your dataset. The project only serves as a storage location for the data. You can create a new project and dataset, or use an existing one. {% endhint %} Choose the project where your data will be hosted. All projects under your billing account remain available. You can set the dataset name to any convention you prefer. You can also use our recommended name, `north_billing_dataset`. This dataset holds your standard usage cost, detailed usage cost, and pricing exports. Note the name. You need it in the last two steps. {% endstep %} {% step %} ### Set up the CUD export The Committed Use Discount (CUD) metadata export gives North.cloud the data it needs to calculate commitment coverage and utilization. * On the same [Billing Export](https://console.cloud.google.com/billing/export) settings page from the previous step, enable **Enable committed use discounts (CUD) metadata export**. * Use the same project as before. Google Cloud writes the CUD export into its own dataset. It does not write it into your billing dataset. We recommend that you name this dataset `north_cud_dataset` so it is easy to identify later. Note the name you choose. You need it in the last two steps. {% endstep %} {% step %} ### Enable the [recommender](https://console.cloud.google.com/active-assist/export/create) {% hint style="info" %} When you enable the recommender, GCP sends you a permission request. This request is the Recommender service asking for access to your other GCP services. It needs that access to provide accurate recommendations. {% endhint %} {% hint style="warning" %} If you see an error like `BigQuery Data Transfer is not enabled for `, enable the [BigQuery Data Transfer API](https://cloud.google.com/bigquery/docs/enable-transfer-service) for that project and try again. If it still fails, you may need to grant permission to the transfer service agent directly. See [GCP's troubleshooting guide](https://cloud.google.com/bigquery/docs/transfer-troubleshooting#authorization_and_permission_issues). {% endhint %} North.cloud uses Google Cloud Platform (GCP) recommendations. We integrate them with our internal machine learning and AI services. * Choose the same project and billing dataset used earlier. * Configure the transfer. This sets how often recommendations can be generated. We generally recommend the following: * Name: `north_config` * Schedule option: Daily ( Day, 1 ) * Start: `00:00` * Destination settings: the dataset you created or selected earlier {% endstep %} {% step %} ### Share your datasets with North.cloud North.cloud reads your exports with a read-only principal. Share every dataset that holds an export. This means your billing dataset and your CUD dataset. For each dataset: 1. Open the dataset in BigQuery. Select **Sharing**, then **Permissions**. 2. Select **Add Principal**. Paste the Principal ID shown during onboarding. 3. Assign both roles: `BigQuery Data Viewer` and `BigQuery Metadata Viewer`. 4. Save. Then add your project ID and billing dataset name to North.cloud. {% hint style="info" %} A dataset that is not shared is the most common reason a table dropdown is empty in the next step. North.cloud tells you when this happens, and it gives you the sharing steps in place. {% endhint %} {% embed url="" %} {% endstep %} {% step %} ### Select the corresponding tables in North.cloud North.cloud lists five billing exports. Each one has a table and a dataset. | Row in North.cloud | GCP billing export | | ------------------ | -------------------------------------- | | Billing Header | Standard usage cost | | Billing Detail | Detailed usage cost | | Pricing | Pricing | | CUD | Committed use discounts (CUD) metadata | | Recommender | Recommender export | For each row, select the table from the dropdown. The **Dataset** field beside it shows which dataset North.cloud reads that table from. Four of the rows read from your billing dataset. CUD is the exception, because Google Cloud writes that export into its own dataset. The CUD row defaults to `north_cud_dataset`. If you named your CUD dataset something else, type that name into the **Dataset** field. North.cloud re-checks the dataset when you leave the field, then loads the tables it finds. Select **Use recommended** to accept the table North.cloud detected for one row. Select **Use all recommended** to accept every detected table at once. Select a table for every row before you continue. See Troubleshooting below if a table you expect is missing. If a dropdown has no options, North.cloud shows a warning under that row. The warning states the reason and offers **Check again**. If North.cloud cannot read the dataset, the warning also offers **How to fix**, which gives the sharing steps for that dataset. See Troubleshooting below for what each message means. {% embed url="" %} {% endstep %} {% step %} ### Start saving Once North.cloud completes your savings and data analysis, we will send you a confirmation email. You will then have access to all our AI-powered optimization features, the same tools that help leading companies achieve top 1% cloud efficiency. {% endstep %} {% endstepper %} ## Troubleshooting ### A Table Dropdown Is Empty in North.cloud North.cloud shows a warning under the row. The message tells you which of three things happened. | Message | What it means | What to do | | ---------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------- | | Dataset not accessible | North.cloud cannot read the dataset. | Select **How to fix** for the sharing steps. Grant both roles. Then select **Check again**. | | No tables in dataset | North.cloud read the dataset and found no tables. | Check the dataset name. If the export does not exist yet, create it in BigQuery. | | Not checked yet | North.cloud has not read this dataset. | Select **Check again**. | A new export can take a few hours to generate its first table. If the dataset is correct and shared, wait and select **Check again**. ### `BigQuery Data Transfer is not enabled for ` When Enabling the Recommender Enable the [BigQuery Data Transfer API](https://cloud.google.com/bigquery/docs/enable-transfer-service) for that project. If the error continues, you may need to grant permission to the transfer service agent directly. See [GCP's authorization troubleshooting guide](https://cloud.google.com/bigquery/docs/transfer-troubleshooting#authorization_and_permission_issues). ### A `cloud_pricing_export_*` or CUD Table Is Not Showing Up in the Dropdown If a table does not appear, the export is probably not enabled yet. Go back to the [Billing Export](https://console.cloud.google.com/billing/export) settings page and enable it. A new export can take a few hours to write its first table. If you already enabled the export, check that the row points at the correct dataset. Google Cloud writes the CUD export into its own dataset. Your pricing export stays in your billing dataset. ### North.cloud Stopped Receiving Billing Data From GCP North.cloud reads your GCP billing exports from BigQuery every day. The app shows the banner "We stopped receiving billing data from GCP" in two cases: * **No new billing data for more than 72 hours.** North.cloud can read your datasets, but no new data arrives in your billing exports. Your GCP cost data in North.cloud stays out of date until new data arrives. * **No price data from your Pricing export.** Your usage cost data arrives, but none of it has price data from your Pricing export. Your usage cost data in North.cloud stays current. To find the cause, check your exports in Google Cloud: * **The exports are enabled.** On the [Billing Export](https://console.cloud.google.com/billing/export) settings page, confirm that Standard usage cost, Detailed usage cost, Pricing, and the CUD metadata export are all enabled. * **Each export writes to the dataset you selected in North.cloud.** North.cloud reads only the datasets you selected during onboarding. If you moved an export to a different dataset, North.cloud cannot find its new data. * **Each export table has recent data.** In BigQuery, open each export table and confirm that it has rows from the last few days. If every export is enabled and has recent data, contact . ### North.cloud Is Not Receiving Commitment Data From GCP North.cloud reads your CUD (committed use discount) metadata export from BigQuery every day. If your billing data arrives but no data arrives in your CUD export, the app shows the banner "We are not receiving commitment data from GCP". Your GCP cost data in North.cloud stays current. To find the cause, check your CUD export in Google Cloud: * **The CUD export is enabled.** On the [Billing Export](https://console.cloud.google.com/billing/export) settings page, confirm that the CUD metadata export is enabled. * **The CUD export is in the dataset you selected in North.cloud.** Google Cloud writes the CUD export into its own dataset. North.cloud reads only the CUD dataset you selected during onboarding. The recommended name is `north_cud_dataset`. * **The CUD export table has recent data.** In BigQuery, open the `cud_subscriptions_export` table and confirm that it has rows from the last few days. If the CUD export is enabled and has recent data, contact . # Azure Onboarding Learn how to integrate your Azure account with North.cloud This process creates a read-only identity in your tenant, a storage account to hold your cost exports, and three daily Cost Management exports. North stores no secrets and no credentials. ## Before You Start {% hint style="info" %} Prerequisites: * [ ] If you do not have an account, create a free account first at [app.north.cloud](https://app.north.cloud). * [ ] Confirm you hold the Azure roles listed below. Ask your Azure administrator if you are not sure. * [ ] Collect your Subscription and your Billing Account ID. * [ ] Ask your North representative for the WIF Subject and the WIF Audience. {% endhint %} ### Roles You Need The person who runs the onboarding must hold the following roles. | Role | Scope | Why it is needed | | ------------------------------------------------------------------------------------ | --------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | Application Administrator, Application Developer, or Cloud Application Administrator | Entra ID, tenant-wide | Creates the App Registration. Configures the federated identity credential. | | Billing Account Owner or Billing Account Contributor | Billing account | Creates the Cost Management exports. Assigns Cost Management Reader at the billing scope. | | Contributor or Owner | Target subscription | Creates the resource group, the storage account, and the blob container. | | Owner or User Access Administrator | Tenant root | Assigns the three tenant-level roles: Reservations Reader, Savings Plan Reader, and Reader on the tenant-root management group. | Contributor and Billing Account Owner cannot write role assignments at the tenant root. Some tenants also need a Global Administrator to [elevate access](https://learn.microsoft.com/azure/role-based-access-control/elevate-access-global-admin) before the tenant-root management group can be assigned. `Microsoft.Authorization/roleAssignments/write` is in Owner. It is not in Contributor. You must hold it at the scope where each role is assigned. Subscription Owner covers the Storage Blob Data Reader grant only. Cost Management Reader needs the billing-account role. The three tenant-root roles need the tenant-scoped role. [Azure permissions](/docs/getting-started/permissions-required/azure-permissions) lists every action the onboarding performs, and every permission North receives. ### How to Verify Your Roles #### 1. Entra ID: App Registration Permissions Go to **entra.microsoft.com > Users > your user > Assigned Roles**. Confirm you hold Application Administrator, Application Developer, or Cloud Application Administrator. The role lets you create App Registrations, Service Principals, and Federated Identity Credentials.
To check the exact permissions, click the role name. Under **Description**, confirm the role includes: * `microsoft.directory/applications/create` * `microsoft.directory/applications/credentials/update` * `microsoft.directory/servicePrincipals/create` #### 2. Billing Account: Cost Management Permissions Go to **portal.azure.com > Cost Management + Billing > Access Control (IAM)**. Confirm you hold Billing Account Owner or Billing Account Contributor. Your Billing Account ID is under **Properties** on the same page.
The role lets you create Cost Management exports and assign Cost Management Reader to the App Registration. To confirm, click your role assignment and check that it includes: * `Microsoft.CostManagement/exports/write` (create exports) * `Microsoft.Authorization/roleAssignments/write` (assign roles at billing scope) #### 3. Subscription: Resource Creation Permissions Go to **portal.azure.com > Subscriptions > your subscription > Access control (IAM) > View my access**. Confirm you hold Owner or Contributor.
To check the exact permissions: 1. Go to **Subscriptions > your subscription > Access control (IAM) > Roles**. 2. Search for your role, for example Contributor. 3. Click the role name, then click **Permissions**. 4. Confirm the list includes: 1. `Microsoft.Resources/subscriptions/providers/register/action` (register resource providers) 2. `Microsoft.Resources/subscriptions/resourceGroups/write` (create resource groups) 3. `Microsoft.Storage/storageAccounts/write` (create storage accounts) 4. `Microsoft.Storage/storageAccounts/blobServices/containers/write` (create containers) 5. `Microsoft.Authorization/roleAssignments/write` (assign RBAC roles - included in Owner but **not** in Contributor; Owner is required for this action) {% hint style="info" %} **Note on scope:** `Microsoft.Authorization/roleAssignments/write` is in Owner but not Contributor - and it must be held *at the scope where each role is assigned*. Subscription Owner only covers the Storage Blob Data Reader grant; Cost Management Reader (billing account) and the three tenant-root roles (both commitment roles plus Reader on the tenant-root management group) need the billing- and tenant-scoped roles in the Prerequisites table above. If any Step 5 grant fails, the script reports it and exits non-zero - have an admin with the right scope assign the missing role(s) via Access control (IAM), then re-run. {% endhint %} #### Cost Management: Export Creation Access Go to **portal.azure.com > Cost Management + Billing > Cost Management > Exports**. If the Exports page opens and the **+ Add** button is available, you can create exports. If the Exports page shows an access error, you do not hold Billing Account Owner or Billing Account Contributor at the billing account scope. ### Supported Agreement Types | Agreement Type | FOCUS Export | Actual and Amortized Export | Billing Account Scope | | ---------------------------------- | ------------ | --------------------------- | --------------------- | | Enterprise Agreement (EA) | Yes | Yes | Enrollment | | Microsoft Customer Agreement (MCA) | Yes | Yes | Billing account | | Microsoft Partner Agreement (MPA) | Yes | Yes | Billing account | #### Enterprise Agreement Customers If your organization uses an Enterprise Agreement, note the following differences: * Your Billing Account ID is your Enrollment Number, a numeric ID. Find it in the Azure Portal under Cost Management + Billing > Properties, or in the EA Portal. * If your EA restricts cost visibility, the person who runs the onboarding may also need EA Admin or Department Admin access to enable cost exports at the billing account scope. * EA enrollment admins must enable "AO view charges" and "DA view charges" in the EA Portal. If those settings are off, the exports can return empty data. * The exports are created at the billing account, or enrollment, scope. That scope includes every subscription and department under the EA. You do not onboard each subscription separately. ### Information You Need You look up the first two values in the Azure Portal. Your North Customer Success Engineer supplies the rest. | Input | Source | Where to find it, or how it is used | | ------------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | Subscription | You | Azure Portal > Subscriptions. Use the name or the ID of the subscription where you want the storage account created. | | Billing Account ID | You | Azure Portal > Cost Management + Billing > Properties. This is the billing account North reads cost data from. | | WIF Subject | North | Identifies North's authentication identity. | | WIF Audience | North | Identifies North's authentication pool. | | App Name (optional) | North | Display name for the App Registration created in your tenant. The default is `north`. Your North representative tells you if a different name is needed. | Your North representative usually sends you a ready-to-paste command with the North-supplied values already filled in. You then add your subscription and your billing account ID. ## Connect Your Account Choose one of the two methods below. The result is the same. {% tabs %} {% tab title="Onboarding script" %} Run the script in Azure Cloud Shell, or in any terminal with the Azure CLI installed and authenticated with `az login`. Azure Cloud Shell is the simpler option, because the Azure CLI is already installed and already authenticated there. Each of the seven steps below is idempotent. If you run the script again, it detects the resources that already exist and skips them. {% stepper %} {% step %} ### Get the script Your North representative provides the script file. Make it executable: ```bash chmod +x north_azure_onboarding_v3.sh ``` {% endstep %} {% step %} ### Run the script ```bash ./north_azure_onboarding_v3.sh \ "" \ "" \ "" \ "" \ [] ``` The last argument is optional. Omit it to use the default name, `north`. Example: {% code overflow="wrap" %} ```bash ./north_azure_onboarding_v3.sh "My Subscription" "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy_yyyy-mm-dd" "us-east-1:aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" "us-east-1:bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb" ``` {% endcode %} {% hint style="warning" %} The WIF Subject and WIF Audience values above are placeholders. Use the exact values your North representative supplied. {% endhint %} {% endstep %} {% step %} ### Send the output values to North When the script finishes, it prints your connection details. Copy them and send them to your North contact. ``` App Name: Tenant ID: Client ID: Billing Account ID: Subscription ID: Storage Account: Container: north-exports ``` {% endstep %} {% endstepper %} ### What the Script Does **Step 1. Register the Cost Management Exports provider.** Registers `Microsoft.CostManagementExports` on your subscription. Azure requires this before any cost export can be created. Registration is free and adds no ongoing cost. **Step 2. Create an App Registration.** Creates an Entra ID App Registration, named `north` by default. This is the identity North authenticates as when it reads your export files. A matching Service Principal is created in your tenant. If an App Registration with that name already exists, the script reuses it. If two or more apps share that name, the script stops and asks you to resolve the duplicate first. This prevents an unrelated app from being rebound by mistake. The script creates no client secrets and no certificates. It grants no admin consent and no API permissions. It gives North no ability to modify any Azure resource. **Step 3. Configure secretless authentication.** Creates a Federated Identity Credential on the App Registration. North's AWS infrastructure obtains a signed JWT from Amazon Cognito. Entra ID validates that JWT against Cognito's public OIDC endpoint, then issues a short-lived access token. The trust is defined by three exact-match fields: issuer, subject, and audience. The issuer is fixed at `https://cognito-identity.amazonaws.com`. Your North representative supplies the subject and the audience. **Step 4. Create a storage account and container.** | Resource | Name | Purpose | | --------------- | ----------------------------- | ----------------------------------------- | | Resource Group | `north-billing-rg` | Contains the storage account. | | Storage Account | `northexports` | Holds the cost export Parquet files. | | Blob Container | `north-exports` | The container inside the storage account. | The storage account name is derived from your subscription ID, so that it is globally unique. Storage cost is small. The export files are a few megabytes per month. If you later enable a firewall on this storage account, you must also enable "Allow trusted Azure services access". Cost Management cannot write the exports otherwise. Updating that configuration needs the Owner role on the storage account. Contributor is not enough. **Step 5. Assign RBAC roles.** Grants the App Registration the five read-only roles listed on [Azure permissions](/docs/getting-started/permissions-required/azure-permissions). North cannot create, modify, or delete anything in your environment. If a role assignment fails, the script reports it and exits with a non-zero status. Ask an administrator with the right scope to assign the missing role through Access control (IAM), then run the script again. **Step 6. Confirm provider registration.** Waits for the Cost Management Exports provider from step 1 to finish activating. This usually takes less than 30 seconds. **Step 7. Create the Cost Management exports.** Creates three daily exports that write Snappy-compressed Parquet files to your container. | Export | Type | Storage path | Description | | ------------------------ | ----------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------- | | `north-focus-export` | FOCUS Cost, version 1.0 | `focus/` | The primary export. Carries actual and amortized cost in one file, following the FinOps FOCUS standard. | | `north-actual-export` | Actual Cost | `actual/` | Invoice-basis cost data. Kept as a backup and validation source. | | `north-amortized-export` | Amortized Cost | `amortized/` | Amortized cost data, which spreads upfront commitment fees across the term. Kept as a backup and validation source. | Each export runs daily at midnight UTC. Each one covers month-to-date data and overwrites the previous day's file, so the current month is always current. {% endtab %} {% tab title="Azure Portal" %} Use these steps to set up the integration by hand instead of running the script. The result is the same. {% stepper %} {% step %} ### Register the Cost Management Exports provider 1. Go to **Azure Portal > Subscriptions > your subscription > Settings > Resource providers**. 2. Search for `Microsoft.CostManagementExports`. 3. If the status is "NotRegistered", click **Register**. 4. Wait for the status to change to "Registered". {% endstep %} {% step %} ### Create an App Registration 1. Go to **entra.microsoft.com > App registrations > New registration**. 2. Set the name to `north`, or to the name your North representative provided. 3. For supported account types, select **Accounts in this organizational directory only**, which is single tenant. 4. Leave the Redirect URI blank. 5. Click **Register**. 6. Record the **Application (client) ID**. You send it to North at the end. {% endstep %} {% step %} ### Configure Workload Identity Federation 1. In the App Registration you created, go to **Certificates & secrets > Federated credentials > Add credential**. 2. Select **Other issuer**. 3. Enter the following values exactly. | Field | Value | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | Issuer | `https://cognito-identity.amazonaws.com` | | Subject identifier | Supplied by North | | Audience | Supplied by North | | Name | `-aws-federation`, for example `north-aws-federation`. This matches the App Registration name from the previous step. | | Description | `North AWS Lambda WIF trust` | 4. Click **Add**. {% hint style="warning" %} The Subject and Audience values are specific to your North environment. Use the exact values your North representative supplied. Do not use placeholder values. {% endhint %} {% endstep %} {% step %} ### Create a storage account and container 1. Go to **Azure Portal > Storage accounts > Create**. 2. Enter the following settings. | Setting | Value | | -------------------- | ------------------------------------------------------------------------------------------- | | Resource group | Create new: `north-billing-rg` | | Storage account name | `northexports`. It must be globally unique, lowercase, and carry no hyphens. | | Region | East US, or your preferred region | | Primary service | Azure Blob Storage | | Performance | Standard | | Redundancy | LRS, locally-redundant storage | 3. Click **Review + create**, then **Create**. 4. Open the new storage account, then go to **Containers > + Container**. 5. Set the name to `north-exports`. 6. Leave the access level at Private, which is the default. 7. Click **Review + Create**. {% endstep %} {% step %} ### Assign the RBAC roles Create five role assignments for the App Registration. For each role, do the following. 1. Go to the scope named in the table below. 2. Go to **Access control (IAM) > Add > Add role assignment**. 3. Search for the role name. 4. On the Members tab, select **User, group, or service principal**. 5. Click **Select members**, search for the App Registration you created earlier, for example `north`, and select it. 6. Click **Review + assign**. | Role | Where to assign it | | ------------------------ | --------------------------------------------------------------------------- | | Storage Blob Data Reader | Storage account > Containers > `north-exports` > Access control (IAM) | | Cost Management Reader | Cost Management + Billing > your billing account > Access control (IAM) | | Reservations Reader | Azure Portal > Reservations > Access control (IAM) | | Savings Plan Reader | Azure Portal > Savings plans > Access control (IAM) | | Reader | Azure Portal > Management groups > Tenant Root Group > Access control (IAM) | [Azure permissions](/docs/getting-started/permissions-required/azure-permissions) explains what each role grants. {% endstep %} {% step %} ### Create the Cost Management exports 1. Go to **Azure Portal > Cost Management > Exports > Add**. Exports can sit under Reporting + Analytics. 2. Create the three exports below. **Export 1, FOCUS Cost. This is the primary export.** | Setting | Value | | ----------------- | ----------------------------------- | | Name | `north-focus-export` | | Type of data | Cost and usage details (FOCUS) | | Dataset version | 1.0 | | Frequency | Daily export of month-to-date costs | | Start date | Today | | File format | Parquet | | Compression | Snappy | | Overwrite data | On | | File partitioning | On | | Storage account | `northexports` | | Container | `north-exports` | | Directory | `focus` | **Export 2, Actual Cost. This is a backup source.** | Setting | Value | | ----------------- | ----------------------------------- | | Name | `north-actual-export` | | Type of data | Cost and usage details (actual) | | Frequency | Daily export of month-to-date costs | | Start date | Today | | File format | Parquet | | Compression | Snappy | | Overwrite data | On | | File partitioning | On | | Storage account | `northexports` | | Container | `north-exports` | | Directory | `actual` | **Export 3, Amortized Cost. This is a backup source.** | Setting | Value | | ----------------- | ----------------------------------- | | Name | `north-amortized-export` | | Type of data | Cost and usage details (amortized) | | Frequency | Daily export of month-to-date costs | | Start date | Today | | File format | Parquet | | Compression | Snappy | | Overwrite data | On | | File partitioning | On | | Storage account | `northexports` | | Container | `north-exports` | | Directory | `amortized` | | {% endstep %} | | {% step %} ### Send the connection details to North Send the following values to your North representative. | Value | Where to find it | | ------------------ | ----------------------------------------------------------------- | | Tenant ID | Entra ID > Overview > Tenant ID | | Client ID | Entra ID > App registrations > your app > Application (client) ID | | Billing Account ID | Cost Management + Billing > Properties | | Subscription ID | Subscriptions > your subscription > Overview | | Storage Account | The storage account name you created | | Container | `north-exports` | | {% endstep %} | | | {% endstepper %} | | | {% endtab %} | | | {% endtabs %} | | ## What Gets Created in Your Azure Environment | Resource | Purpose | | ---------------------------------- | ---------------------------------------------------------------------- | | App Registration (Entra ID) | The identity North authenticates as. | | Federated Identity Credential | Lets North authenticate from its infrastructure with no stored secret. | | Storage Account and Blob Container | Holds the cost export files that Azure writes. | | RBAC Role Assignments | Give North read-only access to your billing data and your storage. | | Cost Management Exports | Write your cost data to that container every day, in Parquet format. | ## After You Connect Export data can take up to 24 hours to appear after onboarding completes. North analyzes your usage once that data arrives, and then shows your spend, your commitments, and your savings opportunities. ## Troubleshooting ### "ERROR: Could not find subscription" Check that the subscription name or ID is correct. Run `az account list --output table` to list the subscriptions available to you. ### Export creation fails You need the Billing Account Owner or Billing Account Contributor role on the billing account. Cost Management exports need billing-scope permissions. ### "Storage account name is taken globally" Azure storage account names must be globally unique. If the generated name is already taken, contact North support. ### New subscription, features not available A new subscription can take up to 48 hours before Cost Management features are fully available. If export creation fails on a recently created subscription, wait and try again. ### The script stops at "Confirming provider registration" The Cost Management Exports provider sometimes takes several minutes to register. Wait up to five minutes. If it still does not finish, check the registration status in the Azure Portal under Subscriptions > Resource providers. ## Removing the Integration North provides a cleanup script. Contact your North Customer Success Engineer for it. To remove the resources by hand: 1. Delete the Cost Management exports, under Azure Portal > Cost Management > Exports. 2. Delete the storage account, `northexports` in `north-billing-rg`. 3. Delete the resource group `north-billing-rg`, if you no longer need it. 4. Delete the App Registration from Entra ID > App registrations. It is named `north` by default. # Permissions required Permissions North.cloud requires from your cloud providers. North ensures minimal privilege permissions across all cloud providers, offering exceptional transparency over any other tool. For more information, contact us at . We also provide customized permissions based on individual requirements. # AWS permissions Permissions North.cloud requires from your AWS account. *** ## IAM Permission & Deployment North requires carefully scoped IAM permissions so our application can access cost and usage data required by our ML engine to provide automated FinOps recommendations. We purposefully limit all permissions to the minimum necessary for your financial analysis and do not request access to your workloads or sensitive application data. {% hint style="info" %} During onboarding, you have the **option** to add an **external ID** to the IAM roles assigned to your unique North root user. Using an external ID is an AWS security best practice. This externally supplied secret string helps ensure that only North’s authorized systems can assume the roles you configure. It is optional, but we encourage its use for additional protection. North will provide the required external ID value (if you choose to use it) securely during onboarding as part of our recommended implementation. If you add an external ID, it must match the value North holds for your account. If the two values differ, North's daily verification check fails, and your cost data pauses until they match. To get an external ID, ask your North Customer Success contact. {% endhint %} #### What North CAN NOT do: * Read sensitive data from your workloads or databases * View or edit network rules and security groups * Create, modify, stop, or terminate any compute instances or other machines * Change, copy, or export any development, test, or production data The following sections explain the IAM permissions required, why each group is needed. {% hint style="info" %} **Groups 1 to 3 are not a menu.** They describe what is inside a single CloudFormation stack. Whichever method you use to onboard, console, CLI, or Terraform, you deploy the same `north-all-features.yaml` template, and it carries all three groups together. The grouping below explains what that one stack grants and why, so you can review it before you deploy it. Group 4, Auto-Purchasing, is the exception. It is a separate role you deploy separately, and only if you want it. {% endhint %} *** ### Permission Groups Explained #### **1. Baseline (Default) – Read-Only Cost & Usage Data** **Purpose:**\ These permissions are required for North to read AWS billing, usage, and cost details, which underpin all FinOps analysis and recommendations. **Key Actions Explained:** * `ce:*`, `cur:*` – Read cost and usage reports from AWS (Cost Explorer, CUR). * `billing:*`, `account:GetAccountInformation` – Read account and billing details. * `ec2:DescribeCapacity*`, `rds:DescribeReserved*` – Read reserved/reserved instance fleet details for savings recommendations. * **Explicitly read-only:** No permission to change or stop resources. **Policy Example:** {% code overflow="wrap" %} ```json { "Version": "2012-10-17", "Statement": [ { "Action": [ "ce:Get*", "ce:Describe*", "ce:List*", "ce:Start*", "account:GetAccountInformation", "billing:Get*", "payments:List*", "payments:Get*", "tax:List*", "tax:Get*", "consolidatedbilling:Get*", "consolidatedbilling:List*", "invoicing:List*", "invoicing:Get*", "cur:Get*", "cur:Validate*", "freetier:Get*", "ec2:DescribeCapacity*", "ec2:DescribeReservedInstances*", "ec2:DescribeSpot*", "rds:DescribeReserved*", "rds:DescribeDBRecommendations", "rds:DescribeAccountAttributes", "ecs:DescribeCapacityProviders", "es:DescribeReserved*" ], "Resource": "*", "Effect": "Allow", "Sid": "NorthCostAndUsageReadOnlyPolicyID" } ] } ``` {% endcode %} *** #### **2. Premier Baseline – Compute Optimizer, CloudWatch & Service-Linked Roles** **Purpose:**\ These permissions let North read Compute Optimizer recommendations and CloudWatch metrics. North uses the Compute Optimizer recommendations for the savings figures in its alerts. Rightsize generates its own recommendations from your billing data, CloudWatch metrics, and AWS pricing. Rightsize reads CloudWatch metrics through `NorthCloudWatchCrossAccountAccessRole` and `NorthCloudWatchCrossAccountSharingRole`, described in [Advanced Permissions](#id-3.-advanced-permissions-cross-account-cross-region-cur-read-access-and-enhanced-real-time-metrics), below. **Why are IAM permissions (like `iam:CreateServiceLinkedRole`) included?** A common source of confusion is the need for IAM service-linked role permissions (such as `iam:CreateServiceLinkedRole`) for Compute Optimizer. Here's what you need to know: * **Compute Optimizer requires a service-linked role to function** (an AWS requirement). * The permission to create this role is used **only by AWS, internally within your account**, to allow Compute Optimizer to gather data. * **North does not use, access, or assume this role directly.** We only access Compute Optimizer's *readable* outputs, which stay within your AWS account. * Granting these permissions allows AWS to configure Compute Optimizer if not already done; many customers may already have this set up. **Key Actions Explained:** * `iam:CreateServiceLinkedRole`, `iam:PutRolePolicy`: Enable AWS to create and configure the required service-linked role for Compute Optimizer to report findings within your account only. * `compute-optimizer:*`: Read Compute Optimizer recommendations. North also calls `UpdateEnrollmentStatus` to enroll your organization in Compute Optimizer. That is the only Compute Optimizer action North calls that changes your account. * `cloudwatch:GetMetricStatistics`, `ecs:List*`, `lambda:ListFunctions`: Access aggregated metric and inventory data for analysis. **Policy Example:** ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Sid": "NorthPremiumPolicy1", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::*:role/aws-service-role/compute-optimizer.amazonaws.com/AWSServiceRoleForComputeOptimizer*", "Condition": { "StringLike": { "iam:AWSServiceName": "compute-optimizer.amazonaws.com" } } }, { "Effect": "Allow", "Sid": "NorthPremiumPolicy2", "Action": "iam:PutRolePolicy", "Resource": "arn:aws:iam::*:role/aws-service-role/compute-optimizer.amazonaws.com/AWSServiceRoleForComputeOptimizer" }, { "Effect": "Allow", "Sid": "NorthPremiumPolicy3", "Action": [ "compute-optimizer:*", "ec2:DescribeInstances", "ec2:DescribeVolumes", "ecs:List*", "autoscaling:DescribeAutoScalingGroups", "lambda:ListFunctions", "lambda:ListProvisionedConcurrencyConfigs", "organizations:ListAccounts", "cloudwatch:GetMetricStatistics", "rds:DescribeDBRecommendations", "rds:DescribeReservedDBInstances*" ], "Resource": "*" }, { "Effect": "Allow", "Sid": "NorthPremiumPolicy4", "Action": "organizations:EnableAWSServiceAccess", "Resource": "*", "Condition": { "StringEquals": { "organizations:ServicePrincipal": "compute-optimizer.amazonaws.com" } } } ] } ``` > **In summary:** North uses these permissions to enroll your organization in Compute Optimizer and to read its recommendations. The enrollment is the only Compute Optimizer write that North calls. To keep this role read-only, see [Removing Write Permissions from the Premium Role](/docs/getting-started/permissions-required/aws-permissions#removing-write-permissions-from-the-premium-role). *** #### **3. Advanced Permissions – Cross-Account, Cross-Region, CUR Read Access & Enhanced Real-Time Metrics** **Purpose:**\ These permissions are **required** (not optional) for customers who want access to North’s advanced FinOps and optimization features. They enable North to retrieve detailed Cost & Usage Report (CUR) data, which unlocks hour and resource-level cloud visibility, as well as, to ingest highly granular metrics from CloudWatch. This deeper and more real-time data access powers advanced analytics, fine-grained savings opportunities, and our most precise rightsizing and recommendation features. Without these advanced permissions, North cannot provide resource-level breakdowns, high-frequency cost analysis, or evaluate metrics on specific resource behaviors necessary for state-of-the-art optimization. **Why are these permissions necessary?** * **CUR (Cost & Usage Report) bucket read access** (`s3:GetObject`, `s3:ListBucket`): This is essential for North to ingest detailed, hourly, and resource-level usage data from your AWS-generated reports. These permissions give you the granularity you expect from modern cloud cost tooling and inform North's advanced dashboards and recommendation engine. * **CloudWatch cross-account metric and real-time data access** (`cloudwatch:GetMetricData`, `sts:AssumeRole`): These permissions allow North to access metrics across multiple AWS accounts and regions, but only for the specific metrics required for precise analysis and rightsizing. This supports real-time analytics and enables more accurate, actionable optimization suggestions—without granting unfettered access. * **S3 write-like actions (`s3:PutObject`)**: North will never write or configure anything unless programmatically authorized by your team (e.g., during setup of CUR, if needed), and always in accordance with the principle of least privilege. **Key Actions Explained:** * `sts:AssumeRole`: Enables North to securely access metric and cost data from linked accounts, supporting organizations with multi-account structures. When configuring cross-account access, you have the option to specify an external ID that North will supply during onboarding, further protecting your account from unauthorized role assumptions. * `cloudwatch:GetMetricData`: Enables retrieval of highly specific CloudWatch metrics for North’s analytics—strictly read-only and always scoped to the required metrics for insight and rightsizing. * `s3:GetObject`, `s3:ListBucket`: Required for North to read your AWS Cost & Usage Reports directly from S3, delivering granular, highly detailed usage data to your reporting dashboards. **Policy Examples:** These permissions sit on two roles and one bucket. Each role has a trust policy, which states who can use the role, and a permission policy, which states what the role can do. The Cost and Usage Report bucket has its own bucket policy. In each example, `` is the ID of the management account where you deploy the stack. **`NorthCloudWatchCrossAccountAccessRole` trust policy.** ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudwatch-crossaccount.amazonaws.com" }, "Action": "sts:AssumeRole" }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::480850768557:role/NorthCURReadOnly" }, "Action": "sts:AssumeRole" } ] } ``` **`NorthCloudWatchCrossAccountAccessRole` permission policy.** ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::*:role/NorthCloudWatchCrossAccountSharingRole" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::north-cur-bucket-", "arn:aws:s3:::north-cur-bucket-/*" ] } ] } ``` **`NorthCloudWatchCrossAccountSharingRole` trust policy.** The stack creates this role in your management account, and a StackSet creates it in each account in the organizational unit you select. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam:::root", "arn:aws:iam:::role/NorthCloudWatchCrossAccountAccessRole" ] }, "Action": "sts:AssumeRole" } ] } ``` **`NorthCloudWatchCrossAccountSharingRole` permission policy.** ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` **Cost and Usage Report bucket policy.** The first statement lets AWS deliver your reports to the bucket. The second lets `NorthCloudWatchCrossAccountAccessRole` read them. ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AWSBillingDeliveryPermissions", "Effect": "Allow", "Principal": { "Service": "billingreports.amazonaws.com" }, "Action": [ "s3:PutObject", "s3:GetBucketAcl", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::north-cur-bucket-", "arn:aws:s3:::north-cur-bucket-/*" ] }, { "Sid": "AllowCrossAccountAccess", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:::role/NorthCloudWatchCrossAccountAccessRole" }, "Action": [ "s3:GetObject", "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::north-cur-bucket-", "arn:aws:s3:::north-cur-bucket-/*" ] } ] } ``` > **In summary:** These advanced permissions are *required* to unlock North’s most powerful optimization algorithms, including resource-level and real-time recommendations. They are always used in a secure, read-only, and compliance-focused manner, never for broad resource access or uncontrolled data export. *** #### **4. Auto-Purchasing (Optional) – Buying Commitments in Your Own Account** **Purpose:**\ Everything above is read-only. It lets North recommend commitments. It does not let North buy them. Autobot needs a separate role, `NorthAutoPurchasingRole`, before it can purchase commitments directly in your own AWS account. This role is optional and separate from the onboarding stack. Grant it only if you want Autobot to purchase on your behalf. North verifies it separately, and a missing purchasing permission does not affect your account's overall verification status. **Trust policy.** The role trusts one named role inside North's account, not North's account root. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::480850768557:role/NorthAutoOrchestratorRole" }, "Action": "sts:AssumeRole" } ] } ``` {% hint style="info" %} **This role does not take an external ID**, and it does not need one. An external ID exists to remove ambiguity when a trust policy names a whole account as the principal. This trust policy names a single role, `NorthAutoOrchestratorRole`, so there is no ambiguity to remove. Do not add an `sts:ExternalId` condition to it. The external ID described at the top of this page applies to the cost and usage roles only. {% endhint %} **Permission policy.** Each statement pairs the read-only `Describe` actions North uses to price an offering with the single purchase action for that commitment type. {% code overflow="wrap" %} ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "SavingsPlans", "Effect": "Allow", "Action": [ "savingsplans:DescribeSavingsPlansOfferings", "savingsplans:DescribeSavingsPlansOfferingRates", "savingsplans:CreateSavingsPlan", "savingsplans:DeleteQueuedSavingsPlan", "savingsplans:DescribeSavingsPlans" ], "Resource": "*" }, { "Sid": "RDSReservedInstances", "Effect": "Allow", "Action": [ "rds:DescribeReservedDBInstancesOfferings", "rds:DescribeReservedDBInstances", "rds:PurchaseReservedDBInstancesOffering" ], "Resource": "*" }, { "Sid": "ElastiCacheReservedInstances", "Effect": "Allow", "Action": [ "elasticache:DescribeReservedCacheNodesOfferings", "elasticache:DescribeReservedCacheNodes", "elasticache:PurchaseReservedCacheNodesOffering" ], "Resource": "*" }, { "Sid": "MemoryDBReservedNodes", "Effect": "Allow", "Action": [ "memorydb:DescribeReservedNodesOfferings", "memorydb:PurchaseReservedNodesOffering" ], "Resource": "*" }, { "Sid": "RedshiftReservedNodes", "Effect": "Allow", "Action": [ "redshift:DescribeReservedNodeOfferings", "redshift:DescribeReservedNodes", "redshift:PurchaseReservedNodeOffering" ], "Resource": "*" }, { "Sid": "OpenSearchReservedInstances", "Effect": "Allow", "Action": [ "es:DescribeReservedInstanceOfferings", "es:DescribeReservedInstances", "es:PurchaseReservedInstanceOffering" ], "Resource": "*" }, { "Sid": "DynamoDBReservedCapacity", "Effect": "Allow", "Action": [ "dynamodb:DescribeReservedCapacityOfferings", "dynamodb:DescribeReservedCapacity", "dynamodb:PurchaseReservedCapacityOfferings" ], "Resource": "*" }, { "Sid": "EC2CapacityBlocksForML.OPTIONAL", "Effect": "Allow", "Action": [ "ec2:DescribeCapacityBlockOfferings", "ec2:PurchaseCapacityBlock" ], "Resource": "*" } ] } ``` {% endcode %} The OpenSearch statement uses the `es:` prefix. OpenSearch kept that IAM namespace after AWS introduced the newer API name, so `es:` is correct here. *** ### Supported Customizations Some organizations change the roles in `north-all-features.yaml` to meet their own security policies. The table lists the changes North supports for the cost and usage roles. For any other change, ask your North Customer Success contact before you deploy it. | Change | Supported | What to know | | ------------------------------------------------------------------------------------------------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Remove the `cloudwatch-crossaccount.amazonaws.com` trust statement from `NorthCloudWatchCrossAccountAccessRole` | Yes | Keep the statement that trusts `NorthCURReadOnly`. North uses that statement to read your Cost and Usage Reports. | | Add an `aws:ResourceOrgID` condition so that `NorthCloudWatchCrossAccountAccessRole` can assume sharing roles only in your organization | Yes | - | | Remove the `:root` principal from the `NorthCloudWatchCrossAccountSharingRole` trust policy, in your management account and in the StackSet | Yes | Keep `NorthCloudWatchCrossAccountAccessRole` as the trusted principal. North assumes the sharing roles only through that role. | | Remove the write permissions from `NorthCostAndUsageRolePremium` | Yes | Enroll in Compute Optimizer first. See [Removing Write Permissions from the Premium Role](/docs/getting-started/permissions-required/aws-permissions#removing-write-permissions-from-the-premium-role). | | Use a different name for the CUR bucket | Yes | Send the bucket name to your North Customer Success contact, and North configures your account with it. The default name, `north-cur-bucket-`, is preferred. | | Encrypt the CUR bucket with your own KMS key | No | Keep the default SSE-S3 encryption (`AES256`). If North cannot decrypt your reports, your cost data stops arriving. | | Trust named North roles in `NorthCostAndUsageRole` and `NorthCostAndUsageRolePremium` | No | Keep North's account root as the principal, with an external ID if you use one. The North roles that assume these roles change as North releases new features. | | Deploy `NorthCostAndUsageRolePremium` in a member account, such as a Compute Optimizer delegated administrator | No | Deploy it in your management account, with the rest of the stack. | #### Removing Write Permissions from the Premium Role `NorthCostAndUsageRolePremium` includes permissions that enroll your organization in Compute Optimizer. After your organization is enrolled, you can remove them and keep a read-only role. Do these steps in this order. If you remove the permissions before you enroll, the enrollment does not happen, and North reports Compute Optimizer data for your management account only. 1. Enroll your organization in Compute Optimizer, with member accounts included. 2. Turn on trusted access for Compute Optimizer in AWS Organizations. 3. Remove `iam:CreateServiceLinkedRole`, `iam:PutRolePolicy`, and `organizations:EnableAWSServiceAccess` from the role. 4. Replace `compute-optimizer:*` with `compute-optimizer:Get*`. Keep the read-only `Describe` and `List` actions and `organizations:ListAccounts` in the role. AWS enrolls member accounts that you add to your organization later. *** ### Important Security Best Practices * **Always review permissions and restrict to least-privilege required for your use case and feature set.** * Avoid granting broad, unnecessary permissions such as `"ec2:Describe*"` to any third party—including North. * If you have questions on what each permission is used for, please contact our support team for a granular explanation. * If you want additional protection, you may use an external ID in your trust relationship when granting North cross-account role access. By adhering to these permission designs, you retain control and visibility into what North can access, and ensure your AWS environment stays secure and optimized. *** {% hint style="info" %} **Note:** Any required North account ID, role ARNs, and (optionally) external IDs can and will be provided securely to you by North during onboarding. {% endhint %} # GCP permissions Permissions North.cloud requires from your GCP account. ## GCP IAM Permissions & Deployment North requires carefully scoped GCP permissions so our application can access billing and usage data required by our ML engine to provide automated FinOps recommendations. We purposefully limit all permissions to the minimum necessary for your financial analysis and do not request access to your workloads or sensitive application data. GCP uses Workload Identity Federation and BigQuery dataset sharing to provide secure, fine-grained access to only your billing data—no North service account keys required. *** ### What North CAN NOT do * Read sensitive data from your workloads or databases * View or edit network rules and security groups * Create, modify, stop, or terminate any compute instances or other machines * Change, copy, or export any development, test, or production data * Access any data outside of the billing dataset you explicitly share, and the utilization metrics you grant for Rightsize * Modify your GCP resources or configurations The following sections explain the IAM permissions required and why each permission group is needed. *** ### Permission Groups Explained #### 1. Baseline (Default) – Read-Only Billing Data via BigQuery **Purpose:**\ These permissions allow North to read GCP billing, usage, and cost details from your BigQuery billing export. These are required for all FinOps analysis and recommendations. **Key Roles Explained:** * `roles/bigquery.dataViewer` (BigQuery Data Viewer):\ Allows North to read data from tables in your billing dataset. Enables querying cost and usage tables for cost analysis. * **Read-only**: No permission to change, delete, or export data. * No access to data outside the shared dataset. * `roles/bigquery.metadataViewer` (BigQuery Metadata Viewer):\ Allows North to view metadata (like table structure and schema) about your billing dataset, and list billing export tables. * **Read-only**: Cannot modify table metadata or datasets. * Cannot see metadata for datasets you do not share. **How Access Works:** North uses GCP **Workload Identity Federation** to securely assume access to the shared dataset, without requiring service account keys. To grant North access, you assign both roles above to the workload identity principal provided by North during onboarding. This principal follows a standard, auditable format and ensures that only North’s authorized system can access your shared data. {% hint style="info" %} **Minimum Required Role for sharing billing dataset:**\ To share your billing dataset, you need the **BigQuery Data Owner** (`roles/bigquery.dataOwner`) role in your account. {% endhint %} #### 2. Auto-Purchasing (Optional) – Buying Commitments in Your Own Account **Purpose:**\ The baseline roles above let North read your billing data and recommend commitments. They do not let North buy anything. Autobot needs a separate set of roles before it can purchase commitments directly in your own Google Cloud account. These roles are optional. Grant them only if you want Autobot to purchase on your behalf. North verifies them separately from the baseline roles, and a missing purchasing role does not affect your account's overall verification status. **Key Roles Explained:** Google Cloud splits committed use discounts across three mechanisms. Each one operates at a different scope, so each role is granted at the scope its mechanism actually works at. | Role | What it lets Autobot buy | Grant it at | | -------------------------------------- | -------------------------------------- | ----------------------------------------- | | `roles/compute.admin` | Resource-based CUDs for Compute Engine | Your organization | | `roles/bigquery.resourceAdmin` | BigQuery capacity commitments | Your designated reservation admin project | | `roles/consumerprocurement.orderAdmin` | Spend-based CUDs and Flexible CUDs | Your billing account | North grants these to the **same principal** the baseline flow already uses. No second principal is created. Only the roles bound to it differ. Notes on the scopes, because they are not interchangeable: * **`roles/compute.admin` is bound at the organization**, not per project. One grant then covers every project under it, including projects you add later. A per-project grant leaves any new project uncovered until onboarding runs again. * **`roles/bigquery.resourceAdmin` is bound on one project only.** Capacity commitments live on the single admin project you designate for reservations. Confirm that the project you name really is that admin project. Do not grant this role at the organization level, because that would give every project in the organization reservation-admin rights it does not need. * **`roles/consumerprocurement.orderAdmin` is bound on the billing account.** Consumer Procurement orders are billing-account-scoped, so there is no organization-level equivalent. One grant covers every project linked to that billing account. North asks for this role rather than `roles/billing.admin`, which is a much broader grant this feature does not need. #### 3. Rightsize (Optional) - Reading Utilization Metrics **Purpose:**\ Rightsize reads utilization metrics from Cloud Monitoring to size your Compute Engine instances. Without this role, North still lists your resources, but Rightsize cannot size them. Everything else in North keeps working. **Key Role Explained:** * `roles/monitoring.viewer` (Monitoring Viewer):\ Allows North to read utilization metrics from Cloud Monitoring. * **Read-only**: Limited to utilization metrics. **How Access Works:** Grant the role on your billing project to the **same principal** that reads your billing export. No second principal is created. Then add every project you want Rightsize to analyze to your billing project's metric scope. A project outside the metric scope is not analyzed. For the steps, see [Compute Engine](/docs/features/rightsize/compute-engine). *** ### Security Model **Workload Identity Federation:** * No service account keys required. Credentials are time-limited, rotated, and cannot be reused. * North can only access the specific dataset you share, and the utilization metrics you grant, and only with roles you choose. * Access is logged in GCP Cloud Audit Logs, providing full traceability. * The principal includes an attribute (`attribute.aws_role/NorthGCPReadOnlyRole`) to ensure only North’s authorized systems can assume the role. **Data Isolation:** * North only has access to the billing dataset you explicitly share, and to utilization metrics if you grant Monitoring Viewer * Access is always read-only—North cannot modify or delete your data * North cannot access any other datasets or resources # Azure permissions Permissions North.cloud requires from your Azure account. ## Azure IAM Permissions and Deployment North requires carefully scoped Azure permissions so our application can read the billing and usage data our ML engine needs to produce automated FinOps recommendations. We limit every permission to the minimum needed for your financial analysis. We do not request access to your workloads or to your application data. Azure uses Workload Identity Federation to give North secure, fine-grained access. No North service account keys and no client secrets are created in your tenant. *** ### What North CAN NOT do * Read the contents of any resource. This covers database rows, Key Vault secret values, log records, and blob data outside the `north-exports` container. * Create, modify, or delete any Azure resource. * Access keys, secrets, passwords, or any other credential in your environment. * Run Log Analytics queries. That needs the Log Analytics Reader role, which North is not granted. * Make purchases, modify subscriptions, or change billing settings, unless you grant the optional purchasing roles below. ### What North CAN do * Read the cost export Parquet files in the `north-exports` container. * Query aggregated cost data through the Cost Management API, read-only. * Read your reservation and savings plan details, for commitment coverage and utilization analytics. * Read the configuration and metadata of resources across your tenant, and their metrics through Azure Monitor. North uses this for compute right-sizing. The following sections explain the roles North receives and why each one is needed. *** ### Permission Groups Explained North receives five RBAC role assignments. Every one of them is read-only. | Role | Scope | What it grants | | ------------------------ | ---------------------------------- | ------------------------------------------------------------------------------------------------- | | Storage Blob Data Reader | The `north-exports` container only | `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read` | | Cost Management Reader | Billing account | `Microsoft.CostManagement/*/read`, `Microsoft.Billing/*/read` | | Reservations Reader | Microsoft.Capacity provider | `Microsoft.Capacity/reservationOrders/read`, `Microsoft.Capacity/reservations/read` | | Savings Plan Reader | Microsoft.BillingBenefits provider | `Microsoft.BillingBenefits/savingsPlanOrders/read`, `Microsoft.BillingBenefits/savingsPlans/read` | | Reader | Tenant-root management group | `*/read`. See below. | #### 1. Billing data Storage Blob Data Reader lets North read your export files from the dedicated container. North cannot reach any other container and cannot reach any other storage account. Cost Management Reader lets North query cost data through the Cost Management API. It cannot create, modify, or delete anything. #### 2. Commitment data Reservations Reader and Savings Plan Reader let North read the details of the reservations and savings plans you hold. North needs both to report commitment coverage and utilization. {% hint style="info" %} If either grant is missing, onboarding still completes. North cannot read your commitment inventory in that case, so coverage and utilization figures on the Commitments page will be incomplete. {% endhint %} #### 3. Right-sizing data Reader is the one grant that is not narrowed to a single provider. It grants `*/read`: read access to the configuration and metadata of every resource in the tenant, plus resource metrics through Azure Monitor. North uses it to size and right-size your compute. It reads Virtual Machine and Virtual Machine Scale Set inventory through Azure Resource Graph, and CPU, network, and disk metrics through Azure Monitor. Reader is assigned at the tenant-root management group because Azure RBAC inherits downward. One assignment therefore covers every subscription in your billing account, and North never has to enumerate them. Reader carries no `dataActions`, so it cannot read the contents of anything. It grants no write access, no delete access, and no configuration access of any kind. North asks for Reader rather than Azure's built-in Monitoring Reader role. Monitoring Reader covers the same reads and adds `Microsoft.Support/*`, which includes `Microsoft.Support/supportTickets/write`, the ability to open support tickets in your tenant. North does not need that, so North asks for the smaller role. #### 4. Auto-Purchasing (Optional) **– Buying Commitments in Your Own Account** The five roles above are read-only. They let North recommend commitments. They do not let North buy anything. Autobot needs two more roles before it can purchase commitments directly in your own Azure subscription. These roles are optional. Grant them only if you want Autobot to purchase on your behalf. North verifies them separately, and a missing purchasing role does not affect your account's overall verification status. | Role | What it lets Autobot buy | | ---------------------- | ------------------------ | | Reservation Purchaser | Azure reservations | | Savings plan Purchaser | Azure savings plans | Assign both to the **same App Registration** you created for cost and usage onboarding. No second app registration and no second federated credential are needed. {% hint style="warning" %} **Assign both roles at the subscription scope**, `/subscriptions/`. A tenant-root assignment does not work. These built-in roles grant `roleAssignments/read` at their own scope only, not at the tenant root above it, so a tenant-root grant fails with `AuthorizationFailed` even when the roles look correctly assigned. {% endhint %} *** ### Permissions Used During Onboarding The list below covers every Azure action the onboarding performs. Grant these if your organization uses custom roles instead of the built-in roles. **Entra ID: App Registration and Workload Identity Federation** | Permission | Action | | --------------------------- | ----------------------------------------------------- | | Create App Registration | `microsoft.directory/applications/create` | | Read App Registration | `microsoft.directory/applications/read` | | Read Service Principal | `microsoft.directory/servicePrincipals/read` | | Create Service Principal | `microsoft.directory/servicePrincipals/create` | | Create Federated Credential | `microsoft.directory/applications/credentials/update` | | List Federated Credentials | `microsoft.directory/applications/credentials/read` | **Subscription: resource group, storage, and provider registration** | Permission | Action | | ------------------------------- | ----------------------------------------------------------------- | | Register resource provider | `Microsoft.Resources/subscriptions/providers/register/action` | | Check provider registration | `Microsoft.Resources/subscriptions/providers/read` | | Create resource group | `Microsoft.Resources/subscriptions/resourceGroups/write` | | Create storage account | `Microsoft.Storage/storageAccounts/write` | | Read storage account | `Microsoft.Storage/storageAccounts/read` | | Check storage name availability | `Microsoft.Storage/checkNameAvailability/read` | | Create blob container | `Microsoft.Storage/storageAccounts/blobServices/containers/write` | | Check blob container existence | `Microsoft.Storage/storageAccounts/blobServices/containers/read` | **RBAC: role assignments** | Permission | Action | | ------------ | ----------------------------------------------- | | Assign roles | `Microsoft.Authorization/roleAssignments/write` | **Billing: Cost Management exports** | Permission | Action | | ------------------------- | ---------------------------------------- | | Create and update exports | `Microsoft.CostManagement/exports/write` | Azure Onboarding lists which roles the person running the onboarding needs, and at which scope. *** ### Security Model North uses Workload Identity Federation to authenticate. * **No stored secrets.** There is no client secret and no certificate, so there is nothing to rotate, leak, or expire. * **Short-lived tokens.** Access tokens are valid for one hour and are obtained on demand. * **Scoped access.** Each token is minted for a single audience. That is either Azure Blob Storage, to read the export files, or Azure Resource Manager, for the read-only metadata, commitment, and metric queries above. * **Auditable.** Every authentication event appears in your Entra ID sign-in logs. * **Revocable.** Delete the App Registration or the Federated Credential to revoke all access immediately. **Data isolation** * North reads blob data from the `north-exports` container only. * Access is always read-only, unless you grant the optional purchasing roles. North cannot modify or delete your data. # Security At North.cloud, security is fundamental to everything we do. Our approach is multi-layered, with clear delineation of security responsibilities and controls at every level of our service. *** ### Security Levels & Best Practices **Platform and Architecture Security** * **Dedicated Environments:** Our AWS-based infrastructure is strictly segregated into separate environments for development, testing, and production. This ensures changes and experiments in non-production environments can never impact production or customer data. * **Least Privilege Permissions:** All IAM roles and policies are locked down using the minimum privileges required. No permission is ever granted unless it is strictly necessary for North to operate our service. * **Internal Security Audits:** Every significant new feature or architectural update undergoes internal security review to identify and address risks at design and implementation time. * **External Security Testing:** North contracts third-party SecOps professionals for regular penetration testing, including both black-box and gray-hat audits, to probe and validate the security of our production system. * **Comprehensive Logging & Auditing:** Every environment is continuously logged and monitored. Audit logs for all customer environments are maintained and can be made available for review by customers on request. * **SOC 2 Type II Compliance:** As of June 2026, North holds a SOC 2 Type II report. Full details of our compliance, including audit reports, are available to customers with a signed NDA. Reach out to our security team to request them. *** ### Customer Data Segregation & Controls **Strict Account Isolation & Data Segregation** * **One Billing Account per North Account:** North enforces a policy of one cloud provider billing account ID per North.cloud account. This strict separation makes it impossible for cross-customer data access or account impersonation within our platform. * **Root User Controls:** Within each customer organization, we allow only one root North user per company domain. This increases control and minimizes the surface area for insider risk or account misuse. * **No Data Leakage:** There is no mechanism for data to transfer or be accessed between North.cloud accounts. Customer workloads, savings plans, and reporting are all strictly isolated. * **Request Security Info:** Need more information? We provide detailed documentation and audit trails on a per-request basis for customers (subject to appropriate NDAs). # Managed Savings Pods Learn about the security controls put in place on the Savings Pods that allow our customers to benefit from flexible savings across multiple providers. Every North AWS member account is physically isolated from all other member accounts, ensuring strict customer-to-customer data separation at the infrastructure level. Each member account is protected by four distinct layers of security controls, including dedicated logging and auditing tailored for that account. These accounts are monitored continuously for anomalous or extraneous costs that may indicate unexpected behavior. North employs a Control Tower framework to quickly investigate any issues at the account level and, if necessary, can proactively detach and isolate the affected account from your organization to prevent broader risk. Additionally, customers retain complete authority over their AWS Organization—at any time, you can immediately remove North’s account or any Savings Pod from your Organization. This action instantly revokes all access and ensures you are always in control, especially in emergency situations. *** #### Why member accounts? **North Member Accounts: Maximizing Customer Security & Autonomy** North deploys member accounts within your AWS Organization specifically to manage Savings Plans and Reserved Instances on your behalf. This architecture is designed with customer sovereignty and security as a top priority: * **You Own the Billing Account & Organization:** North never takes over your AWS billing account or Organization. You always retain full administrative control and ownership. * **No Exposure to External SCPs (Service Control Policies):**\ North member accounts operate within your Organization but never impose or inherit any Service Control Policies (SCPs) from North, its sub-processors, or other third parties. You are not subject to security policies set by North, its staff, or any outside administrators, your Organization’s security and compliance boundaries remain fully and solely under your control. * **Minimized 3rd Party Risk:**\ By never transferring your root billing account or Organization control to a reseller or external party, you avoid risks associated with potential 3rd party security events or compromises affecting SCP administration. We highly discourage companies from doing so. * **Full Disconnect at Any Time:**\ At any moment, you can remove North’s member accounts from your Organization through native AWS controls. This instantly disconnects North’s access and halts any service operation across your organization—giving you rapid, autonomous control for security, compliance, or business needs. * **Customer-First Approach:**\ North’s model means you are never locked in or made dependent on a North-controlled environment. All privileges remain with your administrators at all times. This structure ensures your AWS Organization stands independent, secure, and insulated from any external policy risk while benefiting fully from North’s FinOps automation and optimization capabilities.

Example of North Savings Pod Joining a Customer Billing Organization.

*** ### Frequently Asked Questions **Q: What access do North Savings Pods have in our AWS Organization?**\ A: None. Each pod only has read-only billing permissions for its own account, allowing North to monitor savings and usage. Pods *cannot* access any other accounts or resources in your AWS Organization. **Q: How are Savings Pods secured?**\ A: Each pod is protected at root with password encryption and MFA. No extra IAM permissions exist, ensuring no unintended access. Activity and spend are strictly monitored—pods act as “dark sites” used only for managing commitments. **Q: What happens to pod costs if a pod leaves our Organization?**\ A: Any North account leaving your org will default to its own AWS payment method for billing. This is AWS standard behavior. More info: [AWS account removal docs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_remove.html) # SSO Learn about SSO that North.cloud supports. {% hint style="info" %} North.cloud is planning on supporting Okta and Auth0 in the near future. For any SSO requirements and blockers, please reach out to with feedback. {% endhint %} North supports Single Sign-On (SSO) for secure and simple access to your account. You can sign in using: * **Google** * **Microsoft** * **GitHub** To use SSO, just select your preferred provider from the login page. If your organization requires a particular method, follow their SSO policy. If you need to link multiple accounts or experience any issues with SSO, please contact # MFA Learn more about how to enable MFA. Multi-Factor Authentication (MFA) adds a second check to your North sign in. North supports two methods: an authenticator app, and a code sent by SMS. ## Enable MFA 1. Go to [app.north.cloud/settings](https://app.north.cloud/settings) and open the **Security** tab. 2. Find the **Multi-Factor Authentication** section. 3. Choose **Authenticator App** or **SMS**. 4. For an authenticator app, scan the QR code with your app, then enter the six-digit code it shows. If you cannot scan the code, use the setup key below it. 5. For SMS, enter your phone number, click **Send code**, then enter the code you receive. {% hint style="info" %} Your email address must be verified before you can enroll. If it is not, the Security tab offers to send you a verification email. Click the link in that email, then click refresh on the same panel. {% endhint %} ## Require MFA for Your Team The root user of your organization can make MFA mandatory. Enroll first, then set the **Require MFA for all team members** toggle in the same section. Team members who are not enrolled are asked to enroll at their next sign in. ## Remove MFA In the **Multi-Factor Authentication** section, click the remove control and confirm. North signs you out when the removal completes, so you must sign in again. # AI Use & Security Learn more about the security put in place around Noros, our customers' cloud FinOps assistant. ## Noros Security & Privacy ### Overview At North.cloud, we understand that security and data privacy are paramount when integrating AI agents into your cloud infrastructure. This document outlines our security practices for Noros, demonstrating our commitment to protecting your sensitive cloud data. *** ### Core Security Principles #### Your Data is Never Used for AI Training **We do not train or perform inference on any LLMs, open source or proprietary - using customer data.** * Customer data is strictly off-limits for model training purposes * Your cloud infrastructure data, billing information, and usage patterns remain completely private * We never share, sell, or use your data to improve third-party AI models #### Complete Data Isolation Your data never leaves our secure AWS environment: * **VPN-Protected Infrastructure**: All customer data remains within our Virtual Private Cloud (VPC) inside AWS * **Secure AI processing**: Noros uses foundational AI models hosted within secure cloud infrastructure. Your data is never used for model training. * **Zero External Transmission**: Customer data is never sent to third-party APIs or to cloud services outside our controlled environment *** ### Data Separation & Access Control #### Physical Data Segregation Each Noros deployment is physically isolated from other customers: * **Dedicated Resources**: Every customer's Noros environment operates in a completely separate environment * **No Cross-Customer Access**: Technical architecture prevents any possibility of data leakage between customers * **Isolated Storage**: Customer data is stored in dedicated, encrypted databases with strict access boundaries #### OAuth-Level Authentication We implement industry-standard OAuth 2.0 authentication at the agent level: * **Credential-Based Access**: Noros can only retrieve data that corresponds to your specific login credentials * **Principle of Least Privilege**: Noros has access only to the resources explicitly authorized by your account * **Session Management**: Secure token-based authentication ensures that only authenticated users can interact with Noros *** ### Conversation Storage & Transparency #### Why We Store Conversations To provide you with the best possible experience, we store customer conversations with Noros. This enables: * **Improved Response Quality**: Learning from interaction patterns helps us refine responses * **Enhanced Context Awareness**: Maintaining conversation history allows for more intelligent, contextual assistance * **Better LLM Effectiveness**: Understanding how customers use Noros helps us optimize prompt engineering and response relevance **Important**: Stored conversations are never used to train foundational LLMs only to improve our prompting strategies and response frameworks. #### Your Control Over Data Storage We believe in giving you complete control: * **Opt-Out Available**: If you prefer not to have conversations stored, we can disable this feature for your account * **Data Deletion**: You can request deletion of stored conversation data at any time * **Transparency**: We're happy to discuss exactly what data is stored and how it's used To disable conversation storage or request data deletion, please contact our support team at or through your account. *** ### Compliance & Standards #### Industry Best Practices Noros is built on enterprise-grade security standards: * **Encryption at Rest**: All stored data is encrypted using AES-256 encryption * **Encryption in Transit**: TLS 1.3 for all data transmission * **Regular Security Audits**: Continuous monitoring and third-party security assessments * **Access Logging**: Comprehensive audit trails of all data access and agent activities *** ### Frequently Asked Questions #### Q: Can other North.cloud customers see my data? **A: No.** Each customer's Noros environment is physically separated from other customers. Technical safeguards make cross-customer data access impossible. #### Q: What happens if I delete my account? A: All customer data, including stored conversations, is permanently deleted according to our data retention policy. You can also request immediate deletion at any time. #### Q: What access does Noros have? A: Noros has the same access as our traditional application. #### Q: Do you comply with GDPR, CCPA, and other privacy regulations? A: Yes. Our data practices are designed to comply with major privacy regulations including GDPR and SOC 2 requirements. *** ### Commitment to Transparency Security isn't just about technology—it's about trust. We're committed to: * **Clear Communication**: We'll always be transparent about how we handle your data * **Regular Updates**: This documentation is updated as our practices evolve * **Responsive Support**: Questions about security? Our team is here to help # Recommended Best Practices These are additional steps that we have seen some of our more security forward customers follow. * **Use Service Control Policies (SCPs):**\ SCPs let you set permission guardrails for all (or a subset of) accounts in your AWS Organization. For your Savings Pods, set an SCP that explicitly *denies* all actions except those required for cost and usage reporting. This helps enforce “read-only” and blocks creation/modification of workloads or network changes in the pod accounts. [Read more about SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). * **Monitor Pod Activity Regularly:**\ North.cloud continuously self-monitors all savings pods for unauthorized actions or unexpected spend spikes. You can review this monitoring data directly in your North.cloud app for additional transparency and auditing. * **Review Audit Logs:**\ Enable CloudTrail or AWS account activity monitoring to view all actions performed within your organization. Regularly review for unexpected changes or access patterns. Following these practices, along with North's built-in monitoring and least-permissive configuration, maximizes your security and control. # Coverage Learn how North covers your cloud spend with commitments, and how North carries the commitment term and the risk on your behalf. North's Coverage is the commitment management engine for AWS, Google Cloud, and Azure. It works out how much of your cloud spend is worth covering with a commitment, and then covers it. You get the savings that a long commitment earns, without the exposure that a long commitment usually carries. North covers your spend two ways. North calls them Flexbot and Autobot. Run either one on its own, or set what share of your coverage runs on each. ## Flexbot Flexbot is coverage that North holds for you. North buys the commitment in its own accounts, and the discount reaches your account. With Flexbot, you are never on the hook for a long-term cloud commitment. North assumes the full commitment term and the risks that come with it. Your needs can scale up or down. You do not have to worry about inflexible contracts, or about being stuck with unused commitments. Traditional models expose customers to penalty fees, sunk costs, and rigid timeframes. Flexbot gives you flexibility instead. If your usage drops, or your business conditions change, North resizes your commitments. You pay for what you actually use. The flexibility works both ways: * **Downsizing.** If your needs decrease, North can retrieve or reduce commitment quantities. The average retrieval time is seven days, and the best case is same day. * **Upsizing.** If your usage increases, North adds new commitments without a procurement cycle. The risk and the operational overhead stay with North. You do not get stuck with commitments you no longer need, and you do not pay for resources you no longer use. {% hint style="info" %} **Note:**\ Retrieval times and flexibility depend on your volume and on the terms of your North Master Services Agreement (MSA). All aspects of commitment insurance and flexibility are subject to the terms in the [MSA](https://north.cloud/terms-of-service). {% endhint %} ## Autobot Autobot buys commitments directly in your own account. You own them, and they sit in your billing organization like any commitment you bought yourself. Autobot does not buy your whole target at once. It commits a share in the first month, then adds to that position month over month, until it reaches the coverage you asked for. Autobot acts within the permissions you grant it. Until you grant them, North recommends and does not purchase. ## How North Manages Risk Every commitment carries the same underlying risk. You commit for a term, and your usage moves. North manages that risk differently for each mechanism, because Flexbot commitments sit in North's accounts and Autobot commitments sit in yours. ### Flexbot Flexbot manages risk through two models. **Managed by North.cloud.** North aggregates and orchestrates commitments across its own accounts. If a commitment becomes underutilized, North can reallocate it, or remove it from your billing organization entirely. You reach high coverage rates without the usual lock-in. **Insured by North.cloud.** For selected commitments, North covers underutilization directly. If your usage falls below the commitment, even to zero, North covers the shortfall. North provides credits or cash back against your North invoice or fees. Up to 100% of monthly commitment costs are protected, whatever your utilization does. ### Autobot Autobot holds commitments in your own account, so North manages the risk by controlling what gets bought and when. It works two ways. **Building the position in steps.** Your exposure grows only as your coverage grows. You are never committed to your whole target on day one. **Sizing every step against current usage.** Your target is a share of your spend, so when your spend falls, the amount needed to reach that target falls too. The next step is smaller. In a month where your coverage already meets your target, Autobot buys nothing. ## How North Decides What to Buy North reads your cloud usage, your commitment history, and your projected growth. It generates a new set of recommendations every month. Each month's recommendations take account of how your usage has changed since the last set. They decide what North buys for you that month. What happens to a recommendation depends on which mechanism holds the coverage: * For your Autobot share, North purchases the commitment automatically, within the permissions you granted. * For your Flexbot share, North creates a task for your Customer Success Engineer. Your CSE works with you to attach North's Savings Pods to your account. The discount reaches you once those pods are in place. ## Where to Go Next Use these guides to configure coverage, purchase commitments, and track your savings: {% content-ref url="/pages/x83trPlFR1VQIrj9bvnE" %} [Getting Started](/docs/features/coverage/getting-started) {% endcontent-ref %} {% content-ref url="/pages/ZNcol773ZdD9zSkCxRo2" %} [Commitments](/docs/features/coverage/commitments) {% endcontent-ref %} {% content-ref url="/pages/FDXEhnrYjIu3VeMTjUJa" %} [Purchasing Coverage](/docs/features/coverage/purchasing-coverage) {% endcontent-ref %} {% content-ref url="/pages/C9RmMAcuWMbTYOCEyJzp" %} [Coverage Plans](/docs/features/coverage/coverage-plans) {% endcontent-ref %} # Getting Started Learn how to view your commitments health, your coverage options, and what happens after you buy coverage with North. ## Before You Start * North analyzes your usage every day and projects the savings available on each of your services. Review them on your homepage under **Available Savings**. For the detail per plan, open the [Commitments](https://app.north.cloud/commitments) page. * Check [Coverage Plans](/docs/features/coverage/coverage-plans) to confirm that the services you want to cover are supported. That page also shows whether each plan is available through Flexbot, Autobot, or both. * If you have just onboarded onto North, note that it can take a few hours before your usage and coverage data starts showing up on the Commitments page. ## View your Commitments The Commitments page is your control center for all things related to coverage. It shows your current commitments, the health of those commitments, any commitments that are queued to be purchased, and analytics tied to your coverage. 1. On the Commitments page, select the service for which you want to see your usage and coverage data. 2. On the 'Current Coverage and Projection' section, you can see your spend and coverage charts across various time ranges. Switch between simple and inventory views to see different visualizations of your data. 3. See a list of your current commitments and their health on the 'Commitments Health' section. This includes both commitments held by you as well as North. The list is filterable by date ranges, commitment type, region, whether it is held by North or not, and whether it is underperforming. 4. View any pending and forecasted commitments in the 'Pending & Forecasted' section. This is where you can see any purchases that are queued once you buy coverage through North. 5. See high-level metrics about your coverage in the Analytics section. The [Commitments](/docs/features/coverage/commitments) guide covers each section in detail, including explaining all the metrics listed on this page. ## Turn On Coverage 1. On the Commitments page, click **Adjust Coverage**. 2. Set your coverage target, and set your Auto / Flex split. 3. Select a coverage profile for the Autobot share. 4. Review the simulation's results. 5. Click **Update Policy**, then authorize the configuration. [Purchasing Coverage](/docs/features/coverage/purchasing-coverage) covers every step in detail. It also lists the permissions Autobot needs before it can purchase for you. ## Frequently Asked Questions ### How Are Savings Pods Removed From My Environment? Savings Pods are the North-managed accounts you add when Flexbot covers part of your spend. North removes them automatically. North can also remove them at your request. You keep full control over these accounts, and you can remove them whenever you need to. The Master Services Agreement applies for non-emergency events. ### Is There Any Concern With Adding North's Accounts to My Environment? No. Savings Pods are North-managed accounts that distribute commitment discounts into your account. [Managed Savings Pods](/docs/getting-started/security/managed-savings-pods) describes the security controls North puts in place. # Purchasing Coverage Learn how North measures coverage, and how to buy more of it through a policy or a one-time purchase. Everything here happens in the coverage simulation. Open it from the Commitments page. Click **Adjust Coverage**. ## How Coverage Is Measured Every percentage in the simulation is a share of your on-demand equivalent spend for one plan. On-demand equivalent is what your usage would cost at list price, with no commitment applied. This gives every figure on the page the same denominator. North sets a **recommended maximum** for each plan. This is the highest coverage that still adds savings. Above it, more coverage costs more than it returns. North calculates the recommended maximum from your own usage, over a window sized to that plan's own spend pattern rather than a fixed number of days. North recalculates the maximum every month. Your coverage target is set as a share of the recommended maximum. If North's recommendation changes, your target moves with it. ## Ways to Buy Coverage There are three ways to buy coverage. You can use any of them, and you can use all three. * **A coverage policy.** You set a target once. North generates recommendations every month and buys against that policy. * **A Flex purchase to cover a shortfall.** You buy the gap between what you already hold and your policy target, as a single purchase. * **A Flex purchase above your target.** You buy part of the spend you left outside your policy, up to the recommended maximum. The last two are one-time purchases. Neither changes your ongoing policy. If you prefer not to run a policy at all, you can keep buying Flex one purchase at a time. ## Metrics The simulation shows four metrics. Use them to compare one configuration against another before you commit to it. ESR and Savings/mo show a simulated figure beside your current figure, so you can read the change. | Metric | Meaning | | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **ESR** | The single best way to judge your commitments' health. It is your blended discount across committed and on-demand spend. North calculates it after any Enterprise Discount Plan (EDP) or other negotiated pricing. If you have negotiated pricing with your cloud provider, ESR reflects your savings measured against that negotiated rate. | | **Savings/mo** | Combined Autobot and Flexbot savings per month, at this configuration. | | **Flex Score** | The flexibility of this configuration's term mix, from 0 to 10. A higher score is more flexible. | | **Time to Peak** | The number of months before coverage stops climbing. A configuration already at its peak reads "At peak". | ## Autobot and Flexbot Autobot and Flexbot are the two mechanisms North uses to cover your spend. Autobot buys commitments in your own account, and you own them. Flexbot is coverage North holds for you in its own accounts. The [Coverage](/docs/features/coverage) guide explains both in full, including how North manages the risk for each. Three drawers sit below the policy controls in the simulation view of the Commitments page. Each one covers a different band of your spend. | Drawer | Covers | Held by | Managed by | | ------------- | ---------------------------------------------------------------------- | ------- | ---------- | | **Autobot** | From the coverage you already own, up to the Auto share of your target | You | North | | **Flexbot** | From the Auto share of your target, up to your total coverage target | North | North | | **On Demand** | From your total coverage target, up to the recommended maximum | North | North | Spend above the recommended maximum stays uncovered. Covering it costs more than it saves. The **Auto / Flex** control divides your target between the first two. It sets which of the two holds the commitment. It does not change how much coverage you end up with, but it can change how quickly you get there: Autobot builds up gradually, while Flexbot can fill its share at once. {% hint style="info" %} **Note:** Flex is available on Compute, Database and SageMaker Savings Plans only. {% endhint %} ## Coverage Profiles A coverage profile controls how Autobot builds its share. It does not change your target. Each profile sets three things: * **Base**, the share committed in the first month. * **Ladder**, the share added month over month after the first. * **Term mix**, the split between one-year and three-year commitment terms. Profiles differ in pace and in how much they commit in the first month. A slower profile commits less at the start and keeps more room to change course. A faster profile commits more at the start and reaches your target sooner. North maintains the set of profiles. You select the one you want. North also grades how steady each plan's spend is, and uses that grade to cap how fast the ladder may climb. Where spend is less predictable, North adds coverage more slowly, leaving you room to change course. The grade sets pace only. It does not lower the coverage North recommends for you. ### Choosing a Coverage Profile Choose a coverage profile based on how sure you are that the usage will last, and on how long you are willing to commit to it. | Profile | Base | Ladder | Term mix | Choose it when | | ------- | ---- | ------ | ---------------------------- | -------------------------------------------------------------------------------------------------------------- | | Crawl | 0% | 100% | 100% one-year | You are unsure the usage will last. For example, the workload is new, it may migrate, or its usage is falling. | | Walk | 25% | 75% | 50% one-year, 50% three-year | The usage is steady, but you want room to change course. | | Run | 60% | 40% | 25% one-year, 75% three-year | You expect the usage to last for most of three years. | | Jet | 80% | 20% | 15% one-year, 85% three-year | You are confident in the usage and want to reach your target quickly. | | Hyper | 90% | 10% | 100% three-year | You expect the usage to last for the full three years, and you want the most savings. | A three-year term has a deeper discount than a one-year term, and it commits you for longer. North offers one-year terms only on AWS and Azure Database Savings Plans and on RDS Reserved Instances. On these plans every coverage profile buys one-year terms, so the profiles differ only in Base and Ladder. The simulation shows the projected ESR, Savings/mo, Flex Score, and Time to Peak for each coverage profile on your account. In the Autobot drawer, click **Compare Profiles** to see the profiles side by side. ## Buying Coverage Through a Policy A coverage policy applies to a service. Select the service at the top of the Commitments page before you set a policy for it. 1. On the Commitments page, click **Adjust Coverage**. 2. If you are looking to buy commitments for Reserved Instance plans, you can choose to exclude certain instance types so that North does not account for their usage while forecasting the commitment needs. See [Choosing Which Instances Count](/docs/features/coverage/coverage-plans#choosing-which-instances-count) for more details. 3. Choose a range to project over: 3m, 6m, 1y, 2y, or a custom range. 4. Use the Coverage Policy slider to set your coverage target. The track runs from 0% to 100% of your on-demand equivalent spend, and your plan's recommended maximum is indicated on it. 5. Use the Auto / Flex control to divide that target between Autobot and Flexbot. 6. Open the Autobot drawer and select a coverage profile. Click **Compare Profiles** to see the profiles against each other. 7. Review the projected ESR, Savings/mo, Flex Score, and Time to Peak. 8. Click **Update Policy**, then authorize the configuration. ### Authorizing a Policy When you click **Update Policy**, North shows an **Authorize coverage configuration** confirmation before it purchases anything. The confirmation states: * The chosen profile and your target coverage. * The details of what will be bought each month, including the commitment terms, rates, cost per month, and the expected savings per month. You can see the projected purchases for the rest of the ladder. Note that these are projections only - North re-evaluates every month against your actual usage, so only the first month's purchases are fixed at the time of authorization. * The Flex purchases that are part of the profile. By default, North will assess the Flex split of your policy each month and recommend additional purchases as needed. If you would rather that this be a one-time purchase, turn off the **Keep buying Flex as part of this policy** toggle. * Any required permission that is missing, and a **Set up permissions** link to grant it. {% hint style="info" %} Confirming a policy authorizes North to purchase commitments on your behalf. An automation fee applies to Autobot coverage. See the [pricing page](https://north.cloud/pricing) or your Master Services Agreement for details. {% endhint %} ### Permissions Autobot Needs Autobot purchases and manages commitments directly in your own AWS, Google Cloud, or Azure account. Before it can act on your behalf, you must grant it purchasing permissions. * **AWS.** Deploy the `NorthAutoPurchasingRole`. Its trust policy names a single role inside North's account, so it does not take an external ID. * **Google Cloud.** Grant three roles, each at the scope its commitment type works at: `compute.admin` on your organization, `bigquery.resourceAdmin` on the project you designate for reservations, and `consumerprocurement.orderAdmin` on your billing account. The third one is what allows Autobot to buy Flexible CUDs. * **Azure.** Grant the `Reservation Purchaser` and `Savings plan Purchaser` roles, at subscription scope. North checks these permissions when you enable Autobot on a profile. North also requests them during onboarding for new accounts. A missing purchasing permission does not affect your account's overall verification status. Flex purchases do not need these permissions. North holds those commitments in its own accounts. ### What Happens Each Month Once your policy is active, North generates new recommendations every month, based on how your usage has changed. What happens next depends on which mechanism holds the coverage. * **For your Flexbot share:** Every North customer is assigned a dedicated Customer Success Engineer (CSE). Your CSE monitors your order, keeps you updated on its status, and guides you through the next steps. As part of this process, you are invited to add North-managed Savings Pods to your environment. These pods distribute discounts directly into your account. * **For your Autobot share:** North purchases commitments directly into your own account. There is no separate invite step. The permissions you granted when you confirmed your policy are what let North purchase on your behalf. Coverage ladders up gradually, following the profile you chose, until it reaches peak coverage. ### Updating an Existing Policy On the Commitments page, click **Adjust Coverage** to open the simulation again. Change your coverage target, your Auto / Flex split, or your coverage profile. Click **Update Policy** and authorize the new configuration. North uses the new policy for its next set of recommendations. ## Buying Flex to Cover a Shortfall Use this when the Flex share of your coverage target sits above the Flex North already holds for you. Autobot fills its own share of that target. The Flexbot drawer presents what is left for Flex as a single purchase for you to make. {% hint style="info" %} **Note:** If you have not set a coverage policy, North's recommended maximum stands in as your target. {% endhint %} 1. On the Commitments page, click **Adjust Coverage**. 2. Open the **Flexbot** drawer. 3. Review the purchase table. It shows the commitment, the term, the rate, the cost per month, and the savings. Below it, North states the coverage the purchase takes you to. 4. Lower the rate if you want to buy less. You cannot set it above North's recommendation. 5. Click **One-Time Purchase**. A one-time purchase does not change your ongoing policy, and it needs no purchasing permissions. To change your ongoing coverage, use the Coverage Policy and Auto / Flex controls above the drawer. North holds every Flex commitment in its own accounts. After you buy, your Customer Success Engineer contacts you to attach North's Savings Pods to your account. The discount reaches you once those pods are in place. ### How the Controls Above Change This Offer Your Coverage Policy target sets the top of the band Flexbot can fill. The Auto / Flex control sets how much of that band belongs to Flex rather than to Autobot. Raise your target, or move the split toward Flex, and the offer grows. Move it toward Auto and it shrinks. ### When There Is Nothing to Buy The drawer states the reason and shows the two figures that produce it. There are three reasons: * North already holds more Flex on this plan than your policy allocates to Flex. * Your own commitments and Autobot's purchases already reach your target. * Purchases already in progress account for the remaining room. ### Why a Shortfall Appears A shortfall is typically a timing gap. Your coverage policy re-evaluates every month, and North works Flex recommendations through with you. Both take time. Use this drawer when you would rather act now than wait for either. A shortfall in this drawer has several causes: * Sustained spend growth lifted your coverage target. * A Flex recommendation was canceled. * A recommendation is still with your Customer Success Engineer. * You raised your coverage target or your Flex share. * Commitments expired. * A plan came into scope. * The account has no coverage policy. An account with no coverage policy is the one exception. Nothing is running to close that gap until you set a policy. If you cancel a Flex recommendation, it returns while the condition that produced it holds. A cancellation applies to that request only. ## Buying Coverage Above Your Target Use this to cover spend you deliberately left outside your policy. The On Demand drawer offers the band from your coverage target up to the recommended maximum. The drawer opens with the share of spend above your target, and the recommended maximum for the plan. It then gives you the savings available on the part still worth covering. The rest sits past the point where the savings curve peaks. 1. On the Commitments page, click **Adjust Coverage**. 2. Open the **On Demand** drawer. 3. Review the purchase table, and lower the rate if you want to buy less. 4. Click **One-Time Purchase**. This purchase works the same way as a Flex shortfall purchase. North holds the commitment, and your Customer Success Engineer handles fulfillment. {% hint style="info" %} **Note:** This drawer sells the band between your target and the recommended maximum, so lowering your target makes the offer larger and raising it makes the offer smaller. If your target already sits at the recommended maximum, there is nothing here to buy, and the drawer says so. {% endhint %} ## Frequently Asked Questions ### How Do I Turn Off Autobot? You can either temporarily turn off Autobot or opt out of it completely. * To temporarily turn off Autobot but leave your selected profile intact: In the Autobot drawer, set the **Autobot off** toggle. * To turn off the Autobot profile completely: In the coverage profile list, select the **Off** profile, then click Update Policy and confirm. This stops new purchases. Commitments you already hold run to the end of their terms. # Commitments Learn how to use the Commitments page to track your coverage, your savings, and the health of every commitment. The Commitments page is where you see how much of your cloud spend is covered, what that coverage saves you, and how each commitment is performing. It also shows what is queued to be purchased, and how your coverage and savings have moved over time. {% hint style="info" %} You can also purchase additional coverage from this page. See [Purchasing Coverage](/docs/features/coverage/purchasing-coverage) for details. {% endhint %} ## Adjust Coverage * **Adjust Coverage** opens the coverage simulation, where you set your coverage policy and buy additional coverage. See [Purchasing Coverage](/docs/features/coverage/purchasing-coverage) for more details. * The **Autobot** and **Flexbot** pills show whether Autobot and Flexbot are currently active on your account. * **Plan** narrows the page to one commitment plan. By default the page loads scoped to Compute Savings Plans. ## Current Coverage and Projection This section shows your coverage today, and how it is projected to change. Four figures sit above the chart: * **Savings**, what your commitments saved over the selected range. A selector on this tile allows you to see savings from Flexbot, Autobot, or the total. * **Available Savings**, the additional savings per month you could still capture on this plan. North works this out over a window sized to that plan's own spend pattern, rather than a fixed number of days. * **Coverage**, the share of your on-demand equivalent spend that a commitment covers. * **ESR**, your Effective Savings Rate. See [Metric Definitions](#metric-definitions) below for details. Set the range with the **30d**, **60d**, **90d** and **Custom** controls. Set the granularity to hourly, daily, or monthly. North gives you several different visualizations to see your coverage data. * **Simple:** The Simple view charts covered spend against uncovered spend over the selected range, with your projected coverage drawn over it. * **Inventory:** The Inventory view charts the commitments you hold, forward from today. Use the period control to move the window backward or forward twelve months at a time. Three types of inventory charts are available: * **Commitment windows** draws one band per commitment, stacked. The total steps down as each commitment expires. Each band is sized by the on-demand equivalent it covers, and a deeper shade is a three-year term. Hover a band for the price paid. * **Stacked timeline** charts the same inventory over time. * **Ranked horizontal bars** ranks the inventory by size. ## Commitments Health This section lists every commitment held in your account. It includes both commitments held by you as well as by North for you. Click **Expand** to open the list. For each commitment, the list includes the identifier, the commitment type, the service it covers, its utilization, ESR, cost/hr, savings, the term, and expiry date. Click any row to see more details about the commitment. * By default the list includes commitments for all services. Use the **Commitment Type** filter to narrow the list. * If you want to look at your commitments with low utilization, use the **Underutilized Commitments** filter. * You can also narrow the list to commitments that are about to expire using the **Expiration Window** filters. * Use the date range filters to filter the list by the month the commitments were purchased. ## Pending & Forecasted This table lists commitments that are queued to be purchased, and commitments North forecasts buying for you. * North generates new recommendations every month, so this table changes as each month's set is decided. * Each row shows the coverage profile, the commitment type, and the service. It also shows the date you authorized it, the purchase date, the status, and the expected savings. * Once North purchases a commitment, its associated record from this table moves to the Commitments Health table above it. * This is also where you can cancel a request for a Flex purchase. Autobot purchases cannot be canceled - instead you must [turn off Autobot](/docs/features/coverage/purchasing-coverage#how-do-i-turn-off-autobot) to prevent future purchases against your policy. ## Analytics This section shows trends for your coverage and your savings over a range you select. Set the range with the **3M**, **6M**, **12M** and **Custom** controls, and set the granularity to hourly, daily, or monthly. Each card states whether the figure is an average or a total across the range. * **ESR**, your Effective Savings Rate. * **North Flex Savings**, savings from commitments North holds for you. * **North Auto Savings**, savings from commitments Autobot purchased into your own account. * **On Demand Spend**, spend that no commitment covered. * **North Utilization**, how much of the commitments North manages is being used. * **Coverage**, the share of your on-demand equivalent spend that a commitment covers. ## Metric Definitions * **Utilization** is how much of one commitment is being used. It is not the share of your environment that commitments cover. Utilization tells you how effectively you are using what you already committed to. * **Effective Savings Rate (ESR)** is your blended discount across committed and on-demand spend. North calculates it after any Enterprise Discount Plan (EDP) or other negotiated pricing. If you have negotiated pricing with your cloud provider, ESR reflects your savings measured against that negotiated rate. # Coverage Plans Learn which commitment plans North supports, on which cloud, for which services, and through Flexbot or Autobot. A coverage plan is a commitment North can buy from a cloud provider on your behalf. Each plan covers a defined set of services, is sized in a particular way, and is available through Flexbot, through Autobot, or through Autobot alone. North does not offer any plan that requires an upfront payment. See [Coverage](/docs/features/coverage) for how Flexbot and Autobot work. See [Purchasing Coverage](/docs/features/coverage/purchasing-coverage) for how to buy a plan. ## Plans North Supports | Plan | Cloud | Covers | Sized by | Flexbot | Autobot | Terms | | ------------------------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------------- | ------- | -------- | | Compute Savings Plans | AWS | EC2, Lambda, ECS, EKS, Fargate | Spend | Yes, 3yr only | Yes | 1yr, 3yr | | Database Savings Plans | AWS | RDS, ElastiCache, OpenSearch, DynamoDB, DocumentDB, Neptune, Keyspaces, Timestream, DMS | Spend | Yes | Yes | 1yr | | SageMaker Savings Plans | AWS | SageMaker | Spend | Yes, 3yr only | Yes | 1yr, 3yr | | RDS Reserved Instances | AWS | RDS | Quantity | No | Yes | 1yr | | ElastiCache Reserved Instances | AWS | ElastiCache | Quantity | No | Yes | 1yr, 3yr | | OpenSearch Reserved Instances | AWS | OpenSearch | Quantity | No | Yes | 1yr, 3yr | | Redshift Reserved Instances | AWS | Redshift | Quantity | No | Yes | 1yr, 3yr | | Compute Engine Flexible CUDs | Google Cloud | Compute Engine, GKE, Cloud Run, Cloud Run Functions | Spend | No | Yes | 1yr, 3yr | | Cloud SQL CUDs | Google Cloud | Cloud SQL | Spend | No | Yes | 1yr, 3yr | | Azure Compute Savings Plans | Azure | Virtual Machines, VM Scale Sets, App Service, Container Apps, Container Instances, Functions | Spend | No | Yes | 1yr, 3yr | | Azure Database Savings Plans | Azure | SQL Database, SQL Managed Instance, Cosmos DB, Database for MySQL, Database for PostgreSQL, Database Migration Service, Managed Instance for Apache Cassandra | Spend | No | Yes | 1yr | ## Savings Plans and Reserved Instances The two instruments behave differently, and the difference decides which one fits a workload. A **Savings Plan** commits you to an amount of spend per hour. It applies to whatever eligible usage runs, up to that amount, whichever instances produce that usage. You can change instance type, size, family, or region, and the commitment keeps applying. A **Reserved Instance** reserves specific capacity. When you buy one, you specify the instance type and the region. For RDS, ElastiCache, OpenSearch and Redshift you also specify the database engine. The reservation applies only to usage that matches what you specified. If you move that workload, the reservation stays behind. This is why Reserved Instances are available through Autobot only. A reservation is a whole unit of specific capacity, so there is no single amount that a customer can buy to reach a coverage target. Autobot sizes it against your fleet instead. ## What a Plan Covers Inside a Service A plan covers particular usage within a service. It does not cover everything that the service bills. ### Savings Plans * **Lambda.** Duration and provisioned concurrency are covered. Requests, storage, and data transfer are not. * **Fargate.** vCPU, memory, and Windows OS hours are covered. Ephemeral storage is not. ### Reserved Instances A Reserved Instance covers instance hours and node hours. Storage, backup, snapshots, provisioned IOPS and throughput, serverless capacity, data transfer, and extended support are not covered. ## Choosing Which Instances Count A Reserved Instance reserves specific machines, so Autobot needs to know which machines to size against. You control that with a policy scope. The policy scope lets you exclude instances from the coverage estimate. North then sizes your coverage against what is left. Set it on the Commitments page, on the plan you are setting a policy for. Only RDS, ElastiCache, OpenSearch and Redshift Reserved Instances carry a policy scope. Savings Plans do not carry one. A Savings Plan applies to any eligible instance, so excluding one would change nothing. Four rules govern the scope: * You exclude instances. You do not add them. Every instance is in scope until you take it out. * The scope is set for one commitment type at a time. * An exclusion is reversible. Put an instance back in scope, and North includes it again. * A new instance you add to your fleet is in scope automatically. ## RDS Is Eligible for Two Plans RDS usage can be covered by a Database Savings Plan, and it can be covered by an RDS Reserved Instance. North builds a recommendation for both. North prefers the Savings Plan, because a Savings Plan leaves your architecture free to change. The savings quoted for the two plans describe the same underlying usage. They do not add together. ## Savings Plans Under Flexbot Flexbot supports Savings Plans only. Three plans are available through Flexbot: Compute Savings Plans, Database Savings Plans, and SageMaker Savings Plans. # Coststreams Learn more about one of our most powerful feature Coststreams.
Coststreams puts you in control of your cloud spend through two core capabilities: powerful, flexible visibility and simple, precise cost allocation. With just a few clicks, you can subdivide complex and large datasets within your cloud environment, creating real-time, dynamic groupings of your spend based on any attribute you choose—teams, business units, environments, projects, cloud provider, or fully custom tags. These groupings update live as your cloud accounts evolve, letting you isolate, track, and manage subsets of spend exactly the way your business requires. The UI makes it easy to slice and dice spending, create groupings or sets of groupings, and assign them to business units. Each business unit can then have its own set of company users, enabling you to allocate costs accurately, assign tailored budgets, and control access. North's AI Budget Insights monitor historical spend to assess your budget health and notifies you proactively if your stream or business unit budgeting is off track or if thresholds are exceeded. You can drill into spend analytics at any granularity—from daily to monthly—to observe trends and optimize operations. This flexibility empowers organizations to analyze and manage spend intelligently: * **For smaller companies:** Even with simple account structures, tangled shared resources and services make cost separation painful. Cost Streams lets you untangle and allocate shared costs, so every dollar spent is tracked to its true business purpose. * **For larger organizations:** Complex, multi-account, multi-region, and multi-service landscapes make traditional cost tracking unmanageable. Cost Streams makes it easy to split, regroup, and assign accountability—so teams and business owners are responsible for their usage and alerted proactively to significant changes or overspending. Additional features include automated showback of costs to any group, and the ability to send pre-populated PDF reports summarizing spend and allocations for key stakeholders. {% hint style="info" %} **Streams are not limited to cloud spend.** If you have connected a Cost Loop, you can include its spend in a view alongside your cloud accounts, and allocate it through the same model. Select the loops you want when you create the view. Splitting a loop by service breaks AI spend down to the model, and splitting a model by usage type separates cached input, input, and output cost. See [Cost Loops](/docs/features/cost-loops). {% endhint %} {% content-ref url="/pages/PSa2d89rQLla0kXCcVgC" %} [Getting Started](/docs/features/coststreams/getting-started) {% endcontent-ref %} {% content-ref url="/pages/z9SwpQOcSuGPTC6vn42e" %} [Business Units](/docs/features/coststreams/business-units) {% endcontent-ref %} {% content-ref url="/pages/faKcklgCIgw958anlMu8" %} [Cost Labels](/docs/features/coststreams/cost-labels) {% endcontent-ref %} {% content-ref url="/pages/RAOKYnbahhH7Oh3KvMPK" %} [Cost Units](/docs/features/coststreams/cost-units) {% endcontent-ref %} # Getting Started How to build your first cost stream. {% embed url="" %} ### How to Get Started with Cost Streams Cost Streams is a dynamic cost allocation and intelligence tool, empowering teams with greater visibility, control, and insights into every facet of their cloud spend—down to products, teams, or any organizational layer you need. To get the most from Cost Streams, it's important to understand its hierarchy and workflow. Here’s a step-by-step structured guide: #### Cost Streams Hierarchy & Concepts **Views**\ Think of each *View* like a browser tab: * Each view is a private workspace, with its own business units and stream logic. * Use separate views for any department or team that needs a unique lens on cloud spend. {% embed url="" %} **Business Units (BUs)** * A business unit is a grouping that will receive a share of costs from streams. * They respect accounting and cost allocation principles where lower level streams cannot be assigned to a BU if the higher level stream is already assigned, disabling any double accounting errors. * You assign streams directly to BUs. * For highly granular BU allocation, create more downstream split boxes and assign at that level. * Defined a budget to your BU which will automatically track your spend and alert anyone assigned to the BU. * Define a cohort (group of users) to your BU, in order to receive notifications on your curated spend health. {% embed url="" %} **Streams** * Streams channel spend and intelligence using your chosen split logic. * Splits can be as simple or as granular as you like; add new filters or sub-splits to refine cost distribution. *** #### Getting Started: Building Your First CostsStreams Logic {% hint style="info" %} Cost Streams is **enabled by default for all North accounts**. {% endhint %} 1. **Create & Name a View** * Click **New view** and name it according to your department, team, or reporting purpose. * If you have connected any Cost Loops, use the **Cost loops** control in the same dialog to choose which ones this view includes. See [Cost Loops](/docs/features/cost-loops). 2. **Start with the Root Account Costs** * From within your view, begin with the root box that represents your total cloud spend. 3. **Split and Filter** * Add filters and splits to the root box to allocate costs by tags, projects, environments, provider, or other attributes. * To further subdivide any allocation, create new sub-boxes (subsplits) under any existing split. * There’s no limit to how deep or granular your splits can go. 4. **Create Business Units** * Click **Business Units** in the top bar to open the business units panel, then click **Create new** to add each BU that should receive cost allocations (e.g., teams, divisions). 5. **Assign Streams/Boxes to Business Units** * Hover a stream box and click **Actions**, then **Business Units**, to connect that box's costs to the relevant BU. *** #### Example Cost Streams Setup 1. **Marketing View:** * Filters spend by campaign and region. * Boxes split by cloud tags (`env`, `campaign_id`). 2. **R\&D View:** * Splits by environment, then project. * Subboxes go as granular as needed for cost allocation control. 3. **Business Units:** * “Europe Engineering,” “US Marketing,” etc. * Stream boxes assigned according to need. # Business Units Learn how to use Business Units in North.cloud's Cost Streams. {% embed url="" %} #### Understanding Business Units (BUs), Budgets, and Cohorts **Business Units (BUs)** are flexible, top-level entities within North's Cost Streams designed to represent teams, departments, regions, or any organizational grouping that needs to be accountable for cloud spend. By organizing your cost allocation around BUs, you create clear, actionable ownership of costs throughout your business. **Budgets and AI-Powered Budget Status** You can create separate budgets for each BU. North also provides an **AI-assigned budget**, which analyzes your historical spend and trends to recommend the most realistic and effective budget threshold for each unit. Budgets have a real-time status indicator: * 🟢 **Green:** On budget — your spend is tracking at or below the threshold. * 🟡 **Yellow:** Close to exceeding budget — spending pace suggests you may go over unless adjustments are made. * 🔴 **Red:** Over budget — the current rate will cause your costs to exceed the assigned budget. These statuses help you proactively manage spend, receive early warnings, and prevent surprises before they impact your bottom line. **Cohorts: Shared Ownership Across the Platform** In addition to BUs, you can assign **cohorts**—global groups of users or stakeholders from anywhere in your organization—to own, monitor, or be accountable for the costs and budgets of particular units, projects, or streams. Cohorts provide cross-functional visibility and shared responsibility, making it easy to collaborate on cost management across departments or teams. ### Showback {% embed url="" %} #### Showback Statements for Business Units **Showback** statements let you transparently report cloud costs by Business Unit (BU), helping drive accountability and foster fiscal awareness across your organization. With North, showback can be **manually created and shared** for any BU. {% hint style="info" %} Showback is always generated **at the Business Unit level**. Individual Coststreams or other sub-units cannot receive showback statements—only entire BUs are eligible. {% endhint %} **How to Generate and Share a Showback Statement** 1. On the **Streams** page, click **Business Units**. 2. Click the business unit you want a statement for. A panel opens on the right of the screen. 3. Go to the **Summary** tab. 4. Click **PDF** to download the statement. The file is named for the business unit and the date. To put a client or partner logo on the statement, select a brand beside the **PDF** button before you download. Use **Manage Brandings** in the same control to add one.

# Cost Labels Learn more about Cost Labels in North.cloud's Coststreams. {% embed url="" %} #### Introducing Cost Labels **Cost Labels** in North's Cost Streams are a lightweight way to visually group streams and give your team fast context for spend, trends, or initiatives—without the operational controls of BUs. Every Cost Label has: * A **name** (displayed throughout the UI) * An optional **description** (for context, e.g. “Customer-related costs”) * A customizable **color** (for instant recognition and grouping in all visualizations) You can assign any stream—or multiple streams—to one or more Cost Labels, making it easy to organize and spot spend groupings across projects, products, or ad hoc initiatives. {% hint style="info" %} Cost Labels are *only* for visual organization and reporting. They do not control assignments, notifications, alerting, or budget actions. Unlike Business Units (BUs), Cost Labels do not enforce accountability or drive budget status—they simply let you tag and roll up cost views as you see fit. {% endhint %} #### **How to Use Cost Labels** * Create Cost Labels for any grouping important to your business (for example: “Customer Facing,” “Internal Tools,” “Experimentation,” “Compliance”). * Assign streams to Cost Labels for clear visual aggregation across dashboards. * Each stream can have one or more Cost Labels, and you may group multiple streams under a single label for consolidated reporting and exploration. * Cost Labels only aggregate costs for visualization purposes and do not affect the underlying allocation or ownership rules. **Constraints & Best Practices** * You can group streams *across* Cost Labels as needed, even if they span different teams or BUs. * There are no restrictions based on organizational except for double-accounting rules on the same cost label. **Example Use Cases** * Highlight all streams related to a launch (“Launch Q4” Cost Label, bright blue) * Visually track major compliance costs across services (“SOC2” Cost Label, purple) * Group experimental, trial, or innovation streams (“Labs” Cost Label, yellow) * Identify internal vs. customer-facing spend in cross-sectional reports {% hint style="info" %} Use Cost Labels in tandem with BUs for fine-grained visual insight and broad organizational clarity, enabling both action and rapid context in every North Cost Streams dashboard! {% endhint %} # Cost Units Learn more about Cost Units in North.cloud's Coststreams. **Cost Units** is a capability within [Coststreams](https://docs.north.cloud/docs/features/cost-streams) that helps teams measure cloud spend against the business metrics they already care about, such as cost per click, impression, customer, incidents, and more. Instead of viewing cloud costs in isolation, Cost Units connect infrastructure spend to real business outcomes at the business unit level, updating in near real time. This makes it easier to understand efficiency, track trends, and explain why costs change, not just that they changed. ### When to use Cost Units Use Cost Units when you want to: * Measure efficiency, such as cost per click or clicks per dollar * Connect cloud spend to KPIs already used by marketing, product, or finance teams * Track how efficiency changes over time, daily or monthly * Bring business metrics and cloud costs into one shared workflow Cost Units are flexible by design. You define the metric, the direction of the calculation, and the time granularity. There is no fixed schema or prescribed KPI. ### To get started with Cost Units 1. Navigate to the **Streams** tab in [app.north.cloud](http://app.north.cloud) 2. Click **Business Unit** in the top left corner of the interface
3. Select the business unit you want to analyze 4. A configuration panel will open on the right side of the screen 5. Select **Cost Units** (next to Analytics and Budget) 6. Create a new Cost Unit by choosing **Manual entry** or **Upload** ### To import metrics into Cost Units Cost Units support multiple ways to bring in your business metrics, depending on your workflow.
#### Upload a file 1. Select **Upload** 2. Upload a supported file type: 1. .csv 2. .xlsx 3. .numbers 3. Map the metric values to the appropriate dates and business unit Uploads are commonly used for historical backfills or when metrics already exist in reports or exports. #### Manually enter metrics Manual entry is useful for quick experimentation or when you want full control over the data.
1. Select **Manually enter** 2. A modal will appear in the center of the screen 3. Enter the following details: 1. Name: The metric you are tracking (for example, Impressions) 2. Description: Optional context for your team 3. Type: 1. Numerator (metric divided by cost), or 2. Denominator (cost divided by metric), depending on how you want to measure your Cost Units 4. Granularity: Daily or monthly 4. Click **Continue to add data** 5. Select a date range to apply metric values across multiple days or months in a single step 6. Enter your metric values for each date. 1. For example, number of impressions, clicks, users, or incidents 7. Click **Create** ### View and analyze Cost Units Once data is uploaded or manually entered, your Cost Units will appear in the Cost Units panel on the right side of the screen.
You can: * View efficiency as charts or in a list view * Track average cost over time * Identify trends and spot spikes or anomalies * Switch between metric per cost and cost per metric views Because cloud costs and business metrics update continuously, Cost Units show how efficiency evolves over time rather than providing a static snapshot. ### Export Cost Units data To export Cost Units data: 1. Click **Export** in the top right corner of the Cost Units card 2. Download the dataset, including your business metric and associated cloud costs Exports can be used for reporting, sharing, or deeper offline analysis. ### Drill deeper with Noros In the bottom right corner of the screen, open [**Noros**](https://docs.noros.ai) to analyze your Cost Units using natural language. You can ask Noros to: * Explain changes in cost per metric * Surface trends over time * Investigate spikes or efficiency drops * Provide context for shifts in performance Noros helps translate Cost Units into clear, actionable explanations without exporting data or rebuilding views. # API Integration ## Cost Units Public API North's Cost Units feature enables you to track and manage custom cost metrics within your cloud financial operations. With the Public API, you can programmatically upload and retrieve cost unit data from outside the North UI, using secure API keys for authentication. #### When to Use the Public API Use the Public API when you want to: * Automate recurring metric uploads from an internal data pipeline or warehouse * Sync business metrics from a third-party system on a schedule * Retrieve Cost Unit data programmatically for custom dashboards or reports * Integrate metric uploads into CI/CD or ETL workflows ### Creating API Keys Before you can use the Public API, you need to create an API key within the North application. API keys provide secure, programmatic access to your cost unit data without requiring interactive authentication. #### Key Management in the North UI To create an API key within the North application: 1. Navigate to the **Streams** tab in [app.north.cloud](http://app.north.cloud/) 2. Open the **API Keys** management section 3. Provide a **name** for the key (for example, "Production Pipeline" or "Weekly Sync") 4. Optionally set an **expiration date** (maximum 365 days from creation) 5. Click **Create** 6. **Copy and save the API key immediately.** The full key is only shown once at creation time and cannot be retrieved later. API keys use the format `north_api_{secret_hash}`. #### Viewing API Keys The API Keys section displays all active keys for your organization, including: * Key name * Date created * Expiration date (if set) * Last used timestamp #### Revoking API Keys To revoke a key, click the delete action next to the key you want to remove. Revoked keys are immediately deactivated and can no longer be used to authenticate API requests. **Important:** When you create a new API key, it will be displayed only once. Make sure to save it securely, as it cannot be retrieved later. If you lose an API key, you'll need to create a new one and revoke the old key. Each API key is scoped to your organization and provides access to all cost units within your account. The key is validated on every API request to ensure secure access to your data. ### Public API Endpoints The Public API provides two endpoints for interacting with your cost units: * **GET /public/cost-units** - Retrieve existing cost unit data * **POST /public/cost-units** - Update cost unit data with new metrics **Note:** The Public API supports updating existing cost units only. To create new cost units, use the North UI or internal API endpoints. ### Authentication All Public API requests require authentication using an API key. Include your API key in the `Authorization` header of each request: `Authorization: ApiKey north_api_{your_key}` The API key is validated on every request. Requests with missing, invalid, expired, or revoked keys will receive a `403` response. Additionally, you must include your `account_number` as a query parameter in all requests. The API validates that the account number matches the organization associated with your API key. #### Base URL `https://api.north.cloud` ### GET /public/cost-units Retrieve data from an existing cost unit. `GET /public/cost-units` #### Headers | Header | Required | Description | | --------------- | -------- | ------------------------------------------------------------- | | `Authorization` | Yes | Your API key in the following format: `ApiKey ` | | `Content-Type` | No | Content type (not required for GET requests) | #### Query Parameters | Parameter | Required | Type | Description | | ---------------- | -------- | ------ | ---------------------------------------------------------------------- | | `account_number` | Yes | string | Your AWS account number (validated against the API key's organization) | | `costUnitId` | Yes | string |

Cost unit identifier

(e.g., bu-123:cu-456)

| * #### Example Request `GET /public/cost-units?account_number=123456789&costUnitId=bu-123:cu-456 Authorization: north_api_AbCdEfGhIjKlMnOpQrStUvWx` #### Response **Success (200 OK):** {% code overflow="wrap" %} ```json { "status": "success", "message": "Cost unit retrieved successfully", "data": { "businessUnitId": "bu-123", "costUnitId": "cu-456", "status": "processed", "data": { "2024-01-01": { "metric": "100.50" }, "2024-01-02": { "metric": "150.75" } }, "errors": [], "warnings": [], "metadata": { "name": "Impressions", "type": "numerator", "granularity": "daily", "description": "Ad impressions" }, "createdAt": "2024-01-10T12:00:00", "updatedAt": "2024-01-15T08:30:00" }, "meta": { "count": 1, "scannedCount": 1 }, "error": null } ``` {% endcode %} **Error Responses:** * **400 Bad Request:** Missing required parameters, invalid format, or business unit ownership validation failed * **401 Unauthorized:** Invalid or missing API key * **403 Forbidden:** API key does not have access to the requested resource * **500 Internal Server Error:** An internal error occurred while processing your request ### POST /public/cost-units Update an existing cost unit with new data points. This endpoint supports both merging new data with existing data and completely replacing existing data. `POST /public/cost-units` #### Headers | Header | Required | Description | | --------------- | -------- | --------------------------------- | | `Authorization` | Yes | Your API key: `ApiKey {your_key}` | | `Content-Type` | Yes | Must be `application/json` | #### Query Parameters | Parameter | Required | Type | Description | | ---------------- | -------- | ------- | ----------------------------------------------------------------------------------- | | `account_number` | Yes | string | Your AWS account number (validated against the API key's organization) | | `replace` | No | boolean | When `true`, completely replaces existing data instead of merging. Default: `false` | #### Request Body | Field | Required | Type | Description | | ------------ | -------- | ------ | --------------------------------------------------------------------------- | | `costUnitId` | Yes | string | Cost unit identifier (required - updates only, no creation via public API). | | `data` | Yes | array | List of data points with date and metric values | #### Data Point Structure Each item in the `data` array must contain: | Field | Required | Type | Description | | -------- | -------- | ------------- | ------------------------------------------------------------ | | `date` | Yes | string (date) | Date in YYYY-MM-DD format (e.g., "2024-01-15") | | `metric` | Yes | string | Metric value as string (will be validated as decimal number) | #### Example Request `POST /public/cost-units?account_number=123456789 Authorization: north_api_AbCdEfGhIjKlMnOpQrStUvWx Content-Type: application/json { "costUnitId": "bu-123:cu-456", "data": [ { "date": "2024-01-15", "metric": "100.50" } ] }` #### Response **Success (200 OK):** {% code overflow="wrap" %} ```json { "status": "success", "message": "Cost unit processed successfully", "data": { "businessUnitId": "bu-123", "costUnitId": "cu-456", "dataPoints": 2, "errorsCount": 0, "warningsCount": 0, "errors": [], "warnings": [], "processedData": { "2024-01-15": { "metric": "100.50" }, "2024-01-16": { "metric": "150.75" } } } } ``` {% endcode %} **Error Responses:** * **400 Bad Request:** Missing required fields, invalid date format, invalid metric value, or business unit ownership validation failed * **401 Unauthorized:** Invalid or missing API key * **403 Forbidden:** API key does not have access to the requested resource * **500 Internal Server Error:** An internal error occurred while processing your request ### Data Merging vs. Replacement The POST endpoint supports two modes of operation: * **Merge (default):** When `replace=false` or omitted, new data points are merged with existing data. If a date already exists, the new metric value will update the existing value. * **Replace:** When `replace=true`, all existing data in the cost unit is completely replaced with the new data array. This is useful for removing dates from a cost unit by sending an array that excludes those dates. **Tip:** Use `replace=true` when you want to ensure your cost unit contains exactly the data points you send, removing any dates that aren't included in your request. ### Data Validation Notes When uploading data via the POST endpoint, keep in mind: * `metadata` and `viewId` fields are ignored if provided. Existing metadata is preserved. * Future dates are rejected. For daily granularity, the current date is also rejected. * Duplicate dates within a single request are rejected. * Metric values are rounded to 2 decimal places. ### Examples #### Retrieve a Cost Unit `curl -X GET \ "https://api.north.cloud/public/cost-units?account_number=123456789&costUnitId=bu-123:cu-456" \ -H "Authorization: ApiKey north_api_AbCdEfGhIjKlMnOpQrStUvWx"` #### Upload Data to a Cost Unit `curl -X POST \ "https://api.north.cloud/public/cost-units?account_number=123456789" \ -H "Authorization: ApiKey north_api_AbCdEfGhIjKlMnOpQrStUvWx" \ -H "Content-Type: application/json" \ -d '{ "costUnitId": "bu123:cu-456", "data": [ {"date": "2024-01-01", "metric": "1500.00"}, {"date": "2024-01-02", "metric": "1620.50"} ] }'` ### Best Practices * **Secure Your API Keys:** Treat API keys like passwords. Store them securely and never commit them to version control or share them publicly. * **Use Key Expiration:** Set expiration dates on your API keys to ensure regular rotation and limit exposure if a key is compromised. * **Monitor Key Usage:** Regularly review your active API keys and revoke any that are no longer needed. * **Validate Data Before Sending:** Ensure dates are in YYYY-MM-DD format and metric values are valid decimal numbers before making API calls. * **Handle Errors Gracefully:** Implement proper error handling in your integration to handle authentication failures, validation errors, and rate limiting. # Visibility Learn how to break down, filter, compare, and forecast your cloud spend in Visibility. In Visibility, you can see the cost data from your cloud accounts in one place: where your spend goes, how it changes, and where it is heading. Visibility has three tabs: * **Explore** shows your spend over a date range. See [Explore costs](/docs/features/visibility/explore-costs). * **Compare** shows two date ranges side by side. See [Compare costs](/docs/features/visibility/compare-costs). * **Forecast** shows your projected spend. See [Forecast costs](/docs/features/visibility/forecast-costs). To open Visibility, select **Analyze** in the top navigation, then select **Explore**, **Compare**, or **Forecast**. {% hint style="info" %} **Visibility is not limited to cloud spend.** If you have connected a Cost Loop, use the **Cost loops** control at the top right to add its spend to the page. The loops you select appear alongside your cloud account, on the same chart and in the same table. See [Cost Loops](/docs/features/cost-loops). {% endhint %} ## Splitting Your Costs Split your spend by a dimension to see the cost of each of its values, such as each service or each region. Use splits to find the largest parts of your spend. For example, split by Service and then by Region to see the cost of each service in each region. Splits apply to Explore and Compare. To add a split, click **Add split**, then select a dimension. You can add up to five splits. With more than one split, each chart series is one combination of values, such as `Amazon Elastic Compute Cloud - us-east-1`. The table below the chart acts like a pivot table showing one column for each split.
Adding a Region split and then a Pricing Term split in Explore. The chart legend and the table update to show each combination of service, region, and pricing term.
## Filtering Your Costs Use filters to keep only the costs you care about. You can filter by any dimension, including one that you do not split by. For example, filter to one service and split by Region to see where that service runs. 1. Click **Filters** at the top right. 2. Select a dimension, then select the values to keep. When you select more than one value for a dimension, Visibility includes cost that matches any of those values. When you filter on more than one dimension, Visibility includes only cost that matches every filter.
Opening the Filters drawer in Explore, selecting Pricing Term, and selecting Standard. A Pricing Term: Standard filter pill appears above the chart.
## Dimensions You Can Split and Filter By Visibility uses the same dimensions as [Streams](/docs/features/coststreams), for both splits and filters. These are the most commonly used dimensions: | Dimension | What it is | | -------------- | ----------------------------------------------------------------------------------------------- | | Service | The cloud service, such as Amazon Elastic Compute Cloud. | | Linked Account | The account in your org that the cost belongs to. | | Region | The cloud region where the cost occurred. | | Usage Type | The specific usage that you were billed for. | | Pricing Term | How the usage was priced, such as Committed for usage that a commitment covers, or Standard. | | Charge Type | The kind of charge, such as usage or a fee. | | Instance Type | The instance type of the resource. | | Tags | The tags on your resources. Each tag key is its own dimension. Select the key, then its values. | There is much more to slice and dice by. The split menu and the **Filters** drawer have more dimensions, grouped by product, configuration, location, billing, and commitments. If your account has cost categories, they are available too. ## Keeping Tabs in Sync With **Sync** on, your settings stay the same as you move between tabs. Sync is on by default. Its switch is at the top of the **Filters** drawer. * **From Explore, or the Compare base state.** Your date range, granularity, splits, and filters carry over to the other tabs. * **From Forecast.** Your granularity and filters carry over to Explore and Compare. Turn Sync off to set up each tab separately. # Explore costs Learn how to break down your cloud spend over a date range with Explore. Explore shows your spend over a date range as a chart and a table. You can split your spend by up to five dimensions, filter it to the costs you care about, and view it from monthly down to hourly. To open Explore, select **Analyze** in the top navigation, then select **Explore**. For how splits, filters, and Sync work across all three tabs, see [Visibility](/docs/features/visibility). {% hint style="info" %} To include SaaS spend from a connected Cost Loop, use the **Cost loops** control at the top right. See [Cost Loops](/docs/features/cost-loops). {% endhint %}
The Explore tab showing monthly spend split by service and region and filtered by pricing term, with a stacked bar chart and a table of costs split by service and region.
## Setting the Date Range and Granularity Use the controls above the chart to set the granularity, the date range, and the cost basis. The date range presets change with the granularity. Hourly views show Unblended cost. The longest date range depends on the granularity: * Hourly: 7 days. * Daily: 90 days. * Monthly: 12 months. ## Reading the Chart The Explore chart shows your spend for each period as stacked bars, with one series for each combination of split values. Use **Display top** dropdown to choose how many series to show. Spend from the remaining series is grouped under **Other**. ## Highest Cost and Top Variant Products The two cards under the chart show the top three entries for: * **Highest Cost.** The chart series with the most spend in the date range. * **Top Variant Products.** The products with the largest increase in daily spend in a given day, within the date range. ## Using Presets Use a preset for a common Explore view. On AWS accounts, open **Filters** and expand **Presets**: * **Regions and Accounts.** Daily spend by linked account and region. * **Purchase type per service.** Daily spend by purchase type and service. ## Exporting Your Data Click **Export** at the top right of the Explore chart to download the data as JSON or XLSX. ## Limitations * **Hourly granularity.** Hourly views are available for AWS and GCP accounts. Azure accounts do not have hourly views. # Compare costs Learn how to compare your cloud spend across two date ranges with Compare. Compare shows your spend from two date ranges side by side, so you can see what grew, what shrank, and by how much. Use it for month-over-month or year-over-year reviews, and to find the cause of a change in your bill. To open Compare, select **Analyze** in the top navigation, then select **Compare**. For how splits, filters, and Sync work across all three tabs, see [Visibility](/docs/features/visibility).
## Setting the Two Date Ranges Compare has two sides, each with its own date range and total: * **Base State.** The period you want to examine, such as month-to-date. * **Compared State.** The period you compare it against. Choose a range relative to the base state, such as **Previous Period** or **Same Period Last Year**, or pick a custom range. Use a preset for a common comparison. Open **Filters** and expand **Presets** to choose one, such as **MTD vs Last Month** or **Last 30 Days vs Previous 30 Days**. ## Splitting and Filtering a Comparison Your splits, and the filters in the **Filters** drawer, apply to both sides of the comparison. To filter only one side, use the **Filter** menu next to that side's date range. ## Choosing a Graph Use **Graph** to show the two periods side by side, overlaid in one chart, or as the variance between them. **Variance** is available only when the two date ranges have the same length. Granularity and Cost apply to both sides. ## Reading the Results The cards under the Compare charts show which costs changed between the two periods. Each entry is one series from the chart above. * **Top Growing Costs.** The costs that grew the most. * **Top Decreasing Costs.** The costs that fell the most. * **Top Cost Center.** The cost with the highest average spend across both periods. # Forecast costs Learn how to project your cloud spend with Forecast. Forecast shows your projected spend, based on your actual cost history. You can also add growth-rate scenarios, to see how your spend changes if it grows faster or slower. To open Forecast, select **Analyze** in the top navigation, then select **Forecast**. For how filters and Sync work across all three tabs, see [Visibility](/docs/features/visibility).
The Forecast tab showing daily actual spend followed by the model projection, with a shaded band between the low and high estimates.
## Setting Up a Forecast Click **Filters** at the top right to open the **Filter & Forecast** drawer. | Setting | What it sets | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | CMGR | CMGR (compound monthly growth rate) is the average rate at which your spend grows each month. CMGR scenarios show as extra lines on the chart. Select **Base CMGR**, the growth rate in your own history, or 1%, 3%, 5%, or 20%. You can also enter your own rate, from -50% to 50%. | | Granularity | Daily or monthly. | | Lookback | How much cost history Forecast uses: up to 365 days for a daily forecast, or up to 14 months for a monthly forecast. | | Projection | How far ahead to forecast: up to 365 days for a daily forecast, or up to 24 months for a monthly forecast. | To forecast part of your spend, add filters in the same drawer, for example one service or one linked account. Filters work the same way as in [Explore](/docs/features/visibility/explore-costs). Splits do not apply to Forecast. It shows the total of the filtered spend. ## Reading the Forecast The Forecast chart shows your **Actual** spend up to today, then the **Model** projection. The shaded band around the projection runs from the **Low Estimate** to the **High Estimate**. Each CMGR scenario that you select appears as its own line. ## Limitations * **Daily and monthly only.** Forecasts are daily or monthly. If Sync is on and Explore is set to hourly, no chart appears. Switch Explore to daily or monthly, or set the granularity in the **Filter & Forecast** drawer. # Rightsize Learn how Rightsize finds cost and performance improvements for your cloud resources. Rightsize identifies cloud resources that cost more than they need to, or that do not have enough capacity for their workload. It recommends a better size for each one, based on how you actually use it. ## How Rightsizing Works Rightsize reads a resource's usage data over a lookback window. It calculates a high percentile of that usage, so one quiet week does not skew the recommendation. It adds a safety margin on top of that peak, then selects the smallest size that fits. Rightsize re-analyzes every account every night. Saving a change in Rightsize settings also triggers an immediate recompute. Depending on the number of services and instances you have, the recompute can take up to 10 minutes. The results on the page cover the last complete calendar month. For example, on October 15, the page shows results for September. A resource that you delete during the current month can still appear, because it existed during the month that the results cover. For an account without a complete month of data, the page shows results for the current month. Each service has its own rules on top of this approach. The page for each service states what Rightsize recommends for it and how. ## Services Rightsize Covers Use the service selector at the top of the page to switch between services. Each service has its own cost chart, summary metrics, and table. | Service | Provider | What Rightsize recommends | Details | | -------------- | -------- | ------------------------------------------------------------------------------------------ | --------------------------------------------------------- | | EC2 | AWS | A smaller or cheaper instance type, or a stop for an idle instance | [EC2](/docs/features/rightsize/ec2) | | Auto Scaling | AWS | A different instance type for the group | [Auto Scaling](/docs/features/rightsize/auto-scaling) | | EBS | AWS | A cheaper volume type, lower provisioned IOPS or throughput, or a review of an idle volume | [EBS](/docs/features/rightsize/ebs) | | ECS | AWS | A smaller CPU and memory configuration for a Fargate service's tasks | [ECS](/docs/features/rightsize/ecs) | | Lambda | AWS | A move to arm64, less provisioned concurrency, or a review of unused standing capacity | [Lambda](/docs/features/rightsize/lambda) | | RDS | AWS | A database class to review | [RDS](/docs/features/rightsize/rds) | | Compute Engine | GCP | A smaller or cheaper machine type, or a stop for an idle instance | [Compute Engine](/docs/features/rightsize/compute-engine) | ## Monitoring Access Rightsize needs to read utilization metrics before it can size anything. * **AWS** - grant access for your org, and separately for any linked account you want Rightsize to analyze. To grant access, update your North stack. See [Update Your North Stack](/docs/getting-started/quickstart/aws-onboarding#update-your-north-stack). Some [region-specific restrictions](/docs/features/rightsize#finding-reasons) cannot be resolved by granting access. * **GCP** - grant the Monitoring Viewer role, and add every project you want Rightsize to analyze to your billing project's metric scope. See [Compute Engine](/docs/features/rightsize/compute-engine). If access is missing for an account or project, Rightsize cannot size its resources. They show as **Insufficient data** with the reason **Monitoring access denied**, and the default view hides them. A banner on each service tab shows how many resources are affected. Select **Show affected resources** to see them. When Rightsize cannot read metrics for any resource on the account, the page shows a request to grant access in place of the table. ## Using the Rightsize Page The page shows a cost chart, summary metrics for the selected service, and a table of individual resource recommendations. * **Cost chart** - shows the selected service's spend. Switch between **Amortized** and **Unblended** to change the chart's cost basis. * **Summary metrics** - Available Savings is the total monthly savings across the selected service's resources. The other tiles show counts of findings, plus the share of resources that are Tagged versus Untagged. * **Filters** - narrow the table by State, Type, Region, Reason, or Cohort. * Use the **All accounts** filter to narrow the table to one or more linked accounts or projects. It appears when there is more than one. * **Non-Optimized** is on by default. It hides Optimized, Insufficient data, and Not analyzed resources. Turn it off, or choose states in the **State** filter, to see them. * **Tag filters** - use the **Filter** button to filter by tag key and value. * **Search** - find a specific resource by name. * **Share** - if you have write permission on Rightsize, you can share Rightsize findings with others in your organization via email, Slack, or Jira. Select one or more rows with the checkboxes, then choose **Share**. Email and Slack shares are limited to 50 resources at a time. Click a row's **AI Suggestion** button to open that resource's panel. The panel shows the resource's current state, the recommendation, the findings behind it, and its utilization history. Optimized rows have no button, except on the RDS tab. A row with no recommendation shows its reason in that column instead. Click the reason to open the panel. ## Rightsize Settings Click the gear icon (**Account Preferences**) to open **Rightsize settings**, where you control how Rightsize analyzes your account. Reading utilization metrics has a small cost, billed by your cloud provider. The exact amount depends on the settings you choose below, and the Spend guardrail settings cap it. {% hint style="info" %} Settings apply to your whole account today. Settings for individual member accounts within one org are not yet available. {% endhint %} * **Profile** - choose **Conservative**, **Balanced**, or **Aggressive**. Balanced is the default. Conservative uses wide safety margins and only recommends clear wins. Aggressive uses the tightest margins and surfaces the most savings. * **Never touch** - exclude specific resources, or anything carrying a tag you choose. Excluding a member of a group excludes the whole group. * **Spend guardrail** - set two limits. Every service shares them. * **Analysis cost floor** - resources that cost less than this each month are not analyzed. * **Monthly metrics budget** - a monthly budget for the metric reads that Rightsize makes on your account. When the budget is used up, Rightsize defers further reads. Raise the budget to resume analysis. * **Advanced** - manually set any individual value behind your chosen profile, grouped as: * **Coverage & cadence** - **Spend coverage**, **Cost change threshold**, and **Max result age**. With Spend coverage, Rightsize analyzes the most expensive resources until they reach this share of total spend. The other two set when Rightsize analyzes a resource again: after a change in its monthly cost, or after a number of days. * **Sizing** - **Metric lookback**, **CPU percentile**, **CPU headroom**, and **Memory headroom**. Metric lookback is how many days of past utilization each recommendation uses. * **Savings floors** - **Min savings** and **Min savings percent**. Rightsize hides a recommendation that saves less than this amount each month, or less than this share of the resource's current cost. * **Per-service overrides** - set values for one service. Select the service, then fill the fields you want to override. An empty field uses the account default shown in that field. **Reset to account default** clears every override for that service. You need write permission on Rightsize to open these settings. Without it, the gear icon is turned off. See [IAM Permissions](/docs/account-management/settings/iam-permissions), or ask your org admin. ## Understanding Each Finding Every analyzed resource gets a finding: a state that summarizes the result, and one or more reasons behind it. Use these to see, at a glance, what Rightsize calculated for a resource and why, before you act on it. {% hint style="info" %} A message above the page shows when the current results are not final. It appears after a settings change, during a background refresh, and on an account without a full month of data. After a settings change and during a refresh, the last completed results stay on screen until the new ones are ready. On an account without a full month of data, the results are estimates based on partial data. {% endhint %} ### Finding States Each finding has one state: | State | Meaning | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Over provisioned** | The resource is bigger than its usage needs. A smaller option is recommended. | | **Under provisioned** | Usage is close to the limit of the current size. A bigger option is recommended. | | **Optimized** | The current size is already the right one. | | **Not optimized** | A cost improvement exists that is not a size change. For example, a volume with provisioned performance that it does not use, or a Lambda function that costs less on arm64. | | **Insufficient data** | Rightsize did not have enough data to size the resource, so it made no recommendation. | | **Not analyzed** | The resource is deliberately out of scope, for example Spot capacity. | Rightsize also flags a resource as **Idle** when it shows no meaningful activity. Idle is separate from the state. It has its own column in the table and its own tile in the summary metrics. ### Finding Reasons Each finding has one or more reasons: which metric it is based on, why a recommendation was capped, or why none could be made. Check these before you act on a recommendation, to understand what it is actually based on. The table's Reasons column shows a count of how many reasons apply to a resource. Click a row's **AI Suggestion** button to see them as Findings chips on that resource's panel. Most reasons are specific to the service. However, there are a few that apply across all services: * **Monitoring access denied** - Rightsize does not have the monitoring grant needed to read this resource's utilization metrics. See Monitoring Access, above. * **Region restricted** - the resource sits in an isolated AWS partition that North's commercial connection cannot reach, such as AWS GovCloud or a China region. Granting more access does not change this, because the partition is unreachable rather than unauthorized. Rightsize skips these resources before it reads any metrics, so they cost you nothing. * **Linked account missing** - Rightsize could not identify which linked account in your AWS Organization owns this resource. * **Covered by a commitment** - a Reserved Instance, Savings Plan, or Committed Use Discount covers at least half of the resource's usage. Rightsize still analyzes it. The saving is estimated at the resource's blended commitment rate, and the panel shows "Estimated at your commitment's blended rate." Resizing a resource does not cancel its commitment. * **Deferred to a later run / Carried from the previous run** - the resource is queued for a later analysis, or its last result was reused because nothing changed enough to re-check it. ### Why a Resource May Have No Recommendation A row with no recommendation shows a short reason in the **AI Suggestion** column, for example "Grant monitoring access to size this resource." Click the reason to open a panel with more detail and the reasons as chips. For a Google Cloud resource without monitoring access, the panel also has a **Grant access** button. A resource marked **Region restricted** shows "North cannot reach this region from your account connection". No action on your side makes it analyzable. When no specific reason applies, the column shows "No recommendation for this resource." Each service page lists the cases that apply to it. ### Why Some Recommendations Might Be Missing Sometimes Rightsize cannot show some or all of your recommendations. A message on the page shows the reason. The list below includes a few examples of such messages. * **Analyzing this account…** - the first analysis of the account is running. The page refreshes automatically, so you can leave and come back. * **Analysis is temporarily off.** - analysis is paused. Recommendations refresh when analysis resumes. Your settings and history are unaffected. * **Rightsize is not enabled for this account.** - Rightsize is not turned on for the selected account. * **Results don't currently include** - a banner that shows how many accounts the results leave out, and which ones. The other results stay on the page. * **Could not load recommendations.** - the results failed to load. Try again in a few minutes. * **You don't have access to this account's recommendations.** - your North user cannot view this account. Switch to an account you manage, or ask an administrator for access. When the table is empty, a line above it shows the reason. For example, it shows how many resources fell below the analysis cost floor, or that the monthly metrics budget is used up. Raise the budget in Rightsize settings to resume analysis. ## Acting on a Recommendation When you have acted on a recommendation, or when one does not fit your resource, record that from the resource's panel. Both actions need write permission on Rightsize. * **Already resolved** - confirms that you reviewed and resolved the recommendation. Rightsize removes it from your shortlist. * **Not a good suggestion?** - confirms that the recommendation is not relevant. North uses your feedback for future Rightsize recommendations. ## Limitations * Rightsize only recommends. It never changes, resizes, or stops a resource on your behalf. * GPU-accelerated instances are not sized. Rightsize sizes on CPU, memory, and network metrics. A GPU-accelerated instance's size depends on its GPUs, which those metrics do not measure. * Spot instances are not sized. Spot capacity is reclaimed and priced on different terms, so Rightsize does not size it. * Rightsize is not available for Azure accounts. * Resources in isolated AWS partitions, such as AWS GovCloud and China regions, are not analyzed. North's commercial connection cannot reach those partitions. * Settings apply to your whole account today, not to individual member accounts within it. # EC2 Learn how Rightsize sizes your EC2 instances. On AWS accounts, Rightsize sizes EC2 instances. It recommends a smaller or cheaper instance type, a larger one when an instance runs near capacity, or a stop for an idle instance. ## What Rightsize Recommends For each EC2 instance, Rightsize recommends one of these: * A smaller instance type in the same family. * An instance type in a different family. * A larger instance type. * A stop. The saving for a stop is an estimate, based on the instance's cost in the month that the results cover. You continue to pay for any commitment that covers the instance, and for its attached EBS volumes. Rightsize does not suggest a burstable instance type (t2, t3, t3a, or t4g) as a target. ## How Rightsize Sizes an Instance Rightsize reads these CloudWatch metrics over the lookback window: CPU utilization, network in and out, EBS read and write bytes, and memory used. Memory data comes from the CloudWatch agent. Without the agent, Rightsize can lower the vCPU count but never lowers memory. The panel then shows "Sized on CPU only. Install the CloudWatch agent to include memory." ### The Sizing Target Rightsize measures CPU and memory at the **CPU percentile** setting, which is P99 by default. A candidate instance type fits when that measured usage, scaled to the candidate's vCPU and memory, stays at or below the target: ``` base target = 100% − headroom target = base target × max(volatility floor, 1 − volatility sensitivity × CoV) ``` CoV is the coefficient of variation of the usage: its standard deviation divided by its mean. A spiky workload has a higher CoV. A higher CoV lowers the target, so the recommended size has more spare capacity. For example, with the Balanced defaults (CPU headroom 20%, volatility sensitivity 0.5, volatility floor 0.5) and a CoV of 0.4: ``` base target = 100% − 20% = 80% target = 80% × max(0.5, 1 − 0.5 × 0.4) = 80% × 0.8 = 64% ``` You can change the CPU percentile, the headroom, and the volatility values in [EC2 Settings](/docs/features/rightsize/ec2#ec2-settings), below. Rightsize then recommends the cheapest instance type that fits. Every candidate must also pass the network and storage checks, and a candidate with fewer vCPUs must also pass the peak load check: * **Peak load** - for a candidate with fewer vCPUs, the highest CPU utilization in the window, scaled to the candidate, stays below 95%. * **Network** - the candidate's network capacity is at least twice the observed peak, in either direction. * **Storage** - the candidate's EBS baseline is at least twice the observed peak of read and write traffic combined. Its EBS bandwidth is also at least that of the current type. Rightsize runs the network and storage checks only when the metric data has periods shorter than one hour. When a check excludes a smaller type that would otherwise have been recommended, Rightsize adds a **Limited by** reason to the finding. ### Larger Instance Types Rightsize recommends a larger instance type when daily average usage exceeds the base target on at least 25% of observed days. This must happen on at least two days. In such cases, the finding state is **Under provisioned**. ### Idle Instances and Stops Rightsize recommends a stop for an instance only when all of these are true. The three thresholds are settings that you can change in [EC2 Settings](/docs/features/rightsize/ec2#ec2-settings), below. * Average CPU stays at or below **Idle CPU ceiling**, which is 10% by default. * CPU stays steady, with a CoV at or below **Idle volatility ceiling**, which is 0.35 by default. * Network egress stays at or below 1 MB per sample at the CPU percentile, and no single network sample in either direction exceeds 25 MB. * The highest CPU utilization, and memory use where measured, never passed **Stop safety peak**, which is 40% by default. ### Commitments When a commitment covers an instance, the recommendation depends on the commitment: * **Reserved Instances that do not allow a size change** - AWS allows a size change only on Linux/UNIX Reserved Instances with default tenancy. Reserved Instances for Windows, RHEL, SUSE, or SQL Server, and Reserved Instances with Dedicated tenancy, do not allow one. For these, Rightsize recommends no other instance type. It does the same when a commitment covers the instance and Rightsize cannot identify it. When this blocks a type that would otherwise have been recommended, Rightsize adds the reason **Review Reserved Instance coverage before resizing**. * **Linux/UNIX Reserved Instances with default tenancy** - Rightsize can recommend a smaller type in the same family. When it does, Rightsize adds the same reason. A regional Reserved Instance applies its discount across all sizes in the family automatically. A zonal Reserved Instance needs a modification to cover the new size. * **EC2 Instance Savings Plans** - The discount applies only within one instance family, so Rightsize keeps the recommendation in the current family. When this blocks a type in another family that would otherwise have been recommended, Rightsize adds the reason **Commitment limits sizing to this family**. * **Compute Savings Plans** - The discount applies across families. Rightsize can recommend a type in another family only when it has the committed rate for every candidate type in the other families. Otherwise, it keeps the recommendation in the current family. ## Using the EC2 Tab The summary metrics on the EC2 tab are Available Savings, Idle, Over provisioned, Under provisioned, Tagged, and Untagged. Available Savings on this tab excludes Auto Scaling groups. The cost chart includes them, and its tooltip reads "Includes Auto Scaling". Click a row's **AI Suggestion** button to open the instance's panel: * **Current State** - the instance name, and its instance type. * **Noros Recommendation** - the recommended instance type, or **Stop instance**. * **Monthly Savings** - the estimated saving. For an instance covered by a commitment, the card also shows "Estimated at your commitment's blended rate." * **Findings** - the reasons behind the recommendation, as chips. Below the panel sections, a chart shows the instance's utilization history. Choose CPU, Memory, Network egress, Network ingress, EBS read, or EBS write to change the metric. ## EC2 Settings In **Settings**, open **Per-service overrides** and select **EC2 & Auto Scaling**. The same settings apply to Auto Scaling groups. An empty field uses the account default. | Setting | What it controls | Balanced default | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | **CPU percentile** | The usage percentile Rightsize sizes against. P99 excludes the highest 1 percent of readings. | P99 | | **CPU headroom** | Spare CPU kept above CPU usage at the CPU percentile. A higher value gives a larger, safer size. | 20% | | **Memory headroom** | Spare memory kept above memory usage at the CPU percentile. A higher value gives a larger, safer size. | 20% | | **Volatility sensitivity** | How much variable usage lowers the sizing target. 0 does not lower it. 1 lowers it the most. | 0.5 | | **Volatility floor** | The lowest value the target can be lowered to. 0.5 keeps at least half of the base target. | 0.5 | | **Idle CPU ceiling** | The average CPU at or below which an instance can count as idle. | 10% | | **Idle volatility ceiling** | How steady CPU must be for an instance to count as idle. A lower value requires steadier CPU. | 0.35 | | **Stop safety peak** | Rightsize never recommends a stop for an instance whose CPU or memory ever passed this. | 40% | | **Min savings percent** | Rightsize does not recommend a smaller or cheaper type that saves less than this share of what the resource costs today. The resource shows as Optimized instead. Stops and larger types are not affected. | 5% | ## EC2 Finding Reasons Rightsize lists the reasons behind each finding. Check these before you act on a recommendation, to understand what it is based on. | Reason | Meaning | | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **CPU Overprovisioned / Underprovisioned** | The finding is based on CPU usage. | | **Memory Overprovisioned / Underprovisioned** | The finding is based on memory usage. | | **Volatile usage** | CPU usage varies, so Rightsize lowered the sizing target. | | **Limited by peak load** | A smaller size passed the CPU percentile test, but the highest peak in the window exceeds its capacity. | | **Limited by network throughput** | The recommended size is the smallest one with enough network capacity for the observed peak. | | **Limited by storage throughput** | The recommended size is the smallest one with enough storage throughput for the observed peak. This check uses throughput only. It does not check IOPS. | | **Limited by missing memory data / No memory metrics** | No memory agent is reporting data, so the recommendation is bounded by CPU alone. The resource's panel links to the install guide for the CloudWatch agent. | | **Burst credits exhausted** | The current type is burstable (t2, t3, t3a, or t4g), and daily average usage exceeded the base target on at least 25% of observed days and on at least two days. This indicates that the instance needs a larger size. | | **Idle** | The instance shows no meaningful activity. Rightsize recommends a stop. | | **Commitment limits sizing to this family** | Because of the covering commitment, Rightsize keeps the recommendation in the current family. See [Commitments](/docs/features/rightsize/ec2#commitments), above. | | **Review Reserved Instance coverage before resizing** | Resizing this resource would change what its Reserved Instance covers. See [Commitments](/docs/features/rightsize/ec2#commitments), above. | | **GPU not sized** | The instance has GPU accelerators. Rightsize sizes on CPU, memory, and network, so it does not size GPU instances. | | **Spot capacity — not right-sized** | The instance runs on Spot capacity. Spot capacity is reclaimed and priced on different terms, so Rightsize does not size it. | # Auto Scaling Learn how Rightsize sizes the instance type of your Auto Scaling groups. On AWS accounts, Rightsize sizes the instance type of each Auto Scaling group. It recommends a smaller or cheaper instance type for the group, or a larger one when the group runs near capacity. ## What Rightsize Recommends An Auto Scaling group runs a set of EC2 instances. AWS adds or removes instances to keep the group within the minimum and maximum that you set, so AWS already manages the number of instances. If you stop an instance in a group, AWS replaces it to keep the group at its desired count. For these reasons, Rightsize recommends a different instance type for all the instances in the group. It does not change the group's desired count, and it does not recommend a stop. Rightsize does not mark a group as idle. A group with very low usage is sized in the same way as any other group. The savings are the price difference per instance, multiplied by the current number of instances in the group, up to the group's compute cost. For a group that runs more than one instance type, Rightsize uses the type of the instance that costs the most. Rightsize does not suggest a burstable instance type (t2, t3, t3a, or t4g) as a target. ## How Rightsize Sizes a Group Rightsize identifies the instances in a group from the `aws:autoscaling:groupName` tag in your billing data. AWS adds this tag to every instance in a group. Make sure that this tag is active as a cost allocation tag in the Billing and Cost Management console in AWS. An instance without the tag in your billing data is sized on its own, on the [EC2 tab](/docs/features/rightsize/ec2) in Rightsize. Rightsize reads these CloudWatch metrics across the group over the lookback window: CPU utilization, network out, and memory used. Memory data comes from the CloudWatch agent. Without the agent, Rightsize can lower the vCPU count but never lowers memory. The panel then shows "Sized on CPU only. Install the CloudWatch agent to include memory." ### The Sizing Target Rightsize measures CPU and memory at the **CPU percentile** setting, which is P99 by default. A candidate instance type fits when that measured usage, scaled to the candidate's vCPU and memory, stays at or below the target: ``` base target = 100% − headroom target = base target × max(volatility floor, 1 − volatility sensitivity × CoV) ``` CoV is the coefficient of variation of the usage: its standard deviation divided by its mean. A spiky workload has a higher CoV. A higher CoV lowers the target, so the recommended size has more spare capacity. For example, with the Balanced defaults (CPU headroom 20%, volatility sensitivity 0.5, volatility floor 0.5) and a CoV of 0.4: ``` base target = 100% − 20% = 80% target = 80% × max(0.5, 1 − 0.5 × 0.4) = 80% × 0.8 = 64% ``` You can change the CPU percentile, the headroom, and the volatility values in [Auto Scaling Settings](/docs/features/rightsize/auto-scaling#auto-scaling-settings), below. Rightsize then recommends the cheapest instance type that fits. A candidate with fewer vCPUs must also pass the peak load check: the highest CPU utilization in the window, scaled to the candidate, stays below 95%. When this check excludes a smaller type that would otherwise have been recommended, Rightsize adds the reason **Limited by peak load**. The network and storage checks that apply to EC2 instances do not apply to a group. For a group, CloudWatch adds up the network traffic of all its instances, so the total does not show what one instance needs. Rightsize does not read storage metrics for a group. ### Larger Instance Types Rightsize recommends a larger instance type when daily average usage exceeds the base target on at least 25% of observed days. This must happen on at least two days. The finding state is **Under provisioned**. ### Commitments When a commitment covers the instances in a group, the recommendation depends on the commitment: * **Reserved Instances that do not allow a size change** - AWS allows a size change only on Linux/UNIX Reserved Instances with default tenancy. Reserved Instances for Windows, RHEL, SUSE, or SQL Server, and Reserved Instances with Dedicated tenancy, do not allow one. For these, Rightsize recommends no other instance type. It does the same when a commitment covers the group and Rightsize cannot identify it. When this blocks a type that would otherwise have been recommended, Rightsize adds the reason **Review Reserved Instance coverage before resizing**. * **Linux/UNIX Reserved Instances with default tenancy** - Rightsize can recommend a smaller type in the same family. When it does, Rightsize adds the same reason. A regional Reserved Instance applies its discount across all sizes in the family automatically. A zonal Reserved Instance needs a modification to cover the new size. * **EC2 Instance Savings Plans** - The discount applies only within one instance family, so Rightsize keeps the recommendation in the current family. When this blocks a type in another family that would otherwise have been recommended, Rightsize adds the reason **Commitment limits sizing to this family**. * **Compute Savings Plans** - The discount applies across families. Rightsize can recommend a type in another family only when it has the committed rate for every candidate type in the other families. Otherwise, it keeps the recommendation in the current family. ## Using the Auto Scaling Tab The summary metrics on the Auto Scaling tab are Available Savings, Idle, Optimized, Not Optimized, Tagged, and Untagged. The Idle tile always shows 0, because Rightsize does not mark a group as idle. Click a row's **AI Suggestion** button to open the group's panel: * **Current State** - the group name, and its instance type. * **Noros Recommendation** - the recommended instance type. * **Monthly Savings** - the estimated saving. For a group covered by a commitment, the card also shows "Estimated at your commitment's blended rate." * **Findings** - the reasons behind the recommendation, as chips. Below the panel sections, a chart shows the group's utilization history. ## Auto Scaling Settings In **Settings**, open **Per-service overrides** and select **EC2 & Auto Scaling**. The same settings apply to EC2 instances. An empty field uses the account default. | Setting | What it controls | Balanced default | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------- | | **CPU percentile** | The usage percentile Rightsize sizes against. P99 excludes the highest 1 percent of readings. | P99 | | **CPU headroom** | Spare CPU kept above CPU usage at the CPU percentile. A higher value gives a larger, safer size. | 20% | | **Memory headroom** | Spare memory kept above memory usage at the CPU percentile. A higher value gives a larger, safer size. | 20% | | **Volatility sensitivity** | How much variable usage lowers the sizing target. 0 does not lower it. 1 lowers it the most. | 0.5 | | **Volatility floor** | The lowest value the target can be lowered to. 0.5 keeps at least half of the base target. | 0.5 | | **Min savings percent** | Rightsize does not recommend a smaller or cheaper type that saves less than this share of what the group costs today. The group shows as Optimized instead. Larger types are not affected. | 5% | ## Auto Scaling Finding Reasons Rightsize lists the reasons behind each finding. Check these before you act on a recommendation, to understand what it is based on. | Reason | Meaning | | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Group Overprovisioned / Underprovisioned** | The finding is based on usage across the group. | | **Volatile usage** | CPU usage varies, so Rightsize lowered the sizing target. | | **Limited by peak load** | A smaller size passed the CPU percentile test, but the highest peak in the window exceeds its capacity. | | **Limited by missing memory data / No memory metrics** | No memory agent is reporting data, so the recommendation is bounded by CPU alone. The group's panel links to the install guide for the CloudWatch agent. | | **Burst credits exhausted** | The current type is burstable (t2, t3, t3a, or t4g), and daily average usage exceeded the base target on at least 25% of observed days and on at least two days. This indicates that the group needs a larger instance type. | | **Commitment limits sizing to this family** | Because of the covering commitment, Rightsize keeps the recommendation in the current family. See [Commitments](/docs/features/rightsize/auto-scaling#commitments), above. | | **Review Reserved Instance coverage before resizing** | Resizing this group would change what its Reserved Instance covers. See [Commitments](/docs/features/rightsize/auto-scaling#commitments), above. | | **GPU not sized** | The instance type has GPU accelerators. Rightsize sizes on CPU, memory, and network, so it does not size GPU instances. | # EBS Learn how Rightsize finds savings on EBS volumes. On AWS accounts, Rightsize identifies EBS volumes that cost more than their usage requires. It recommends a cheaper volume type, lower provisioned IOPS (input/output operations per second) or throughput, or a review of a volume that shows no activity. ## What Rightsize Recommends Rightsize checks each volume in this order, and the first match sets the recommendation: * **Review an idle volume for deletion** - a gp3 volume that you pay extra performance for shows no read or write activity. The saving is the volume's whole monthly cost. * **Change to a cheaper volume type** - a cheaper volume type is available at the same capacity. * **Lower provisioned IOPS or throughput** - you pay for more IOPS or throughput on a gp3 volume than its traffic needs. EBS checks are fixed rules. Unlike EC2, they have no sizing target and no per-service settings. The account-wide settings in EBS Settings, below, still apply. Each rule is described below. ## How Rightsize Checks a Volume Rightsize reads CloudWatch metrics only for gp3 volumes that you pay extra IOPS or throughput for. For those volumes, it reads read and write operations, and read and write bytes, over the lookback window. It reads each one two ways: the total for each period, and the highest single sample in each period. A cheaper volume type does not depend on these metrics, so Rightsize can recommend one for any volume. ### Idle Volumes Rightsize treats one of these gp3 volumes as idle when every one of its metrics comes back empty across at least 10 days in which the volume was billed. AWS sends EBS metrics to CloudWatch only while a volume is attached to an instance, so empty metrics usually mean that the volume is not attached. In such cases, Rightsize states **Review before deleting** and **Idle** as its findings. ### Cheaper Volume Types Rightsize recommends gp3 for gp2 volumes of up to 1,000 GiB, because a larger gp2 volume has a higher IOPS baseline than gp3. Rightsize can also recommend gp3 for io1 volumes. It does not recommend a change for io2 volumes. In such cases, Rightsize states **Cheaper volume type available** as its finding. ### Provisioned IOPS and Throughput On a gp3 volume, you pay extra for IOPS above 3,000 and for throughput above 125 MiB/s. Rightsize checks each of the two separately. It recommends lowering a value to its baseline when the volume's highest traffic, plus 25% headroom, fits within that baseline: ``` trim allowed when (peak read + peak write) × 1.25 ≤ baseline ``` Peak read and peak write are the highest single samples in the lookback window. Rightsize adds them together even when they occurred at different times, so the sum can only overstate the true peak. For example, take a gp3 volume provisioned with 6,000 IOPS, a peak of 1,400 read IOPS, and a peak of 900 write IOPS: ``` (1,400 + 900) × 1.25 = 2,875 ≤ 3,000 ``` The result fits within the baseline, so Rightsize recommends lowering the volume to 3,000 IOPS. The saving is the monthly cost of the provisioned IOPS above the baseline. In such cases, Rightsize states **Volume IOPS Overprovisioned** or **Volume Throughput Overprovisioned** as its finding. Rightsize lowers a value only to the baseline, never to a point in between. When read or write data is missing, Rightsize does not recommend lowering that value. ## Using the EBS Tab The summary metrics on the EBS tab are Available Savings, Idle, Optimized, Not Optimized, Tagged, and Untagged. Click a row's **AI Suggestion** button to open the volume's panel: * **Current State** - the volume's name and type, and its size, IOPS, and throughput when Rightsize has them. * **Noros Recommendation** - the values that change, such as the new volume type or IOPS. * **Monthly Savings** - the estimated saving. * **Findings** - the reasons behind the recommendation, as chips. Below the panel sections, a chart shows the volume's read and write IOPS and throughput. ## EBS Settings EBS has no per-service override settings. These account-wide settings apply to EBS volumes: * **Metric lookback** and **Min savings**, under **Advanced**. * **Spend coverage**, **Cost change threshold**, and **Max result age**, under **Advanced**. * **Analysis cost floor** and **Monthly metrics budget**, under **Spend guardrail**. **CPU percentile**, **CPU headroom**, **Memory headroom**, and **Min savings percent** do not apply to EBS volumes. ## EBS Finding Reasons Rightsize lists the reasons behind each finding. Check these before you act on a recommendation, to understand what it is based on. | Reason | Meaning | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | **Volume IOPS Overprovisioned** | You pay for provisioned IOPS that an active volume does not use. | | **Volume Throughput Overprovisioned** | You pay for provisioned throughput that an active volume does not use. | | **Cheaper volume type available** | A cheaper volume type offers the same capacity. | | **Burst capacity verified** | This reason appears with every IOPS or throughput reduction. The volume's peak read and write traffic, plus 25%, fits within the baseline. | | **Review before deleting** | Rightsize recommends removing this volume. | | **Idle** | The volume shows no meaningful read or write activity. | | **No observed activity** | All of the volume's metrics came back empty, but over too few billed days to count as idle. Rightsize does not lower the volume's IOPS or throughput. | # ECS Learn how Rightsize sizes ECS services on Fargate. On AWS accounts, Rightsize sizes ECS services that run on Fargate. It recommends the CPU and memory configuration that a service's tasks need, based on how the tasks use CPU and memory. ## What Rightsize Covers Rightsize sizes Fargate tasks on Linux and x86. It sizes each ECS service as a whole, using the cluster and service names in the tasks' billing tags. A task without a service tag is not sized. ECS tasks that run on EC2 instances are billed as EC2, so Rightsize sizes those instances on the EC2 tab. See [EC2](/docs/features/rightsize/ec2). ## How Rightsize Sizes a Service Rightsize reads the ECS CPU utilization and memory utilization metrics over the lookback window. It measures both at the **CPU percentile** setting, which is P99 by default. It then recommends the cheapest valid Fargate CPU and memory configuration where both measured values fit under the sizing target: ``` base target = 100% − headroom target = base target × max(volatility floor, 1 − volatility sensitivity × CoV) ``` CoV is the coefficient of variation of the usage: its standard deviation divided by its mean. A spiky workload has a higher CoV. A higher CoV lowers the target, so the recommended configuration has more spare capacity. You can change the CPU percentile, the headroom, and the volatility values in [ECS Settings](/docs/features/rightsize/ecs#ecs-settings), below. Rightsize recommends a larger configuration when daily average usage exceeds the base target on at least 25% of observed days. This must happen on at least two days. A smaller configuration is not recommended when it saves less than **Min savings percent**, which is 5% by default. Rightsize does not recommend a stop for an ECS service. ## Using the ECS Tab The summary metrics on the ECS tab are Available Savings, Idle, Over provisioned, Under provisioned, Tagged, and Untagged. The Idle tile always shows 0, because Rightsize does not mark an ECS service as idle. Click a row's **AI Suggestion** button to open the service's panel: * **Current State** - the service name, and its current CPU and memory configuration. * **Noros Recommendation** - the recommended CPU and memory configuration. * **Monthly Savings** - the estimated saving. * **Findings** - the reasons behind the recommendation, as chips. Below the panel sections, a chart shows the service's CPU and memory history. ## ECS Settings In **Settings**, open **Per-service overrides** and select **ECS**. An empty field uses the account default. * **CPU percentile** - the usage percentile Rightsize sizes against. P99 excludes the highest 1 percent of readings. The Balanced default is P99. * **CPU headroom** - spare CPU kept above CPU usage at the CPU percentile. The Balanced default is 20%. * **Memory headroom** - spare memory kept above memory usage at the CPU percentile. The Balanced default is 20%. * **Volatility sensitivity** - how much variable usage lowers the sizing target. 0 does not lower it. 1 lowers it the most. The default is 0.5. * **Volatility floor** - the lowest value the target can be lowered to. 0.5 keeps at least half of the base target. The default is 0.5. * **Min savings percent** - Rightsize does not recommend a smaller configuration that saves less than this share of what the service costs today. The Balanced default is 5%. ## ECS Finding Reasons Rightsize lists the reasons behind each finding. Check these before you act on a recommendation, to understand what it is based on. * **CPU Overprovisioned / Underprovisioned** - the finding is based on CPU usage. * **Memory Overprovisioned / Underprovisioned** - the finding is based on memory usage. * **Volatile usage** - CPU usage varies, so Rightsize lowered the sizing target. * **Untagged task — tag the service for utilization** - the task has no service tag, so Rightsize cannot attribute its usage to a service and does not size it. When a task has no service tag, the **AI Suggestion** column shows "Tag this task's service to get its utilization." # Lambda Learn how Rightsize finds savings on Lambda functions. On AWS accounts, Rightsize identifies Lambda functions that cost more than they need to. It recommends a move from x86 to arm64, less provisioned concurrency, or a review of standing capacity that a function did not use. Rightsize starts from billing data, then uses CloudWatch metrics to confirm a provisioned concurrency trim. ## What Rightsize Recommends Rightsize makes three kinds of recommendation for a Lambda function: * **Review unused standing capacity** - the function is billed for provisioned concurrency or SnapStart cache, with zero billed requests and zero billed duration across at least 10 billed days. Rightsize reads this from billing data. The saving is the cost of that capacity. The finding state is **Over provisioned**, and Rightsize adds the reason **Idle**. * **Lower provisioned concurrency** - the function uses less provisioned concurrency than you pay for. Rightsize sets a target from the highest use observed across the function's qualifiers, plus **Provisioned concurrency headroom**. That headroom is a setting, 20% by default. See [Lambda Settings](/docs/features/rightsize/lambda#lambda-settings), below. The provisioned concurrency configuration must be unchanged since the start of the lookback window. * **Move to arm64** - the function ran only on x86 in the billed period, and the same work costs less on arm64. The finding state is **Not optimized**. Rightsize records a function's memory use as evidence. It does not recommend a different memory size. ## How Rightsize Checks a Function ### Provisioned Concurrency Rightsize reads the function's invocations, errors, throttles, provisioned concurrency utilization, and provisioned concurrency spillover invocations. It does not recommend a provisioned concurrency trim in these cases: * The error rate or the throttle rate is above 1%. Rightsize adds the reason **Errors or throttling detected**. * Any invocation spilled over the provisioned capacity. Rightsize adds the reason **Provisioned concurrency spillover detected**. ### arm64 Savings The arm64 saving is the function's x86 duration spend, multiplied by the price difference between the two architectures: ``` arm64 saving = x86 duration spend × (1 − arm64 rate ÷ x86 rate) ``` Rightsize uses your account's observed x86 and arm64 rates when the ratio between them is within 10% of the ratio between the published rates for the region. Otherwise, it uses the published rates. The panel shows which rates it used. Rightsize makes no arm64 recommendation in a region without published arm64 rates. An arm64 saving is a price estimate, and a change of architecture can change how long a function runs. ### Memory Memory use comes from Lambda Insights. When no other recommendation applies, and the function has enough memory samples from a single memory allocation, Rightsize adds the reason **Memory measured**. The samples must cover at least **Minimum observed days**, a setting that is 7 days by default. See [Lambda Settings](/docs/features/rightsize/lambda#lambda-settings), below. ## Using the Lambda Tab The summary metrics on the Lambda tab are Available Savings, Idle, Over provisioned, Optimized, Not Optimized, Tagged, and Untagged. Click a row's **AI Suggestion** button to open the function's panel: * **Current State** - the function name, its billed architecture, billed requests, billed duration in GB-seconds, and the cost lines that apply to it. These include duration, requests, provisioned concurrency, SnapStart, and ephemeral storage costs. * **Noros Recommendation** - one of these: * **Architecture** set to arm64, with a note on which rates the estimate uses. The note ends with "Billing cannot verify runtime or dependency compatibility — review before migrating." * The current and recommended provisioned concurrency, for each qualifier. * **Review unused standing capacity**. * **Monthly Savings** - the estimated saving. * **Findings** - the reasons behind the recommendation, as chips. When memory data is available, the panel shows a chart. Choose **Memory used** or **Memory allocated** to change the metric. ## Lambda Settings In **Settings**, open **Per-service overrides** and select **Lambda**. An empty field uses the account default. * **Provisioned concurrency headroom** - spare provisioned concurrency kept above the highest use seen, before a trim. The Balanced default is 20%. * **Memory headroom** - recorded with the function's memory evidence. It does not change a recommendation. The Balanced default is 20%. * **Minimum observed days** - the days that must contain memory samples before the peak counts as evidence. The Balanced default is 7. These settings are separate from the account-wide CPU and memory headroom. ## Lambda Finding Reasons Rightsize lists the reasons behind each finding. Check these before you act on a recommendation, to understand what it is based on. | Reason | Meaning | | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | **Provisioned concurrency underused** | The busiest observed period, with headroom, still leaves provisioned capacity unused. | | **Provisioned concurrency spillover detected** | Invocations went past the provisioned capacity during the window, so Rightsize does not recommend a trim of that capacity. | | **Errors or throttling detected** | The function showed errors or throttling during the window, so Rightsize does not size against that usage. | | **Arm64 migration candidate** | A function ran only on x86 in the billed period, and the same work costs less on arm64. | | **Compatibility not verified** | Billing records cannot confirm that a function's code and dependencies run on arm64, so the migration stays a review. | | **Review unused standing capacity** | Rightsize recommends removing standing capacity that a function did not use. | | **No invocations this period** | A function billed for capacity, with zero billed requests and zero billed duration across the observed period. | | **Memory measured** | Rightsize recorded a function's observed memory use as evidence for its result. | | **Memory usage unavailable** | Rightsize received no memory data for this function, so the recommendation does not use memory. | | **Memory evidence incomplete** | Some memory data arrived for this function, but not enough to size against, so the recommendation does not use memory. | | **Idle** | The function is billed for standing capacity with no invocations. | # RDS Learn how Rightsize reviews RDS databases. Rightsize reviews each Amazon RDS DB instance on your AWS accounts, including the instances in an Aurora cluster. Each RDS finding is a review where it suggests a class for you to evaluate. Confirm each suggestion before you act on it. ## How Rightsize Reviews a Database Rightsize reads these CloudWatch metrics for each database over the lookback window: CPU utilization, freeable memory, swap usage, database connections, read and write IOPS (input/output operations per second), and read and write throughput. The checks below use settings that you can change in [RDS Settings](/docs/features/rightsize/rds#rds-settings), below. The values given here are the Balanced defaults. A database needs samples on at least the number of days set in **Minimum observed days**, which is 14 by default, with at least 90% hourly coverage. Rightsize then applies these checks in order, and the first one that matches is what Rightsize anchors on for that instance: * **Review a larger class** - daily average CPU exceeds **CPU threshold for a larger class**, which is 90% by default, on at least 25% of observed days, and on at least two days. Rightsize suggests the next class in the same family with more memory, for the same engine, deployment, and license. The finding state is **Under provisioned**. * **Reservation locks this size** - on SQL Server, and on Oracle with a license-included model, a Reserved Instance matches the exact class size. When one covers the database, or when a commitment covers it and Rightsize cannot identify that commitment, Rightsize does not review another class. The finding state is **Not analyzed**. * **Review possible memory pressure** - the database was low on available memory and was using swap in the same hours. Rightsize does not suggest a class for this review, and the finding state is Not optimized. Rightsize flags possible memory pressure when all of these are true: * In an hour, available memory fell below **Memory pressure: available memory floor** while swap in use rose above **Memory pressure: swap ceiling**. By default, these are 5% and 10% of the instance's total memory. * This happened in at least half of a day's measured hours. Only days with at least 20 hours of both memory and swap samples count. * Such days make up at least 25% of measured days, and there are at least two of them. * The measured days number at least Minimum observed days, and neither the memory history nor the swap history is sparse. * **Review a smaller class** - a smaller class passes the CPU, memory, and connection checks below. Rightsize considers classes in the same family with less memory and no more vCPUs, and suggests the one with the most memory that passes. The finding state is **Over provisioned**. * **No change recommended** - none of the reviews above apply. The finding state is **Optimized**. A smaller class must pass three checks: * **CPU** - the highest observed CPU utilization, scaled to the smaller class's vCPU count, stays at or below **CPU limit for a smaller class**, which is 70% by default. For databases, Rightsize uses the highest observed value, so one busy hour counts. * **Memory** - the smaller class holds the highest estimated memory use plus **Memory headroom**, which is 25% by default. Estimated memory use is the allocated memory minus the lowest freeable memory. Rightsize runs this check only when the memory history is not sparse. * **Connections** - for PostgreSQL, Aurora PostgreSQL, and MySQL, the engine's default connection limit on the smaller class is at least the highest observed connection count. Rightsize skips this check when the connection history is sparse. ## What the Review Panel Shows Click a row's **AI Suggestion** button to open the database's review panel. The button appears on every reviewed database, including **Optimized** ones, so you can see the evidence behind each result. The panel has up to three sections. **Findings** appears only when the review has reasons. * **Current State** - the database's instance class, engine, deployment, and license, then the evidence behind the review. The evidence covers observed days and hour coverage, CPU peak, and allocated and estimated memory use. It also covers memory pressure, heavy swap use, maximum connections, and maximum read and write IOPS and throughput. When Rightsize suggests a class and knows the engine's default connection limit, the section also shows the assumed default connection limit on that class. * **Noros Recommendation** - the **Review** field shows the suggested class, for example "Review a smaller class: db.r8g.xlarge". When a class is suggested, the card also shows **Review Target Memory**, the memory of that class. The card ends with the modeled reduction, described below. * **Findings** - the reasons behind the review, as chips. Below the sections, a chart shows the database's utilization history. Choose CPU, Database connections, Read iops, Write iops, Read throughput, or Write throughput to change the metric. ## Modeled Reduction The modeled reduction is the monthly price difference between the current class and the suggested class. The card shows it as **Modeled reduction:**, then the amount per month, then "a model of the price gap, not a saving". Rightsize calculates it at the rates you pay today: ``` modeled reduction = covered share × (current committed price − target committed price) + (1 − covered share) × (current on-demand price − target on-demand price) ``` The covered share is the part of the database's instance hours that a commitment covered. When a commitment covers part of the database, the card also shows which rates apply. For a Database Savings Plan, the line ends with "(priced under your Database Savings Plan, weighted by coverage)". For a Reserved Instance, it ends with "(committed rates weighted by coverage)". The card shows "Modeled reduction: not available" when there is no class to price, as in a memory pressure review. It also shows it when a required rate is unknown, or when Rightsize cannot identify the commitment that covers the database. ## RDS Settings In **Settings**, open **Per-service overrides** and select **RDS**. These settings control how Rightsize reviews databases. An empty field uses the account default. * **CPU limit for a smaller class** - Rightsize suggests a smaller class only when the projected CPU on that class stays at or below this percentage. The Balanced default is 70%. * **CPU threshold for a larger class** - Rightsize suggests a larger class when daily average CPU exceeds this percentage on at least 25% of observed days, and on at least two days. The Balanced default is 90%. * **Memory headroom** - the spare memory kept above the highest memory use seen. A higher value gives a larger, safer class. The Balanced default is 25%, which is separate from the account-wide memory headroom. * **Minimum observed days** - the minimum number of days of CPU, memory, swap, and connection samples. Rightsize also requires at least 90% hourly coverage. The Balanced default is 14. * **Memory pressure: available memory floor** and **Memory pressure: swap ceiling** - both are a percentage of the instance's total memory. Rightsize flags possible memory pressure in an hour when available memory falls below the floor and swap in use rises above the ceiling. The defaults are 5% and 10%, and they are the same for every profile. ## RDS Review Reasons You must confirm each RDS suggestion before you act on it, because a database resize depends on facts that North has no data for. For example: * **Memory** - a smaller RDS class has less memory. A database uses its spare memory as a cache, so its metrics cannot show how the database runs with less. * **Configuration** - you know each database's configuration, such as its connection limits, storage setup, and engine version. Rightsize does not read this configuration today. For each RDS review, Rightsize lists the checks that it could not complete, and facts about the database that affect a class change. Use these reasons to see what to confirm before you change a database's class. | Reason | Meaning | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Review only — no change is recommended** | The finding is a review. Rightsize suggests a class to evaluate and does not recommend a change. | | **Memory fit not validated** | The suggested class holds the highest observed memory use plus headroom. Metrics alone cannot confirm that the database runs well on that class. | | **Sparse memory history** | Memory samples cover fewer days than **Minimum observed days**, or less than 90% of hours, so the suggested class was not checked against memory use. | | **No memory history** | No memory samples were returned, so the suggested class was not checked against memory use. | | **Assumes the default connection limit** | The connection check uses the engine's default connection limit on the suggested class. A custom parameter group can set a different limit. | | **Connection limit unknown** | Rightsize has no default connection limit for this engine, so the suggested class was not checked against connections. This applies to Aurora MySQL, MariaDB, Oracle, SQL Server, and Db2. | | **No connection history** / **Sparse connection history** | Connection samples are missing, or cover fewer days than **Minimum observed days** or less than 90% of hours, so the suggested class was not checked against connections. | | **Storage I/O capacity not checked** | The suggested class was not checked against the observed storage IOPS and throughput. | | **Class availability for this engine version not verified** | The suggested class may not be available for the engine version that the database runs. | | **Assumes the default CPU configuration** | SQL Server only. Rightsize uses the class's default vCPU count. If you set a different count with Optimize CPU, billing data does not show it. | | **Reservation keeps applying within the class type** | A Reserved Instance covers the database. After a move to a smaller class, the reservation applies only within the same class type, region, and engine. | | **A commitment could not be resolved** | A commitment covers part of the database's usage, and Rightsize could not identify it. The modeled reduction is not available. | | **CPU sustained near capacity** | Daily average CPU exceeded **CPU threshold for a larger class** on at least 25% of observed days, and on at least two days. | | **No larger class priced** | CPU is near capacity, and Rightsize found no priced larger class to suggest. | | **Possible memory pressure** | Low available memory and high swap use occurred in the same hours on at least 25% of measured days, and on at least two days. | | **Swap in use over sustained periods** | Heavy swap use occurred on at least 25% of measured days, and on at least two days. It does not change the review. | ## Databases Without a Review When Rightsize does not review a database, the **AI Suggestion** column shows a message in place of the button. | Case | Message in the AI Suggestion column | Meaning | | -------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Class not supported | "This instance's class is not supported for review." | The database is a serverless instance, part of a Multi-AZ DB cluster with readable standbys, or a class with no published specification. | | Deployment not identified | "This instance's deployment could not be identified from billing." | The instance's deployment or engine could not be identified from billing. | | No instance hours billed | "No review for this instance." | Billing shows no instance hours for the database in the period, for example when only storage or backups were billed. | | Price not found | "No price was found for this instance's engine, deployment and licence combination." | No price was found for the instance's engine, deployment, and license combination. | | Reservation locks the size | "A reservation locks this instance to its current size, so no other class was reviewed." | See **Reservation locks this size**, above. | | Not enough history | "Not enough utilization history was available to review this instance." | The database has fewer days of samples than **Minimum observed days**, or less than 90% hourly coverage. | | Metrics unavailable | "No utilization metrics were returned for this instance." | No CPU utilization data was returned for the instance. | | Monitoring access denied | "Grant monitoring access to size this resource." | Rightsize does not have the monitoring grant needed to read the database's metrics. See Monitoring Access on the [Rightsize](/docs/features/rightsize) page. | An RDS review does not check storage I/O capacity, custom connection limits, or class availability for your engine version. Confirm these before you change a database's class. # Compute Engine Learn how Rightsize sizes Compute Engine instances, and the access it needs. On GCP accounts, Rightsize sizes Compute Engine VM instances. It recommends a smaller or cheaper machine type, a larger one when an instance runs near capacity, or a stop for an idle instance. ## What Rightsize Covers Rightsize sizes Compute Engine VM instances, including the nodes of GKE (Google Kubernetes Engine) Standard node pools, which GCP bills as Compute Engine instances. It sizes each instance on its own. It does not size persistent disks. Rightsize does not suggest a shared-core E2 machine type (e2-micro, e2-small, or e2-medium) as a target. For an Arm machine type (t2a, c4a, or n4a), Rightsize recommends only another Arm machine type. GPU machine types (g2, a2, and a3) are not sized. ## Grant Monitoring Access Rightsize reads utilization from Cloud Monitoring. It needs the Monitoring Viewer role (`roles/monitoring.viewer`), granted to the same North principal that reads your billing export. With the Monitoring Viewer role, North has read-only access to Cloud Monitoring data and configurations, such as dashboards and alerting policies. To grant access, complete these steps in the Google Cloud console: 1. Open the metric scope for your billing project. 2. Add all the projects you want Rightsize to analyze to the scope. 3. Grant North the Monitoring Viewer role. Monitoring access is granted per project. A project outside the metric scope is not analyzed. When Rightsize cannot read metrics for any resource on the account, the page shows **Connect Cloud Monitoring to analyze this account**. Select **Grant access** to start the grant. When only some projects are missing access, a banner above the page lists how many resources are excluded and which projects they belong to. Select **Show affected resources** to see them, or **Grant access** to complete the grant. ## How Rightsize Sizes an Instance Rightsize reads these Cloud Monitoring metrics over the lookback window: CPU utilization, network bytes sent and received, and memory used. On a GCP account, the maximum **Metric lookback** is 42 days. Metric lookback is an account-wide setting, under **Advanced** in Settings. Memory data comes from the Ops Agent. Without the agent, Rightsize can lower the vCPU count but never lowers memory. The panel then shows "Sized on CPU only. Install the Ops Agent to include memory." ### The Sizing Target Rightsize measures CPU and memory at the **CPU percentile** setting, which is P99 by default. A candidate machine type fits when that measured usage, scaled to the candidate's vCPU and memory, stays at or below the target: ``` base target = 100% − headroom target = base target × max(volatility floor, 1 − volatility sensitivity × CoV) ``` CoV is the coefficient of variation of the usage: its standard deviation divided by its mean. A spiky workload has a higher CoV. A higher CoV lowers the target, so the recommended size has more spare capacity. For example, with the Balanced defaults (CPU headroom 20%, volatility sensitivity 0.5, volatility floor 0.5) and a CoV of 0.4: ``` base target = 100% − 20% = 80% target = 80% × max(0.5, 1 − 0.5 × 0.4) = 80% × 0.8 = 64% ``` You can change the CPU percentile, the headroom, and the volatility values in [Compute Engine Settings](/docs/features/rightsize/compute-engine#compute-engine-settings), below. Rightsize then recommends the cheapest machine type that fits. Every candidate must also pass the network check, and a candidate with fewer vCPUs must also pass the peak load check: * **Peak load** - for a candidate with fewer vCPUs, the highest CPU utilization in the window, scaled to the candidate, stays below 95%. * **Network** - the candidate's network capacity is at least twice the observed peak, in either direction. Rightsize models a machine type's network capacity as 2 Gbps per vCPU, up to 32 Gbps, or up to 16 Gbps for E2 and N1. Rightsize runs the network check only when the metric data has periods shorter than one hour. When a check excludes a smaller type that would otherwise have been recommended, Rightsize adds a **Limited by** reason to the finding. ### Larger Machine Types Rightsize recommends a larger machine type when daily average usage exceeds the base target on at least 25% of observed days. This must happen on at least two days. The finding state is **Under provisioned**. ### Idle Instances and Stops Rightsize recommends a stop for an instance only when all of these are true. The three thresholds are settings that you can change in [Compute Engine Settings](/docs/features/rightsize/compute-engine#compute-engine-settings), below. * Average CPU stays at or below **Idle CPU ceiling**, which is 10% by default. * CPU stays steady, with a CoV at or below **Idle volatility ceiling**, which is 0.35 by default. * Network egress stays at or below 1 MB per sample at the CPU percentile, and no single network sample in either direction exceeds 25 MB. * The highest CPU utilization, and memory use where measured, never passed **Stop safety peak**, which is 40% by default. The saving for a stop is an estimate, based on the instance's cost in the month that the results cover. You continue to pay for any Committed Use Discount that covers the instance, and for its persistent disks. ## Using the Compute Engine Tab The summary metrics on the Compute Engine tab are Available Savings, Idle, Over provisioned, Under provisioned, Tagged, and Untagged. Use the **All accounts** filter to narrow the table to one project. Click a row's **AI Suggestion** button to open the instance's panel: * **Current State** - the instance name and its machine type. * **Noros Recommendation** - the recommended machine type, or **Stop instance**. * **Monthly Savings** - the estimated saving. For an instance covered by a commitment, the card also shows "Estimated at your commitment's blended rate." * **Findings** - the reasons behind the recommendation, as chips. Below the panel sections, a chart shows the instance's utilization history. Choose CPU, Network egress, Network ingress, or Memory to change the metric. ## Compute Engine Settings In **Settings**, open **Per-service overrides**. On a GCP account, the only service is **Compute Engine**. An empty field uses the account default. | Setting | What it controls | Balanced default | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | **CPU percentile** | The usage percentile Rightsize sizes against. P99 excludes the highest 1 percent of readings. | P99 | | **CPU headroom** | Spare CPU kept above CPU usage at the CPU percentile. A higher value gives a larger, safer size. | 20% | | **Memory headroom** | Spare memory kept above memory usage at the CPU percentile. A higher value gives a larger, safer size. | 20% | | **Volatility sensitivity** | How much variable usage lowers the sizing target. 0 does not lower it. 1 lowers it the most. | 0.5 | | **Volatility floor** | The lowest value the target can be lowered to. 0.5 keeps at least half of the base target. | 0.5 | | **Idle CPU ceiling** | The average CPU at or below which an instance can count as idle. | 10% | | **Idle volatility ceiling** | How steady CPU must be for an instance to count as idle. A lower value requires steadier CPU. | 0.35 | | **Stop safety peak** | Rightsize never recommends a stop for an instance whose CPU or memory ever passed this. | 40% | | **Min savings percent** | Rightsize does not recommend a smaller or cheaper type that saves less than this share of what the resource costs today. The resource shows as Optimized instead. Stops and larger types are not affected. | 5% | ## Compute Engine Finding Reasons Rightsize lists the reasons behind each finding. Check these before you act on a recommendation, to understand what it is based on. | Reason | Meaning | | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **CPU Overprovisioned / Underprovisioned** | The finding is based on CPU usage. | | **Memory Overprovisioned / Underprovisioned** | The finding is based on memory usage. | | **Volatile usage** | CPU usage varies, so Rightsize lowered the sizing target. | | **Limited by peak load** | A smaller size passed the CPU percentile test, but the highest peak in the window exceeds its capacity. | | **Limited by network throughput** | The recommended size is the smallest one with enough network capacity for the observed peak. | | **Limited by missing memory data / No memory metrics** | No memory agent is reporting data, so the recommendation is bounded by CPU alone. The instance's panel links to the install guide for the Ops Agent. | | **Idle** | The instance shows no meaningful activity. Rightsize recommends a stop. | | **Commitment limits sizing to this family** | Because of the covering commitment, Rightsize recommends only machine types in the instance's current family. | | **Requires Hyperdisk and gVNIC** | The recommended machine type is in the n4, n4a, n4d, c4, c4a, or c4d family, and the current machine type is not. These families require Hyperdisk and gVNIC (Google Virtual NIC). Check these before you change the machine type. | | **Extended memory pricing unavailable** | The instance is a custom machine type with extended memory, and Rightsize has no rate for that configuration. | | **GPU not sized** | The instance has GPU accelerators. Rightsize sizes on CPU, memory, and network, so it does not size GPU instances. | When Rightsize cannot read an instance's metrics, the **AI Suggestion** column shows "Grant monitoring access to size this resource." See Grant Monitoring Access, above. # Anomalies Learn what North flags as a cost anomaly, how it grades severity, and how to tune detection for your account. North watches your daily cost and reports the days that do not fit your own history. Detection runs on its own. There is nothing to configure before you see results. Open the page from **Analyze > Anomalies**. {% embed url="" %} {% hint style="info" %} AWS accounts need Advanced Permissions for this page. If those permissions are missing, the page states so instead of showing results. See [AWS permissions](/docs/getting-started/permissions-required/aws-permissions) to grant them. {% endhint %} ## What North Flags North groups your cost by linked account, service, and usage type. Where it can attribute a change to a single resource, it reports that resource as well. Inside each group, North compares every day against the running average and spread of that group's own history. A day is flagged when two conditions hold together: * The day sits far from the group's history, measured as a z-score, or the day-over-day change is large against the group's average. * The dollar change clears a floor. That floor is the larger of your cost change threshold and your critical percentage applied to the group's average daily cost. Each flagged day is a spike or a dip. * A **spike** is a day where cost went up. * A **dip** is a day where cost went down. A dip can point to a deleted resource, an expired commitment, or an unplanned shutdown. Two cases are excluded on purpose. A dip that continues a fall already under way over the previous three days is not reported. The first day a service ever has cost is masked, because a new service is expected to look like a spike. ## Severity There are two severity levels. | Severity | Meaning | | ------------ | ---------------------------------------------------------------------------------------------------- | | **Critical** | The cost increase is larger than your critical percentage applied to the group's average daily cost. | | **Medium** | Every other flagged day. | Only spikes can be Critical. A dip is a decrease, so it never passes the Critical test, and a dip is always Medium. A service or a resource takes the highest severity of its own days. One Critical day makes the whole anomaly Critical. ## Pattern Recognition North scans each group's history for spikes and dips that repeat every week or every month. Where a flagged day matches one of those patterns, North labels the day and gives the reason. Use this to separate a monthly billing cycle or a scheduled weekend job from a real problem. The list marks any anomaly that has pattern matches. Open the anomaly, then hover a marked point on the chart to read the explanation. ## Reading the Page Four figures sit above the list: **Total Anomalies**, **Critical**, **Medium**, and **Total Cost Change**. Each figure counts what your filters currently show, and none of them counts a masked anomaly. Filter the list by service and by linked account. Google Cloud accounts show Project in place of Linked Account. The search box narrows the list further. Each row shows the severity, the service, the usage type, the linked account, the cohort, the number of anomaly days, the number of resources, and the most recent anomaly date. Click a column heading to sort by it. Click a row to open the anomaly. The detail panel gives you: | Field | Meaning | | ------------------ | ------------------------------------------------------------------------------------------------------------- | | **Severity** | Critical or Medium, for this anomaly. | | **Spikes** | The number of days where cost went up. | | **Dips** | The number of days where cost went down. | | **Patterns** | The number of pattern matches across those days. A match suggests an expected movement rather than a problem. | | **Largest Change** | The largest single-day cost increase in the anomaly. | Below the fields, a chart plots the last 90 days of cost for the group, with each anomalous day marked. ## Settings Click **Account Preferences**, the gear control at the top right of the page, to tune detection. The settings apply to the whole account. You need write permission on anomalies to change them. | Setting | What it does | Default | Minimum | | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ------- | ------- | | **Cost change threshold** | The minimum dollar amount for a change to count as an anomaly. | $10.00 | $10 | | **Percentage increase for critical alerts** | The minimum cost increase, measured against the group's average daily cost, for an anomaly to be Critical. | 50% | 1% | | **Limit number of services to show anomalies for** | The number of services North reports anomalies on, ranked by size. | 20 | 1 | Raise the cost change threshold to cut small anomalies. Raise the critical percentage to reserve Critical for larger increases. Lower the service limit to keep the page focused on your biggest spenders. ## Acting on an Anomaly Open an anomaly and use one of the two controls at the bottom of the panel. * **Resolve** marks the anomaly as handled. * **Not a good recommendation?** marks it as one you want ignored. Both move the anomaly to the bottom of the list and take it out of the four figures above. North records which action you took, and uses that record when it evaluates the same group again. To bring in other people, use the share control. You can send an anomaly by email, post it to Slack, or open a Jira issue from it. Select several anomalies with the row checkboxes to share them together. # GreenOps Learn about your direct carbon emissions and how to offset it with North.cloud. {% embed url="" %} GreenOps by North provides a comprehensive, zero-setup dashboard to continuously monitor and reduce your cloud carbon footprint. ### Accessing the GreenOps Dashboard To get started, click **Analyze** in the top navigation of app.north.cloud, then select **GreenOps**. No technical configuration or onboarding is required. GreenOps begins analyzing your footprint automatically in the background. ### What You'll See On your GreenOps dashboard, you'll find: * **Last Month’s Carbon Emissions**: A detailed profile of your cloud carbon output, broken down by resource. * **Water & Power Usage Estimates**: Calculations of associated energy and water consumption for your workloads. * **Offset Guidance**: An estimate of the carbon credits required to achieve carbon neutrality for your cloud usage. ### Filtering and Exploring Your Data GreenOps offers flexible filters so you can: * Adjust reporting windows. * Drill down into specific regions, services, or workloads. * Identify areas of high power usage or carbon intensity for targeted optimization. ### Going Carbon Neutral To purchase verified carbon offsets through North: 1. Click the **Go Carbon Neutral** button in the top right of the GreenOps dashboard. 2. Follow the authorization prompts to submit your request. Upon completion, North will provide full documentation. # Cost Loops Learn what a Cost Loop is, which SaaS providers North supports today, and which ones are coming. A Cost Loop brings SaaS spend into North alongside your cloud accounts. Your warehouse bill, your AI API bill, and your observability bill then sit in the same views as your AWS, Google Cloud, and Azure spend, with the same charts, the same allocation model, and the same filters. A Cost Loop is read-only. North reads usage and cost from the provider. North does not change anything in your provider account. You attach a Cost Loop to an organization that already has a cloud account. Add one at any time. ## Available Today | Provider | What it covers | How North authenticates | | --------- | ------------------------------------- | ----------------------- | | Snowflake | Warehouse compute and storage spend | RSA key pair | | Anthropic | Claude usage | API key | | OpenAI | Organization-wide API usage and spend | Admin API key | | Datadog | Observability and APM spend | Service Access Token | Review the setup guide to get started on each one: {% content-ref url="/pages/KnkHzPqzhm5D5uJZI7C9" %} [Snowflake](/docs/features/cost-loops/snowflake) {% endcontent-ref %} {% content-ref url="/pages/q8oZeYUVEuhOMcwwKxy8" %} [Anthropic](/docs/features/cost-loops/anthropic) {% endcontent-ref %} {% content-ref url="/pages/Xf4a0TANX2ATGXzlwHG7" %} [OpenAI](/docs/features/cost-loops/openai) {% endcontent-ref %} {% content-ref url="/pages/6OVAz9P0iPYraLpfyAkI" %} [Datadog](/docs/features/cost-loops/datadog) {% endcontent-ref %} ## Coming Soon More providers are on the way. | Provider | What it will cover | | ------------- | ------------------------------- | | Databricks | Lakehouse and jobs spend | | MongoDB Atlas | Cluster and data-transfer spend | ## How to Add a Cost Loop 1. Open **Settings**, then **Integrations**. 2. Click **Add accounts**. 3. Under **Cost Loops**, select the provider you want. 4. Follow that provider's setup guide. ## Naming Your Connection Every Cost Loop asks for a connection name. Choose something you will recognize later. That name is what labels the provider's card on your homepage, and what identifies the connection when you pick Cost Loops for a Streams view or for Visibility. ## What Cost Loops Do Not Cover Two limits are worth knowing before you plan around Cost Loops. **Cost Loops carry no commitments.** North covers cloud spend with Savings Plans, Reserved Instances, and CUDs. None of that applies to a Cost Loop. A Cost Loop reports spend. It does not buy anything against that spend, and Cost Loop spend does not appear in your coverage or your Effective Savings Rate. **Commitments work on one cloud account at a time.** You can combine a cloud account and several Cost Loops in a single Streams view or Visibility selection. Commitments do not work that way. They operate on one cloud account, so a multi-account view is for reporting rather than for buying coverage. ## Where the Data Appears Once a Cost Loop is connected, its spend shows up on your homepage, in Streams, and in Visibility, and you can ask Noros about it. The detail available differs by provider. {% content-ref url="/pages/MOGdLqJ1QntWx8i6nM2I" %} [Viewing Cost Loop Data](/docs/features/cost-loops/viewing-cost-loop-data) {% endcontent-ref %} # Snowflake Learn how to connect your Snowflake account to North as a Cost Loop. Setup the Snowflake Cost Loop integration in North to see your wrehouse compute and storage spend. North authenticates with Snowflake as a dedicated read-only service user, using an RSA key pair. North generates the key pair in your browser and builds a setup script that already carries your public key. You run that script once in Snowflake. North keeps the private key. ## Before You Start You need a Snowflake user that holds both **ORGADMIN** and **ACCOUNTADMIN**. If you do not hold ORGADMIN, you can still complete the setup. Only the first three statements in the script need it, and they run once per account. Ask your organization administrator to run those three, delete them from your copy, then run the rest yourself as ACCOUNTADMIN. You also need your Snowflake account identifier. Use the `ORGID-ACCOUNTID` form, for example `MYORG-PROD01`. The legacy `locator.region.cloud` form still works. ## What the Script Creates The script is idempotent. You can run it again safely, and re-running never removes the registered public key. | Object | Purpose | | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | `NORTH_RO_WH` warehouse | An XSMALL warehouse used only by the service user. It auto-suspends after 60 seconds and resumes on demand. | | `NORTH_RO` role | The read-only role North uses. | | `NORTH` database and `NORTH.PUBLIC` schema | Holds the secure views North reads through. | | `NORTH_RO` user | The service identity. It is created with `TYPE = SERVICE`, so password authentication is structurally impossible and human MFA policies do not apply to it. | | Secure views in `NORTH.PUBLIC` | Column-pruned wrappers over Snowflake's own usage and billing views. | | `NORTH_RO_NETWORK_POLICY` | Restricts the service user to North's egress IP addresses. It applies to `NORTH_RO` only. Your own users and administrators are unaffected. | ## What North Can and Cannot Read North connects only as `NORTH_RO`, and that role has no direct access to `SNOWFLAKE.*`. It reads the secure wrapper views instead, and those views are built to exclude sensitive columns. **Excluded from every view:** `QUERY_TEXT`, `USER_NAME`, and per-user Cortex identifiers. North sees query identifiers and resource metrics for attribution. North does not see the SQL you ran or who ran it. **Bounded to 365 days.** Every time-based view is filtered to the last 365 days. The views cover organization billing, rates, and balances; warehouse and serverless compute; storage; data transfer; query-level attribution; and Cortex AI usage. Some views depend on your Snowflake edition or region. The script skips any source that does not exist on your account rather than failing, and reports which views it created and which it skipped. ## Connect Snowflake {% stepper %} {% step %} ### Open the connect screen Open **Settings**, then **Integrations**, then **Add accounts**. Under **Cost Loops**, select **Snowflake**. North generates your RSA key pair at this point and fills your public key into the script shown on screen. {% endstep %} {% step %} ### Run the setup script in Snowflake Click **Copy**. Open a Snowflake worksheet and run the whole script as a user holding both ORGADMIN and ACCOUNTADMIN. The script's final statements show the grants and the IP allowlist attached to `NORTH_RO`, so you can confirm the result before you leave Snowflake. {% endstep %} {% step %} ### Enter your connection details Fill in the two fields: * **Connection name.** A label to recognize this account by. It becomes the card title on your homepage. * **Account identifier.** Your Snowflake account identifier, in `ORGID-ACCOUNTID` form. {% endstep %} {% step %} ### Confirm and connect Select the checkbox confirming you have run the script, then click **Connect**. {% hint style="warning" %} Run the script before you connect. If you connect first, the next data pull fails until the setup SQL is in place. {% endhint %} {% endstep %} {% endstepper %} ## After You Connect Snowflake spend appears on your homepage as a card carrying your connection name. See [Viewing Cost Loop Data](/docs/features/cost-loops/viewing-cost-loop-data) for where else it shows up and at what detail. # Anthropic Learn how to connect your Anthropic organization to North as a Cost Loop. Connect the Anthropic Cost Loop with your North account to see your usage costs across the various models Anthropic provides. ## Before You Start You need administrator access to your Anthropic organization, and your Anthropic organization ID. North verifies that the ID matches the organization tied to the key you supply, so the two must belong together. North reads your Claude usage and cost through an Anthropic API. You supply your organization ID and an API key. Which API North uses, and where you create that key, depend on which Claude product you use. North asks you to pick one, and the setup steps change with your answer. | Product type | Where you administer it | Key you create | API North reads | | ------------------- | ----------------------- | ----------------- | ------------------------ | | **Claude Platform** | platform.claude.com | Admin API key | Admin API | | **Enterprise** | claude.ai | Analytics API key | Enterprise Analytics API | Pick the Claude product type that matches how your organization buys Claude. If you are not sure, check which of the two sites you use to manage your organization. If you pick Enterprise, you must be the Primary Owner of your Anthropic organization to create the Analytics API key. ## Connect Anthropic {% stepper %} {% step %} ### Open the Connect Screen Open **Settings**, then **Integrations**, then **Add accounts**. Under **Cost Loops**, select **Anthropic**. {% endstep %} {% step %} ### Create Your API Key **For Claude Platform:** in the Claude Console, open **Settings**, then **Admin keys**. Open the [Claude Console Admin keys](https://platform.claude.com/settings/admin-keys) page to go there directly. Create an Admin API key with access to usage and cost reporting. **For Enterprise:** in claude.ai, open **Organization settings**, then **API**. Open the [claude.ai API settings](https://claude.ai/admin-settings/api-access) page to go there directly. Create an Analytics API key with the `read:analytics` scope. {% endstep %} {% step %} ### Enter Your Connection Details Fill in the Anthropic fields: * **Connection name.** A label to recognize this account by. It becomes the card title on your homepage. * **Anthropic Organization ID.** On Enterprise, claude.ai can show both an Organization ID and a Parent Organization ID. Enter the Organization ID. * **Claude Product Type.** Claude Platform or Enterprise. * **Admin API key**, or **Analytics API key** for Enterprise. The field label changes with the product type you selected. {% endstep %} {% step %} ### Verify and Connect Click **Verify & connect**. North checks the API key against the Anthropic organization ID before it saves the connection. {% endstep %} {% endstepper %} ## What North Reads The reports North reads depend on the Claude product type you selected. ### Claude Platform On Claude Platform, North reads two reports from the Anthropic Admin API, plus a third for Claude Code. | Report | Frequency | Broken down by | | ----------------- | --------- | ------------------------------------------------------------------- | | Usage | Hourly | Model, workspace, service tier, context window, inference geography | | Cost | Daily | Workspace and description | | Claude Code usage | Daily | Not broken down further | {% hint style="info" %} Usage carries more dimensions than cost. That is a property of the Anthropic Admin API, which caps a request at five grouping dimensions and reports cost at a coarser grain than usage. {% endhint %} ### Enterprise On Enterprise, North reads two reports from the Anthropic Enterprise Analytics API. | Report | Frequency | Broken down by | | ------ | --------- | --------------------------------------------------------------------------------------------- | | Usage | Hourly | Model, product, context window, inference geography, speed, RBAC group | | Cost | Daily | Model, product, cost type, token type, context window, inference geography, speed, RBAC group | ## After You Connect Anthropic spend appears on your homepage as a card carrying your connection name. See [Viewing Cost Loop Data](/docs/features/cost-loops/viewing-cost-loop-data) for where else it shows up and at what detail. # OpenAI Learn how to connect your OpenAI organization to North as a Cost Loop. Connect your OpenAI Cost Loop integration with your North account to see usage costs across the various models OpenAI provides. North reads your organization-wide OpenAI usage and spend through the OpenAI Admin API. One organization-scoped Admin key covers your whole organization. ## Before You Start You need administrator access to your OpenAI organization, and your OpenAI organization ID. Find the ID in the OpenAI platform under **Settings**, then **Organization**, then **General**. Open the [OpenAI General settings](https://platform.openai.com/settings/organization/general) page to go there directly. The ID starts with `org-`. ## Connect OpenAI {% stepper %} {% step %} ### Open the Connect Screen Open **Settings**, then **Integrations**, then **Add accounts**. Under **Cost Loops**, select **OpenAI**. {% endstep %} {% step %} ### Create an Admin Key In the OpenAI platform, open **Settings**, then **Organization**, then **Admin keys**. Open the [OpenAI Admin keys](https://platform.openai.com/settings/organization/admin-keys) page to go there directly. Then: 1. Click **Create admin key**. 2. Name it `north`. The name is optional. 3. Set the expiration to **Never**. 4. Open the **Permissions** tab. 5. Toggle **Read** on the **Usage API** scope. 6. Click **Create admin key**. {% hint style="warning" %} Set the expiration to Never. If the key expires, North stops receiving your usage and cost data until you supply a new one. {% endhint %} {% endstep %} {% step %} ### Enter Your Connection Details Fill in the OpenAI fields: * **Connection name.** A label to recognize this account by. It becomes the card title on your homepage. * **OpenAI organization ID.** The `org-` value from your General settings. * **Admin API key.** The key you just created. {% endstep %} {% step %} ### Verify and Connect Click **Verify & connect**. North checks the Admin API key against the OpenAI organization ID before it saves the connection. {% endstep %} {% endstepper %} ## What North Reads North reads a cost report and a set of usage reports. | Report | Frequency | Broken down by | | ------ | --------- | ------------------------------ | | Cost | Daily | Project, line item, API key | | Usage | Hourly | Varies by endpoint. See below. | North reads usage from ten endpoints: completions, embeddings, moderations, images, audio speeches, audio transcriptions, vector stores, code interpreter sessions, file search calls, and web search calls. Most usage endpoints break down by project, user, API key, and model. Two do not carry a model breakdown: vector stores and code interpreter sessions report by project only. {% hint style="info" %} Cost is daily, and usage is hourly. That is a property of the OpenAI Admin API, which does not accept an hourly bucket on the cost endpoint. {% endhint %} ## After You Connect OpenAI spend appears on your homepage as a card carrying your connection name. See [Viewing Cost Loop Data](/docs/features/cost-loops/viewing-cost-loop-data) for where else it shows up and at what detail. # Datadog Learn how to connect your Datadog organization to North as a Cost Loop. Connect Datadog to North as a Cost Loop to see your Datadog observability and APM (application performance monitoring) spend beside your cloud spend. North reports Datadog spend by product, such as Infra Hosts, Containers, and Indexed Logs. You can also split and filter Datadog spend by your Datadog tags. North reads your Datadog cost with a Service Access Token. ## Before You Start You need three things in Datadog: * **Permission to manage access.** You create a role, a service account, and a Service Access Token for North. * **Custom roles.** Your Datadog organization must have custom roles turned on before you can create the role for North. See [Datadog custom roles](https://docs.datadoghq.com/account_management/rbac/). * **Your Datadog site.** Your Datadog site is the domain in your browser's address bar when you sign in to Datadog, for example `app.datadoghq.com` or `app.datadoghq.eu`. ## Connect Datadog {% stepper %} {% step %} ### Open the Connect Screen Open **Settings**, then **Integrations**, then **Add accounts**. Under **Cost Loops**, select **Datadog**. {% endstep %} {% step %} ### Opt In to Datadog Cloud Cost {% hint style="info" %} If you have already opted into Cloud Cost, you can skip this step. {% endhint %} In Datadog, open **Cloud Cost** in the left sidebar. This Datadog feature is free. You only need to opt in. 1. On the **Manage your Datadog spend** card, click **Opt in**. 2. If Datadog then asks you to set up Usage Attribution, skip it. Skip the **Control your cloud spend** card. It is a separate paid Datadog add-on for AWS, Azure, and Google Cloud bills. Complete this opt-in before you connect Datadog to North. North reads your Datadog cost from Datadog Cloud Cost Management. See [Datadog costs](https://docs.datadoghq.com/cloud_cost_management/datadog_costs/) for more guidance. {% endstep %} {% step %} ### Create a Role for North In Datadog, open **Organization Settings**, then **Roles**. Create a role for North with two permissions: * **Usage Read** * **Billing Read** {% endstep %} {% step %} ### Create a Service Account In Datadog, open **Organization Settings**, then **Service Accounts**. Create a service account for North. Assign it the role that you created for North. See [Datadog service accounts](https://docs.datadoghq.com/account_management/org_settings/service_accounts/) for more guidance. {% endstep %} {% step %} ### Create a Service Access Token In Datadog, create a Service Access Token on the service account for North. Set its expiration to **Never**. Give it these three scopes: * `usage_read` * `billing_read` * `timeseries_query` {% hint style="warning" %} Set the expiration to Never. If the Datadog token expires, North stops receiving your Datadog cost data until you supply a new token. {% endhint %} {% endstep %} {% step %} ### Enter Your Connection Details On the North connect screen, fill in the Datadog fields: * **Connection name.** A label to recognize this account by. It becomes the card title on your homepage. * **Datadog site.** The site that matches the domain in your browser's address bar. * **Service Access Token.** The token that you created for North. It starts with `ddsat_`. {% endstep %} {% step %} ### Verify and Connect Click **Verify & Connect**. North looks up your Datadog organization with the token. If the connection works fine, you should see a success message. {% endstep %} {% endstepper %} ## If Verification Fails When a Datadog check fails, the error message states the missing scope and the role permission that goes with it. Add the missing item in Datadog. Then click **Verify & Connect** again. If North cannot connect to Datadog, check two things: * **The token type.** The Datadog token must be a Service Access Token that starts with `ddsat_`. * **The site.** The selected site must match the domain in your address bar. Each Datadog site is a separate deployment, and a token works only on its own site. ## After You Connect {% hint style="info" %} Your Datadog cost data can take a few days to appear in North after you opt in to Datadog Cloud Cost. Datadog makes the current month available a few hours after you opt in, and earlier months can take longer. North checks Datadog for new cost data each day and imports it as soon as it is available. {% endhint %} Datadog spend appears on your homepage as a card that carries your connection name. You can also add Datadog to a Streams view, select it in Visibility, and ask Noros about it. See [Viewing Cost Loop Data](/docs/features/cost-loops/viewing-cost-loop-data) for the detail available on each surface. ## What North Reads North reads daily cost for your Datadog organization from Datadog Cloud Cost Management. North receives this cost by product, by pricing term, and by tag. * **Product** is the Datadog product you are billed for, such as Infra Hosts or Indexed Logs (15 Day Retention). * **Pricing term** is **Committed** for usage that your Datadog commitment covers, and **Standard** for on-demand usage. * **Tags** are the tag keys that Datadog Cloud Cost Management attributes your cost to, such as `env`, `service`, or `team`. {% hint style="info" %} **A note on tags with more than one value.** Datadog can report one cost with two values of the same tag, such as `env:dev` and `env:prod`. Streams and Visibility show that cost once, as the value `dev,prod`. A filter on `prod` in Streams or Visibility includes only `prod` spend, while the same filter in Datadog also includes `dev,prod` spend. To match Datadog, select both `prod` and `dev,prod`. {% endhint %} Datadog reports cost by day. For hourly views, North allocates each day's Datadog cost across its hours by your hourly Datadog usage. Datadog bills some products on a P99 (99th percentile) basis, and those products have no hourly split. North spreads their cost evenly through the day. Daily and monthly totals do not change. ### Historical data North reads up to 12 months of Datadog cost: the current month and the 11 months before it. If your Datadog billing history is shorter, North reads from the month your history starts. ## Limitations You cannot split Datadog spend by child organization. # Viewing Cost Loop Data Learn where your Cost Loop spend appears in North, and how much detail each provider gives you. Cost Loop spend appears in four places: your homepage, Streams, Visibility, and Noros. Each one answers a different question. | Surface | What it answers | | ---------- | ------------------------------------------------------------------------ | | Homepage | What am I spending this month, per provider? | | Streams | How does this spend allocate across my business, and what is it made of? | | Visibility | How does this spend compare and trend across time periods? | | Noros | The questions you ask about this spend in chat. | ## Homepage Each connected Cost Loop gets its own card, below the alert tiles. The card carries the connection name you chose during setup. Every card shows: * **MTD Spend**, month-to-date spend for that provider. * A sparkline comparing the previous month against this month, split by a marker between the two. * A bell icon, which opens alerts for that provider. * A gear icon, which opens that connection's settings. ## Streams Streams is where Cost Loop spend is allocated and broken apart. A Streams view groups your cloud streams and business units into a single allocation model, and a Cost Loop can be part of that model. ### Adding Cost Loops to a View When you create a view, a **Cost loops** control lists every connected loop, grouped by provider. Select the loops you want in this view. A view can carry your cloud account and any number of Cost Loops together. ### Splitting Cost Loop Spend To see provider-specific spend, split your root by **Provider**. Once a loop is in a view, split its node by **Service** to see the provider's own units of spend. Most providers support more splits below that. The table in [What Each Provider Reports](/docs/features/cost-loops/viewing-cost-loop-data#what-each-provider-reports) lists them for each provider. For example, split an OpenAI model by **Usage Type** to see its cached input cost beside its uncached input cost. ## Visibility Visibility puts Cost Loop spend beside your cloud spend on the same chart and in the same table. ### Selecting Cost Loops A **Cost loops** control sits at the top right of the Explore, Compare, and Forecast tabs. It lists every connected loop, grouped by provider, and it is additive: whatever you select is added to the data presented on the page. ### Splitting and Filtering by Provider Use the **Provider** dimension to separate Cost Loop spend from cloud spend, and one Cost Loop from another. Group by provider to see AWS, Snowflake, Anthropic, OpenAI, and Datadog as their own series. Filter by provider to narrow the whole page to one of them. ### What You See Cost Loop spend appears at service granularity, with both **Amortized cost** and **Unblended cost**. See [What Each Provider Reports](/docs/features/cost-loops/viewing-cost-loop-data#what-each-provider-reports) for what the services are for each provider. {% hint style="info" %} **A note on Claude models.** If you run Claude through Amazon Bedrock as well as through the Anthropic API, both appear in your service list, and they are separate lines. Bedrock usage is labelled with the Bedrock edition, for example `Claude Sonnet 4.5 (Amazon Bedrock Edition)`, and is part of your AWS spend. Anthropic Cost Loop usage carries the raw model name, for example `claude-sonnet-4-6`. Adding them together would not double count, but they are billed by two different providers and reach North by two different routes. {% endhint %} {% hint style="info" %} **A note on Datadog hourly figures.** Some Datadog hourly figures in Visibility are estimates. Datadog bills some products on a P99 (99th percentile) basis, and those products have no hourly split. North spreads their cost evenly through the day. Daily and monthly totals do not change. When this applies, the Explore and Compare tabs show a **Datadog hourly is estimated** note. {% endhint %} ## Noros Noros answers questions about Cost Loop spend the same way it answers questions about your cloud spend. Open **Noros AI**. Ask Noros about a Cost Loop provider by name, for example "Show my Datadog cost." See [Noros AI](https://docs.noros.ai) for what else you can ask. ## What Each Provider Reports Each Cost Loop provider reports spend in its own units. In Streams and Visibility, those units appear as services. Most providers support more splits below the service. | Provider | Services | Other useful splits | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | OpenAI | Models, by version, for example `gpt-5.4-2026-03-05` |
  • Usage Type: input, cached input, and output tokens.
  • Pricing Term: Standard or Dynamic.
  • Linked Account: OpenAI project.
| | Anthropic (Claude Platform) | Models, by version, for example `claude-sonnet-4-6`. Tool charges appear under their own names, for example `web_search` and `code_execution`. |
  • Usage Type: uncached input, cache read, cache write (5-minute and 1-hour), and output tokens.
  • Pricing Term: Standard or Dynamic.
  • Linked Account: Anthropic workspace.
| | Anthropic (Enterprise) | Models, by version, for example `claude-opus-5`. Tool charges appear under their own names, for example `web_search` and `code_execution`. |
  • Usage Type: uncached input, cache read, cache write (5-minute and 1-hour), and output tokens.
  • Pricing Term: Other for all Enterprise spend.
  • Linked Account: None for all Enterprise spend.
| | Snowflake | Billing categories, for example Snowflake Compute and Snowflake Cloud Services |
  • Usage Type: Snowflake usage categories, for example Compute, Cloud Services, and Storage. An Overage prefix, as in Overage-Compute, marks usage billed at on-demand rates.
  • Pricing Term: Committed, Standard, or Other. Other is usage paid with free or rebate credits.
  • Record Type: Usage, Adjustment, or Purchase.
  • Resource Id: warehouse ID.
  • Tags: warehouse and database tags.
| | Datadog | Products, for example Infra Hosts and Indexed Logs (15 Day Retention) |
  • Usage Type: Datadog usage keys, for example infra\_host\_top99p.
  • Pricing Term: Committed or Standard.
  • Record Type: Usage, Credit, or Adjustment.
  • Tags: Datadog tags, for example env and service.
| # Alerts Learn what North alerts you about, where those alerts appear, and how to read each one. North watches your spend, your commitments, and your resources every day. What it finds reaches you in two places on the homepage: the **notification bell** in the top navigation, and the **alert row** below the spend charts. Both show the same findings. The bell is the running feed. The alert row breaks the same findings into counts by type. {% hint style="info" %} You can also set up alerts to your Slack channels using Noros. Learn more about Noros [here](https://docs.noros.ai/). {% endhint %} ## The Notification Bell The bell carries a count of alerts you have not read yet. Click it to open the **Notifications** panel, where your alerts are listed under **Smart Alerts**, newest first. Each entry shows: * A **severity dot**. Red marks the most urgent findings. Amber marks findings that are not urgent, including savings opportunities. * A **title** naming what happened and what it happened to. * **How long ago** it was raised, and for some alerts the cloud provider it came from. Use **Mark all as read** to clear the unread count. Reading an alert does not dismiss it. ### Alert Types Each alert describes the issue at hand. Clicking the alert takes you to the relevant page in the app, scoped to that alert, so that you can review it further and take action. | Title | What it means | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Cost Spike Detected:** *service* | Spend on that service rose beyond what North expected. | | **Cost Dip Detected:** *service* | Spend on that service fell sharply. A dip can mean a resource was deleted or a commitment lapsed. | | **Budget Exceeded:** *budget* | Spend passed a threshold you set on that budget. | | **Underutilized Commitment:** *utilization* | A commitment is running below the utilization it needs to pay for itself. The figure is its current utilization. | | **$***amount***/month in Rightsize Savings** | Rightsize has found resources you can resize. The figure is the monthly saving available across them. | ## The Alert Row Below the spend charts on the homepage, four tiles group the same findings by type. Each tile carries a count or a figure. Click one to expand it in place, without leaving the homepage. | Tile | What it covers | | ------------------------------- | -------------------------------------------------------------------------------- | | **Noros Alerts** | Every alert raised for this account, matching the bell. | | **Rightsize savings available** | The savings Rightsize has found, as a dollar figure per month. | | **Cost Anomalies** | Cost spikes and dips flagged by anomaly detection. | | **Commitment Health Alerts** | Commitments needing attention, such as low utilization or an approaching expiry. | The first tile is the whole set. The other three are the individual sources feeding it, so one finding can appear in both its own tile and the Noros Alerts total. ## Cost Loop Alerts Each connected Cost Loop has its own card further down the homepage, and each card carries a bell. Use it to reach the alerts for that provider's spend. See [Cost Loops](/docs/features/cost-loops) for what a Cost Loop is and how to connect one. ## Choosing What You Are Alerted About The homepage shows you what North found. Choosing which alerts are raised, and where else they reach you, happens in Noros. Noros supports two levels of alerting: * **Organization alerts** are set once by your root user and go to a shared Slack channel. * **Your own alerts** are set by you, with your own thresholds, and reach you by email or by Slack direct message. Both cover cost anomalies, commitment alerts, reshaping recommendations, and budgets. See the [Noros documentation](https://docs.noros.ai/) for how to set them up. # Settings # Add cloud accounts Learn how to add another cloud account or a SaaS Cost Loop to an organization you have already set up. You can add accounts at any time after your first one. Open [Settings, then Integrations](https://app.north.cloud/settings?tab=accounts), and click **Add accounts**. The provider picker shows two groups. **Cloud** holds AWS, Google Cloud, and Azure. **Cost Loops** holds the SaaS providers North supports, such as Snowflake, Anthropic, and OpenAI. You can add from either group, and adding one does not affect the accounts you already have. ## Cloud Accounts Each cloud provider has its own onboarding guide, with the permissions it needs and the steps to grant them. {% content-ref url="/pages/uMXDX5flGvRBqdtPXmQ9" %} [Quickstart](/docs/getting-started/quickstart) {% endcontent-ref %} ## Cost Loops A Cost Loop brings SaaS spend into North alongside your cloud accounts. Each provider has its own setup guide. {% content-ref url="/pages/c3A0TWK2bgT0VaU3IMZg" %} [Cost Loops](/docs/features/cost-loops) {% endcontent-ref %} # Invite team members Invite teammates to your North account and assign the appropriate level of access. You can invite new users to your North.cloud account [here.](https://app.north.cloud/settings?tab=team-members)
1. Go to **Settings** 2. Click **Invite team member** in the top right corner {% hint style="info" %} You can only invite users with the same domain name. For example cannot invite . {% endhint %} 3. Enter the team member’s email address 4. Select the access level you want to grant. For more details, click on **IAM permissions** at the bottom of this page {% hint style="info" %} Viewer is best suited for users that only need read only access. Editor is best suited for users that can read and edit your profile. {% endhint %} After the invitation is sent, the team member will receive an email from `north.cloud` with instructions to access the account. # IAM Permissions Learn more about IAM Permissions in North. IAM Permissions let teams control access to cloud accounts and product features across North. As organizations grow, not every user should have access to the same data. IAM Permissions make it possible to safely share cloud cost visibility across engineering, finance, and leadership teams, without exposing information they don’t need. Instead of relying on a single role for all users, IAM Permissions allow access to reflect real organizational structures, cloud ownership models, and security requirements.
### When to use IAM Permissions Use IAM Permissions when you want to: * Restrict access to specific AWS or GCP accounts * Limit feature access by role, team, or responsibility * Share cost visibility with finance or leadership without exposing infrastructure-level details * Separate access across business units, subsidiaries, or environments * Reduce manual requests for cost data while maintaining control IAM Permissions are designed to support teams operating across multiple clouds, accounts, and functions. ### How IAM Permissions work IAM Permissions are configured per user and apply at two levels: Account access\ Control which AWS or GCP accounts a user can see: * All AWS accounts * All GCP accounts * Specific AWS or GCP accounts only Feature access\ Control which product features a user can access, such as: * Visibility * Coststreams * Commitments * Reshaping * Budgets * Agent * API access (when enabled) Each feature can be set to: * View * Edit * Deny This allows fine-grained control over what users can see and do inside North. ### Who can manage IAM Permissions Only users with Manage users permissions can configure IAM access.
There are two relevant permission levels: * View users: Can see users and their permissions, but cannot make changes * Manage users: Can invite users, assign permissions, and update access All users can view their own permissions, but only managers can modify access for others. ### View your permissions Every user has access to a My Permissions view.
This shows: * Which cloud accounts you can access * Which features are enabled for your user * Whether access is view-only or editable This makes permissions transparent and easy to understand without involving an administrator. > Note: If you assign permissions to all accounts and add another specific account with different permissions, IAM will automatically assign permissions based on the most granular. I.e: the smaller account will have different permissions to the broader all account setup.
# Getting Started How to begin granting permissions across your team or organization. ### To get started with IAM Permissions
1. Navigate to **Settings** in [app.north.cloud](https://app.north.cloud) 2. Select **IAM Permissions** 3. Click **Invite user** 4. Choose the cloud accounts the user can access 5. Assign feature-level permissions 6. Send the invite New users do not receive full access by default. All access must be explicitly granted during the invite process. ### Update permissions over time Permissions can be updated at any time as roles change or teams grow. Admins can: * Add or remove account access * Change feature permissions * Restrict or expand user capabilities Changes take effect immediately. ### Using IAM Permissions with Noros Noros respects user permissions.
When a user interacts with Noros: * Noros can only retrieve data the user has access to * Restricted accounts or features are excluded from responses If you want to limit what data Noros can surface for a user, restrict their account or feature access accordingly. More granular Noros controls are planned for future updates.
# Create cohorts Learn more about North.cloud's Cohorts feature, which enables you to organize users into groups and assign them specific roles and responsibilities across different North features. Cohorts are powerful user groups that let you organize people within your organization and assign responsibilities across North's features. With cohorts, you can streamline collaboration, control access, and clarify which users or teams are responsible for specific accounts and feature areas. #### What are Cohorts? * **Cohorts** are groups of users that can be assigned to manage or access specific features in North.cloud. * You can use cohorts to allocate responsibility for important functions like **Anomaly Detection**, **Reshaping recommendations**, and **Stream Business Units**. * Cohorts allow you to map teams to the cloud accounts or business units they manage, improving accountability and workflow. * For other North features, cohorts can be created and members can self-assign as needed. {% embed url="" %} #### How to Create and Use Cohorts **To create a cohort and assign responsibilities:** 1. [**Navigate to the "Cohorts" section** in your North.cloud dashboard.](https://app.north.cloud/settings?tab=cohorts) 2. Click **"Create Cohort"**. 3. **Name your cohort** (e.g., "FinOps Team", "SRE Group", "Business Unit X Owners"). 4. **Add users** to the cohort. 5. **(For Anomalies, Reshaping, and Stream Business Units):** * Assign the cohort a list of account IDs or business units they are responsible for. * This maps accountability for optimizations, anomaly investigations, and business unit management directly to the relevant team. 6. **Finalize and save** the cohort configuration. **Example workflow:** * Create a cohort called "East Region Engineers". * Add engineers responsible for the eastern AWS accounts. * Assign this cohort to Anomalies, Reshaping, and Stream Business Units for the set of account IDs they own. * Whenever a recommendation or anomaly is detected for those accounts, the cohort is automatically notified and given access. * For features like reports or dashboards, cohorts can join or be given access as needed. **Why use cohorts?** * Ensure the right teams receive the right alerts and tasks. * Streamline collaboration and hand-offs—everyone knows their area of responsibility. * Maintain clear, auditable mappings between users, teams, accounts, and feature controls. For more on cohorts, see the feature-specific documentation or the "Cohorts" section in your North.cloud dashboard. # Billing Learn more about how our billing works. How North bills you depends on the cloud you are on. | Your cloud | How North bills you | | ------------ | ---------------------------------------------- | | AWS | Through the AWS Marketplace, or through Stripe | | Google Cloud | Through Stripe | | Azure | Through Stripe | ### AWS Marketplace North is available through the [AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-axjowgejulzlm). * Subscribe directly via the Marketplace listing, or * Contact your North team to set up a private offer for billing via AWS Marketplace. ### Stripe North's invoicing is powered by Stripe, with net 15 payment terms. You can manage billing details anytime at [app.north.cloud/billing](https://app.north.cloud/billing). Google Cloud and Azure customers are invoiced through Stripe. For any billing questions, contact . # Customer Support Customers can request support 24/7 via their dedicated Slack channel or [book time directly with our team.](https://calendly.com/northinc/northcloud-customer-support-call) # Service Cancellation Learn how to cancel North's service, and where to find the terms that apply to a cancellation. You can cancel North's service at any time. The Savings Plans and Reserved Instances that North manages for you can be disconnected from your billing organization and transitioned to another North customer. The notice periods and handoff terms for a cancellation or a reduction are set out in North's [Master Services Agreement (MSA)](https://north.cloud/terms-of-service).