tag resources

[brianleroux]

use @app to tag lambdas, tables, restapis… basically anything generated by arc

[brianleroux]

nice idea for the future so adding to the wiki

[sentience]

Our organisation has a tagging standard for all its AWS resources, so we could really use this capability. For now, is there any more practical approach than going into the AWS Console and manually tagging the resources created by arc?

[brianleroux]

This is a great use case for opening up access to the cli workflow tool arc-inventory. Basically when you run npx inventory it calls this code which returns a tidy object of all your resources defined by .arc in the current directory.

Can you share more with the tagging standard of your org?

[sentience]

Sure! Here's a quick paste of our standard:

Tagging AWS Resources: Sensible Defaults

This is a sensible default. Read the linked article for more information about what a sensible default is and how to read this document.

Tagging AWS resources allows for better cost control, easier auditing and helps new team members understand how stuff works. Tags can declare AWS resources as components of an item in our asset register, making it easier to track risk.

Implementation

Most AWS resources are managed via CloudFormation. When launching a CloudFormation stack, our mandatory tags MUST be specified. This ensures the stack itself is tagged, and that the tags flow into all taggable resources created as a result. AWS CLI supports this via --tags when creating or updating a stack.

Tag keys and values

• Tags are case sensitive; precise keys and values are required
• All key names should be lower case e.g. foo
  • Except for Name which AWS treats as special in the web console.
• There should be no spaces in key names, use hyphen e.g. foo-bar
• Where possible do not use special characters in tag values.

Mandatory tags

All taggable AWS resources must have the following tags. The examples given would apply to Influx's production RDS database.

We run an AWS Config rule to monitor compliance with mandatory tagging.

Tag Names	Example value	Summary
asset	influx	Asset ID which the resource is a component of
workload	production	The type of workload, representing availability impact
data-classification	restricted	Classification of the data held by the resource

asset

All AWS resources represent a component of an “asset” in Culture Amp's Asset Register. The asset tag must be set to the ID of the associated asset.

Example values
murmur
influx
aws-infrastructure

workload

The type of workload the resource is supporting. This helps represent the impact to availability if the resource fails. It is also indicative of the classification of data the service can impact.

Value	Description
production	resource failure has immediate customer impact.
management	resource failure prevents us managing our services, e.g. VPN, AD.
delivery	resource failure prevents us from delivering new features.
staging	resource failure prevents us from demonstrating/testing upcoming features.
development	resource failure prevents us from working on new features
sandbox	resource failure has negligible impact

data-classification

A data classification from our Data Protection Policy relating to the data held within the resource. Mandatory for all AWS resources, but may be “None” if there is no data.

Value	Description
none	Resource is not a data repository
internal-use-only	The default; not public, but low-impact
public	Data intentionally published to the public
confidential	Aggregated/anonymised customer data
restricted	Raw customer data

Further reading:

• AWS Tagging Strategies

[brianleroux]

thx for this / super helpful!!!

given that arc generates all sorts of infra but the end user experience is effectively a manifest and a bunch of functions do you think a new section called @tags work for your use case?

@app
myapp

@html
get /

@tags
asset aws-infrastructure
tag2 value-two
etc etc

The example .arc above would apply tags to all resources. Imagining a workflow wherein you can use npx inventory tags to verify/sync the aws resources to the tags in the arc file. We could allow for function level override using .arc-config.

One problem w this approach is I'm not sure how we'd handle tagging the diff between staging and production!

[sentience]

@brianleroux That looks great except for the need to tag staging/production with a “workload” tag in our case. Could we support tagging from environment variables with some kind of placeholder?

@tags
asset aws-infrastructure
workload %ARC_DEPLOY%

[vala84no]

+1 for this feature. It would be very helpful to be able to specify tags, though there's some difficulties involving dynamic tags. Static tags as a first step would be great. For dynamic tags, would it be possible to just leverage the fact that the repo will be using node? Something like a .arc-tags.js that exports a function that can be executed for everything generated by arc to determine suitable tags (in addition to the already defined static ones). It would be relatively easy to implement after static tags had been implemented while being very powerful.

[JakeChampion]

Tagging is also a standard at my workplace. We currently use Serverless Framework and it's stackTags feature, which tags the entire cloudformation stack with the associated tags.

[brianleroux]

YES! I have been dying to build this in. We do now have a macros feature which allows you to modify the generated CFN … if anyone gets a macro going its a very short jump to adding it into architect/package

[brianleroux]

Thank you for your continued patience! Adding to architect/architect distribution as soon as all the tests pass. You can now tag every deploy with arc deploy --name mycustomname --tags key=val my=hello!