Skip to main content

Identifying and Managing Untagged AWS Resources

Overview

In our AWS account, some resources are missing the mandatory business-unit tag. These untagged resources contribute to unallocated spend, which can be identified using AWS Cost Explorer.

You can refer to the Cost Explorer report to view untagged spend based on missing business-unit tags. (You can adjust the date range in the report as needed.)

To maintain accurate cost allocation, we need to identify and tag these resources wherever possible.

Refer to the MoJ Technical Guidance on tagging requirements for more information.

Note: Missing mandatory tagging can sometimes be case by case, depending on the resource and its ownership. This runbook serves as a general guideline for approaching untagged resources.

Step-by-Step Process

1. Identify untagged resources by type

We handle each resource type individually based on the “Service” field in the Cost Explorer report (e.g. ECR, RDS, S3, CloudWatch, etc.).

  • Use the AWS Tag Editor to filter for resources missing the business-unit tag.
  • Search by region and resource type.
  • This will help identify which resources are missing required tags.

Note: While we primarily use the eu-west-2 region, some resources may be deployed in eu-west-1 or even in US regions. Always check carefully across regions to ensure no untagged resources are missed.

Once identified:

  • Determine whether the resource belongs to us or to a user.
  • If it belongs to us, update the relevant Terraform code to apply the missing tag.
  • If it belongs to a user, contact them and ask them to add the required tag.
  • In some cases, the tag might be missing in our Terraform modules.
    • If so, update the module, test it, and bump the module in the cloud-platform-environment repository.
    • (Example ticket here)

2. Investigate services not visible in Tag Editor

Some services do not appear in Tag Editor (e.g. Amazon Kendra). In such cases:

  • Navigate to the service directly in the AWS Console.
  • Manually check each resource to confirm whether the business-unit tag is present.
  • Determine ownership (ours or the user’s).
  • Either update the code or contact the user to apply the tag.

Note: These services may also be deployed outside our primary eu-west-2 region. Be sure to check other regions such as eu-west-1 or even US regions if needed.

3. Exceptions – organisation-level resources

Some AWS services are inherited from the organisation level and not created directly in our account, so we cannot tag them manually.

Examples include:

  • Detective
  • GuardDuty
  • Inspector
  • Config
  • Security Hub
  • Cost Explorer

These can remain untagged for now, as they are managed and tagged at the organisation level.

4. Verifying the Change

Once tagging changes have been applied, you can verify them in two ways and focus your checks on the service which you took action:

  • Via Cost Explorer:

    • Use the same Cost Explorer report to confirm that the change has taken effect — the untagged cost for that service should now be reduced or even drop to zero.
    • When a tag is applied during the day, the cost for that day would be split between tagged and untagged entries.
    • For a clearer view of the impact, check the Cost Explorer report two days after the change.
      • For example, if the tag was applied on Monday, check the report on Wednesday to see the full charges for Tuesday.
  • Via Tag Editor:

    • Return to the AWS Tag Editor and filter by region and resource type to confirm that the business-unit tag has been applied. This helps ensure that the resource is now properly tagged and visible in your tagging reports.

If untagged cost remains in Cost Explorer, or resources are still showing as untagged in Tag Editor, repeat steps 1–2: re-check the tagging, investigate ownership, and take appropriate action — such as fixing Terraform code, manually applying the missing tag, or contacting the responsible team — then verify again.

This page was last reviewed on 6 May 2025. It needs to be reviewed again on 6 November 2025 by the page owner #cloud-platform .
This page was set to be reviewed before 6 November 2025 by the page owner #cloud-platform. This might mean the content is out of date.