Tagging AWS resources
We use AWS for hosting. Most AWS resources support tagging, and the Engineering Enablement team coordinates their effective use at GDS.
This guidance explains the tagging strategy for the interim GDS AWS organisation. You can find information about other AWS organisations on the Engineering Hub.
Account tags
Account tags are essential for accurate recharging to your business unit and cost centre. See service team responsibilities for finance and billing on the Engineering Hub for more information.
They’re also used for cyber security and accountability.
Resource tags
The main reasons for adding tags to your AWS resources are:
- to be able to understand costs (by assisting queries in Cost Explorer)
- to understand the provenance of resources (by tagging with metadata about source code)
- security and assurance
Resource tags are not used for financial reporting in GDS, but they can still help you understand your cloud infrastructure costs.
We therefore make available a set of standard resource-level cost allocation tags, to help you understand spend with respect to specific components, teams, and environments.
If you want to analyse spend by directorate, programme or product, you may want to use Cost Explorer’s facility for grouping or filtering spend by linked account. The Engineering Enablement team will consider enabling account-level tags, such as cost centre, for cost allocation.
Tag names
The tag names in this guidance use UpperCamelCase case, except for a limited number of tags which for historical reasons contain a space character. AWS tags are case sensitive.
AWS
limits
the names and values of tags to alphanumeric, space, and a limited set of punctuation (\+-=.\_:/), so you must avoid characters outside this set.
Further limitations for EC2 disallow space and other characters for instance metadata, so for consistency you should avoid those too.
Validation and preventative controls
All tags are optional and there are no plans to establish preventative controls to enforce the inclusion of tags when resources are created.
If you use one of the GDS standard resource tags in the table below, you should follow the schema described.
GDS standard resource tags
Only the tags marked with a Y below are enabled as cost allocation tags in the interim GDS AWS organisation.
| Tag name | Example values | Description | Cost allocation tag? |
|---|---|---|---|
Name |
ec2-instance-prod-1 |
Identifies an individual resource | Y |
Service |
webcaf.nonprod-service.security.gov.uk, CSLS - Centralised Security Logging Service
|
Identifies what service this resource (or a collection of resources with the same tag value) provides to its clients, which may be internal or external. You should use a domain name if applicable. | Y |
Component |
front-end, db, api
|
The component or microservice associated with the resource. Typically this is a lower level construct than Service, but you do not have to use both. If your multi-account strategy allows you to perform account-level analysis without the Service tag, Component may still be useful for lower-level cost analysis. |
Y |
Environment |
production, test, development, dev, staging, integration, prototype, sandbox, preview
|
Application environment the resource belongs to. Teams should follow a multi-account strategy with a separate account for each environment, so as a resource tag this may be redundant and could be deprecated in future. | Y |
Owner |
team1@digital.cabinet-office.gov.uk |
Email address of the individual or team that is responsible for the resource. | Y |
Product |
govuk-once |
Frequently the account name (or account-level tags) are adequate to track which product relates to all the resources in an account, so this tag is optional. One use case is to track ownership for resources in central accounts that relate to specific products (such as AWS Organizations policies). You must use a product name that matches the account name brand and product prefix that applies to the associated accounts. | Y |
Source |
https://github.com/alphagov/gds-way/ |
The URL(s) for any source code repositories related to this resource, separated by spaces. | N |
Data Classification |
PCI DSS, OFFICIAL
|
Identifies the highest data classification level the resource handles. | N |
BillingProject |
Helps with cost/benefit analysis and reporting to your stakeholders. Compare the relative cost of one project against another, or one technology stack against another, or one component against another. | Y | |
Exposure |
internal, external
|
Specifies the level of exposure the resource has to determine its attack surface area. | N |
PipelineStackName |
Pipelines can use this to indicate which CloudFormation stack and pipeline deployed the resource. | N | |
BackupFrequency |
Daily, BiHourly
|
Used in the Digital Identity AWS organisation for automated backups using AWS Backup. | N |
Note that the above resource tags are not used for recharging to GDS business units. We enable cost allocation only to help teams visualise their costs and to understand their cloud spend. All GDS financial reporting uses account-level tagging, so that every resource is accounted for according to the owner of the account in which it’s created.
Deprecated resource tags
The following resource tags, previously mentioned in the GDS Way, are deprecated. There’s no obligation to remove them from existing resources, and if you think they’re useful please contact Engineering Enablement.
| Tag name | Deprecation reason |
|---|---|
| System | The system or component should be clear from the name of the account. BillingProject is an alternative for analysing different technology solutions you’re trying out; Service and Component are alternatives for comparing other resource use within an account. |
References
You may find the following references useful:
- AWS documentation and best practices on tagging
- RFC: GDS tagging strategy
- MoJ digital tagging strategy
- the duckbill group’s guide to tagging best practices