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. 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 ofHQ,HMPPS,OPG,LAA,HMCTS,CICA, orPlatforms(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:trueorfalse, to indicate if the infrastructure is part of, or supports, live production servicesowner: Should be of the form<team-name>: <team-email>. This is the team responsible for the overall service.
Optional
environment-name: The name the owners use to refer to the environment; typically something likeproduction,staging,test, ordevelopment.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.