docs: Provide worked examples for the AWS tag schema

[akash1810]

What is being recommended?

Updates the recommendation for AWS tags, providing a worked example of our tagging schema.

Note

It might be easier to review the rendered markdown.

What's the context?

The existing definition of stack is quite ambiguous. Hopefully, the worked examples is clearer.

[Copilot]

Pull request overview

Updates the AWS recommendations documentation by moving the tagging guidance into a dedicated document and adding clearer examples to reduce ambiguity around the Stack tag.

Changes:

• Replaces the inline AWS tagging bullet list in AWS.md with a link to a dedicated tagging guide.
• Adds a new aws-tags.md document describing the Guardian AWS tag schema (App, Stack, Stage, gu:repo) with explanatory examples.
• Clarifies how Stack relates to account-level grouping and notes the term’s ambiguity vs CloudFormation stacks.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
AWS.md	Replaces inline tag guidance with a pointer to the new tagging documentation.
aws-tags.md	Introduces a dedicated AWS tagging schema doc with definitions and examples.

Suppressed comments (2)

aws-tags.md:25

• Grammar: “operate across account” should be plural (“across accounts”) since the sentence refers to tooling spanning multiple AWS accounts.

Tools which operate across account, for example Riff-Raff, use the stack to derive an individual AWS account. 

aws-tags.md:49

• Grammar: “the Owner tags helps” should be singular (“tag helps”).

When provisioning a resource in another team's account, the `Owner` tags helps that team know who to contact if needed. 

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[johnduffell]

this is great, I think we don't really use stack properly in supporter revenue, partly as we just have loads and loads of glue lambdas and only a small number of larger systems.

[akash1810]

I think we don't really use stack properly in supporter revenue, partly as we just have loads and loads of glue lambdas and only a small number of larger systems.

I think this is fairly common and I suspect largely due to copy/pasting existing CFN or riff-raff.yaml files from other apps in a team's estate. The definition for Stack is deliberately open: "a group of related applications". This grouping could be broad or narrow based on a team's preference.

[johnduffell]

I think we don't really use stack properly in supporter revenue, partly as we just have loads and loads of glue lambdas and only a small number of larger systems.

I think this is fairly common and I suspect largely due to copy/pasting existing CFN or riff-raff.yaml files from other apps in a team's estate. The definition for Stack is deliberately open: "a group of related applications". This grouping could be broad or narrow based on a team's preference.

Yeah agreed on the copy and paste, but personally I think a lot of it is fear of breaking something unknown - e.g. not having to go and fix it up in places like https://github.com/guardian/Anghammarad#mappings and maybe other places encourages us to duplicate them.
in fact, in supporter revenue stream we have our own set of app->team mappings for our alarms [1] , which probably doesn't fit in with the stack philosophy (it's easier to change the app mapping when ownership changes than the whole stack)

[1] https://github.com/guardian/support-service-lambdas/blob/main/handlers/alarms-handler/src/alarmMappings.ts