AWS Tagging/Naming Conventions

Naming of Objects
Nearly all AWS resources can be named. These should follow a consistent pattern to be able to
more clearly identify them and their context. The standard naming convention described below
should be used in all AWS accounts. If the name tag is available, then the object must be given
one. Below are examples of resources and the associated naming conventions as they would be
following this pattern. NOTE: If a resource type is not listed below, it should still conform to
this naming convention.

Name recipe (Camel Case + ALL CAP

AWS
appended to the end (e.g., SG, VPC, Comment Example
Resource
S3, KEY))
ITS-USEast1-
Prod
VPC ITS-Region-<name>
ITS-USEast2-
DevQA
ITS-USEast1-
Prod-Public-
2a
ITS-Region-<vpc name>-<scope>- Scope: Public or
Subnet
<AZ> Private
ITS-USEast2-
DevQA-
Private-2c
Elastic
<project>-whatever your team needs-
Load
<(dev/stage/prod/whatever)>-ELB
Balancer
AURA-
<project>-whatever your team needs-
EC2 WebSvr-prod-
<(dev/stage/prod/whatever)>-EC2
EC2
Security <project>-whatever your team needs-
Group <(dev/stage/prod/whatever)>-SG
<project>-whatever your team needs-
S3 <(dev/stage/prod/whatever)>-s3 (note:
s3 bucket names are lowercase)
 <project>-whatever your team needs-
Key
<(dev/stage/prod/whatever)>-KEY
<project>-whatever your team needs-
RDS
<(dev/stage/prod/whatever)>-RDS
<project>-whatever your team needs-
SQS
<(dev/stage/prod/whatever)>-SQS
<project>-whatever your team needs-
SNS
<(dev/stage/prod/whatever)>-SNS
these users are ONLY
programmatic users. linuxteam-
<team>-brief description of need- no console access. ec2-autoscale-
USER
<(dev/stage/prod/whatever)>API-USER console access is prod-API-
ONLY through USER
grouper.
linuxteam-
ec2-autoscale-
if tied to an API-USER, use <same name
POLICY prod-API-
as API-USER>-POLICY
USER-
POLICY
<project>-whatever your team needs-
RDS
<(dev/stage/prod/whatever)>-RDS-
Parameters
PARAM

TAGS
Based on: https://aws.amazon.com/answers/account-management/aws-tagging-strategies/

as well as convention for DLT: https://opscenter.dlt.com/hc/en-us/articles/235230267-AWS-

Tagging-with-a-DLT-AWS-Account

https://confluence.cornell.edu/display/CLOUD/Standard+Tagging

RULES

1. use on every type of AWS object

2. you can use whatever other tags you like
3. but these tags must be used according to the environment
 SANDBOX
TAG PROD - Required standardized/open details/example
- Required
yes, get it from its-aws- (Standardized: If you don't know your
[email protected], yes, your What has been CostCode, or need one,
1 CostCode
or make one up and we'll cnetid provided by email its-aws-
correct it later Cornelia). [email protected]
(Open: What is the
resource used for?
2 Purpose yes yes
Use your
nomenclature.)
(Open-ish: What
architectural
3 Role yes yes e.g., database, web serve
purpose does this
serve?)
4 Environment yes optional (Standardized:) dev, test, stage, prod
(Standardized:
Service owner,
Who is the first
unix-
5 ResponsibleParty yes yes responder when it
[email protected]
breaks? for the
value, use name +
contact, e.g.,
(Standardized:
Who is the
business
"First Name / Last Nam
6 Owner yes optional owner? We know
<email>"
it'll change, but we
can batch that
later.)
 (Open: what's the
project?) identifies
the project(s) the
resource
supports. This
should be
consistent for
7 Project yes optional griffin, aura,
resources
supporting the
same project for
ease or
programming,
querying,
reporting, etc.