Skip to main content
Table of contents

Documenting owners of infrastructure

All of your infrastructure resources should be tagged with details of their owners, what service they are part of, and what type of environment they are in.

Without this, teams responsible for supporting your services (security, finance, and web operations) may not be able to keep your infrastructure secure, paid for by the right people, and appropriately supported. Documenting this on the infrastructure itself ensures that it’s as accurate and up-to-date as possible.

You should do this even if you’re managing infrastructure in your own account: other teams may end up needing access to that account, or may receive access via another account.

Tagging your infrastructure

All of our existing cloud hosting providers support tagging (AWS, Azure, vCloud). If your infrastructure is defined in code (as it should be), you can probably specify your tags in that code.

AWS limits the names and values of tags to alphanumeric, space, and a limited set of punctuation (+-=._:/), so it’s worth avoiding characters outside this set on all providers for maximum portability.

Tags you should use

To ensure we can consistently search for, and report on, the tags we use, you should use the following tags. In all values, only use acronyms if you’re confident that someone from another part of government would understand them.

Mandatory

  • business-unit: Should be one of HQ, HMPPS, OPG, LAA, HMCTS, CICA, or Platforms (for use by Platforms & Architecture team). If none of these are appropriate, use an appropriate name for the area of the MOJ responsible for the service.
  • application: Should be the full name of the application or service (and acronym version, if commonly used), e.g. Prison Visits Booking, Claim for Crown Court Defence/CCCD.
  • is-production: true or false, to indicate if the infrastructure is part of, or supports, live production services
  • owner: The team responsible for the overall service. Should be of the form <team-name>: <team-email>.

Optional

  • environment-name: The name the owners use to refer to the environment; typically something like production, staging, test, or development.
  • component: Which part of the application this infrastructure is for, e.g. Staff booking interface, API gateway. If there’s a common name for the type of component, use that (e.g. front-end, api, message-queue)
  • infrastructure-support: The team responsible for managing the infrastructure. Should be of the form <team-name>: <team-email>.
  • runbook: The URL of the service’s runbook.
  • source-code: The URL(s) for any source code repositories related to this infrastructure, comma separated.
This page was last reviewed on 20 December 2021. It needs to be reviewed again on 20 March 2022 .
This page was set to be reviewed before 20 March 2022. This might mean the content is out of date.