AWS Naming Conventions

Introduction- AWS Naming Conventions

This blog talks about the AWS Naming Conventions for different workloads.

There are different criteria for naming a workload. For example,

  • Account name could be infra account or product type for workload.
  • Environment for a product includes an instance of dev and production.
  • Workload type is lambda, AWS EC2, S3 Buckets etc. 

If multiple similar type of numbering range workloads exists, then add a number to them.

Below is an example:

  • Root Account <master> -no environments
  • Sandbox
    • Sandbox-product1-Lambda1
    • Sandbox-Product1-Lambda2
  • Production
    • Production-Product1-
    • Production-Product2
    • Production-Infra-1

There is no best practice or mandate for AWS naming conventions. So, use them as needed and change them as per the business requirements.

Below are some of the standards we follow for all of our clients.

Cloud Resource AWS Naming Conventions

Bottom of Form:

Please follow the AWS naming conventions below for a consistent provisioning of AWS resources.

Item

FormaClientNaming Style

Determined by Construct

{{construct_name}}

Entered by User

{{item_name}}

Optional Text based on use

[[naming]]

To be Included “AS IS”

wording

Account Naming Constructs

AWS Resource

Resource Name

Comment

Example

Org Unit Name

<>-<ou>

   

Account Naming

<Account name>-<environment>

teamName should be the name of the application team owning the application

Environment should be one of:

  • prod
  • stage
  • test
  • dev

Product1-prod

App Naming

{{appName}} – {{environment}} [[number]]-[[region]]-{{scope}}[[number]]

Environment should be one of:

  • prod
  • stage
  • test
  • dev

Scope should be used if necessary and it can reflect components of an application

  • auth
  • app
  • web
  • api
  • cache
  • master
  • worker

Product1-dev

Product1-stage

Product1-test

Product1-prod

Product1-dev-app

Product1-test-web

Resource AWS Naming Conventions

Cloud Formation Naming Standards

AWS Resource

Resource Name

Comment

Example

CloudFormation Stack

If this stack is universal and not application specific:

{{account_naming}}  – {{stack_group}} – cf

If this stack is application specific:

{{app_naming}} – {{stack_group}} – cf

stack_group should be one of:

  • ALL – includes all stack types
  • VPC – All VPC resources
  • NAT – NAT servers for the VPC
  • SG – Security Groups
  • IAM – IAM roles used instances and CodeDeploy
  • ELB – Elastic Load Balancer
  • ASGLC – AutoScaling Group and Launch Configuration
  • CW – CloudWatch monitoring
  • RDS – Databases, options groups, parameter groups
  • RDSREPLICA – Replica/slave database instances
  • S3 – S3 buckets
  • CONFIG – Config Rules

Product1-prod-vpc-cf

Product1-dev-sg-cf

Product1-test-s3-cf

Product1-prod-web-elb-cf

Product1-prod-app-rds-cf

CloudFormation ChangeSet

If this stack is universal and not application specific:

{{account_naming}}  – {{dateGenerated}} – cset

If this stack is application specific:

{{app_naming}} – {{dateGenerated}} – cset

Date Generated should follow:

YYYYMMDDHHMM

Any additional information about the change set should be included in the description of the changeset

Product1-prod- 202109151100-cset

or

Product1-prod-202109151100-cset

AWS Account Items

AWS Resource

Resource Name

Comment

Example

AWS Account Email

Aws_accounts – {{teamName}} – {{environment}} @tonkintaylor.co.nz

Environment should be one of:

  • <Environments>

Not all P-env’s require a separate account

Aws_accounts-Product1-dev@ tonkintaylor.co.nz

VPC Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

VPCs

{{account_naming}} – vpc 

 

Product1-dev-vpc

Product1-prod-vpc

Subnets

{{account_name_construct}} – {{subneClientNameype}}  {{routeType}} – {{az}} – {{number}}

Subnet Type should be one of:

  • app
  • elb
  • db
  • cache
  • nat
  • web
  • data

Route type

Number:

  • Starts at 1, only increments if we have outgrown that AZ’s subnet

Product1-dev-app-private-1a-1

Product1 -stage-elb-public-1b-1

Product1 -prod-db-private-1c-1

Product1 -prod-web-private-1d-1

VPC Peering Link

{{account_naming_of_target}} – {{scope_of_target}} – vpc-peerlink

The items to be wriClientNameen should be that of the remote end of the VPC Peering Link

Example link between Product1 and sharedservices

  • Product1-prod-vpc-peerlink
  • sharedservices-prod-vpc-peerlink

Route Tables

{{account_naming}} – {{routeType}} – rt  [[-  zone]]  

Route type is one of the following:

  • public
  • private

If the route table is distinct for each AZ (e.g. you are routing to different NATs), you must add the following Zone

Zone should be #l (e.g 1a, 1b, 1c, 1d, 1e)

Product1-dev-private-rt-1a

Product1-dev-standard-public-rt

DHCP Option Sets

{{account_naming}} – dhcpoptions

 

Product1-dev-standard-dhcpoptions

Network ACL

{{account_naming}} – {{naclType}} – nacl

NACL Types should reference why they exist (dnsout, etc)

Please note that these are not required and not great to use

Product1-dev-dnsout-nacl

Virtual Private Gateway

{{account_naming}} – {{scope}} – vgw 

This should match the VPC naming

 

EC2 Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

Elastic Load Balancer

{{app_naming}} – elb

All new ELBs should be internal

Product1-dev-elb

Product1-stage-web-elb

Product1-prod-web1-elb

Launch Configuration

{{app_naming}} – {{dateGenerated}} – lc

dateGenerated only required if manually created

Date should be in the form:

YYYYMMDDHHMM

Hours should be in 24 hour format

Product1-prod-web-202111251904-lc

AutoScaling

{{app_naming}} – asg

 

Product1-prod-app-asg

Product1-prod-asg

Security Groups

{{app_naming}}[[number]] – {{resource_name}} – sg

Account level Security Group resources:

{{account_naming}}[[number]] – {{account_level_resource_name}} – sg

Resource Name can be one of:

  • elb
  • efs
  • nfs
  • instance
  • db
  • mgmt 
  • for bastion and direct T+T management access only

If multiple are needed, increment number.

Account level resource name:

  • nat

Product1-dev-elb-sg

Product1-prod-web-mgmt-sg

Product1-prod-web01-instance-sg

Product1-prod-web02-instance-sg

Instances

{{app_naming}} [[-  ec2asg]] 

 Account level instance resources:

{{account_naming}} – {{account_level_instance_scope}} [[-  ec2asg]] 

If generated by an Autoscaling Group add “-ec2asg”

Account level Instance Scope:

  • nat

Product1-dev-app

Product1-prod-cache

Product1-prod-web-ec2asg

AMIs

{{app_naming}} – ami

 

Product1 -prod-worker-ami

SSH Pem Keys

{{account_naming}} – {{app_naming}} – {{dateGenerated}}

Date should be in the form:

YYYYMMDD

.pem will be added by AWS on download

riskreport-dev- Product1-dev-web-20151102.pem

S3 Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

S3 Buckets

{{teamName}} – {{environment}} – {{scope}}  bucket

Environment should be one of:

  • P = prod
  • P-1 = stage
  • P-2 = test
  • P-3 = dev

Scope can be one or the following

  • elblogs

lancheck-dev-bucket

lancheck-dev-elblogs-bucket

Lambda Function Naming Standard

AWS Resource

Resource Name

Comment

Example

Lambda Function

{{app_naming}} – {{function_scope}} – lambda-function

 Account level function resources:

{{account_naming}} – {{function_scope}} – lambda-function

Function scope should be one of the following:

  • autodeploy
  • cfoutputs

Product1-prod-autodeploy-lambda-function

RDS Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

RDS (DB Instance Name)

{{app_naming}} – {{db_type}} – {{deployment_type}}

DB Type is one of the following:

  • oracle
  • mysql
  • postgres
  • maria
  • aurora

Deployment Type is one of the following:

  • multiaz
  • standalone
  • slave

Product1-prod-oracle-standalone

Product1-prod-mysql-multiaz

Product1-prod-aurora-slave

RDS (Subnet Group)

{{app_naming}} – {{db_type}} – {{deployment_type}} – subnetgroup

DB Type is one of the following:

  • oracle
  • mysql
  • postgres
  • maria
  • aurora

Deployment Type is one of the following:

  • multiaz
  • standalone
  • slave

Product1-prod-oracle-standalone-subnetgroup

Product1-prod-mysql-multiaz-subnetgroup

Product1-prod-aurora-slave-subnetgroup

RDS (Option Group)

{{app_naming}} – {{db_type}} – {{deployment_type}} – optiongroup

DB Type is one of the following:

  • oracle
  • mysql
  • postgres
  • maria
  • aurora

Deployment Type is one of the following:

  • multiaz
  • standalone
  • slave

Product1-prod-oracle-standalone-optiongroup

Product1-prod-mysql-multiaz-optiongroup

Product1-prod-aurora-slave-optiongroup

RDS (Parameter Group)

{{app_naming}} – {{db_type}} – {{deployment_type}} – paramgroup

DB Type is one of the following:

  • oracle
  • mysql
  • postgres
  • maria
  • aurora

Deployment Type is one of the following:

  • multiaz
  • standalone
  • slave

Product1-prod-oracle-standalone-paramgroup

Product1-prod-mysql-multiaz-paramgroup

Product1-prod-aurora-slave-paramgroup

Elasticache Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

AWS Resource

Resource Name

Comment

Example

ElastiCache

{{app_naming}} – {{cache_type}} – {{deployment_type}}

Cache Type is one of the following:

  • memcached
  • redis

Deployment Type is one of the following:

  • multiaz
  • standalone
  • slave

Product1-prod-memcached-standalone

Product1-prod-redis-multiaz

Product1-prod-redis-slave

CodeDeploy Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

Code Deploy Deployment Group

{{app_naming}} – {{scope}} – dg

Scope Can be one of the following:

  • app
  • web
  • cache

Product1-prod-app-dg

Product1-dev-web-dg

IAM Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

IAM User

Administrators:

First.last

Service Accounts:

service_name

IAM user names should mirror the users @tonkintaylor.co.nz email address

brent.taylor

my_serviceaccount

IAM Group

{{app_naming}} – {{group_purpose}} –  iam – group

Note: There will be a standard naming structure for account level group resources:

{{account_naming}} – {{group_purpose}} – {{access_level}} –  iam – group

Application group purpose can be one of the following:

  • readonly
  • poweruser
  • administrator
  • developer

Account level group purpose can be one of the following:

  • forcemfa
  • cloudendure
  • administrator

Option account level group access can be one of the following:

  • administer
  • developer
  • poweruser
  • readonly
  • isolated-by-tag

Product1-prod-readonly-iam-group

Product1-dev-administrator-iam-group

riskreport-dev- forcemfa-iam-group

IAM Role (via aad)

{{account_naming}} – aad – {{group_purpose}} –  iam – role@us-east-1

Note: There will be a standard naming structure for app level roles resources:

{{app_naming}} – aad – {{group_purpose}} –  iam – role@us-east-1

Account group purpose can be one of the following:

  • admin
  • poweruser
  • developer
  • readonly
  • (More can be added as required)

Account level group purpose can be one of the following:

  • fullaccess
  • readonly

cloudhacks-dev-standard-aad-admin-iam-role@us-east-1

Product1-prod-aad-readonly-iam-role@us-east-1

IAM Roles

{{app_naming}} – {{role_purpose}} –  iam – role

Role Purpose can be one of the following:

  • autodeploy
  • s3access
  • datapipeline
  • ebssnapshot
  • lambdaexecute

Product1-prod-autodeploy-iam-role

Product1-dev-s3access-iam-role

Instance Role

{{app_naming}} – {{role_type}} –  iam – ec2role

Role Purpose can be one of the following:

  • app
  • web
  • cache
  • master
  • worker
  • nfs

Product1-prod-app-iam-ec2role

Product1-dev-cache-iam-ec2role

IAM Policy

{{app_naming}} – {{product_used}} –  {{level_of_access}} – iam – policy

 

 

 

Note: There will be a standard naming structure for account level policy resources:

 

{{account_naming}} – {{product_used}} –  {{level_of_access}} –  iam – policy

 

Product Used must be one of the AWS product names such as:

  • ec2
  • s3
  • lambda
  • codedeploy
  • sqs

Account level product names can be one of the following:

  • securitymonkey
  • osaccounts
  • cloudendure
  • cfoutputs

Level of Access must be one of the following:

  • readonly
  • readwrite
  • isolated-by-tag

Product1-prod-s3-readwrite-iam-policy

Product1-dev-codedeploy-readonly-iam-policy

Note: Instance profiles are a collection of policies added to a role

KMS

{{app_naming}} –  {{type}} – kms

  • Type should be one of:
  • ebs
  • rds
  • snowball
  • s3
  • redshift
  • codecommit
  • cloudtrail
  • elastictranscoder
  • ses

Product1-dev–rds-kms

Product1-prod–ebs-kms

 SSL Certificates (for ELB or Cloudfront)

{{app_naming}} – {{product_used}} – {{certificate_type}} – {{certificate_expiry}} – sslcert

These items are treated internally as IAM resources and therefore must be named appropriately

Product Used must be one of the following AWS product names:

  • elb
  • cloudfront

Certificate Type should be one of the following:

  • domain
  • wildcard
  • san

Certificate Expiry should be in the format “YYYYMM”

Product1-dev-elb-domain-201601-sslcert

Product1-prod-cloudfront-wildcard-201601-sslcert

Cloudwatch Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

CloudWatch Alarm

{{app_naming}} – {{instance_id}} – {{alarm_product}} – {{alarm_metric}} – {{check_status}} – cw-alarm

Alarm Product Should be one of the following (lowercased):

  • elb
  • asg
  • rds
  • billing
  • ebs
  • lambda
  • s3
  • sns
  • linuxsystem (instance_id must be used)

Alarm Metric should match the metric name in lowercase dashed style such as:

  • hClientNamep-4xx
  • hClientNamep-5xx
  • volume-queue-length
  • cpu
  • memory
  • swap
  • diskspace

Check Status should be one of:

  • high
  • low

Product1-prod-elb-hClientNamep-4xx-high-cw-alarm

Product1-prod-rds-max-connections-high-cw-alarm

SNS Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

SNS Topic

{{app_naming}} – {{topic_name}} – {{topic_subscription_type}} – sns-topic

Topic name should be a lowercased name for the topic

Topic Subscription Type should be one of the following:

  • email
  • hClientNamep
  • sqs
  • sms
  • application
  • lambda

Product1-prod-elbcw-email-sns-topic

Product1-prod-codedeploy-lambda-sns-topic

SQS Resource Naming Standards

AWS Resource

Resource Name

Comment

Example

SQS Queue

{{app_naming}} – {{queue_name}} – sqs-queue

The Queue name should be a lowercased name for the queue

Product1-prod-myqueuename-sqs-queue

CloudWatch Log Groups

Format

Comment

Example

{{app_naming}} – {{ source }} – {{ context }} 

Source should be one of the following (the AWS service the CloudWatch Log is configured with):

  • lambda
  • vpc

Context may be arbitrary but reflects the context of the use of the log

vpc-flowlog

lambda-dev-autodeploy

lambda-prod-autodeploy

Product1-dev-lambda-deleteebssnapshot

Git Repository

Type

Format

Comment

Example

Automation Code Repositories

ClientName – {{ code context }} – {{ resource name }}

Code context should be one of the following:

  • cloud formation

This name should mirror any associated CAR package

Resource name should be the name of the resource the automation code manages.

ClientName-cloudformation-rds

Application Repositories

ClientName – applications – {{teamName}} – {{appName}}

teamName should be the application team name providing support

appName should be the application name without the environment

ClientName-applications-riskreport-Product1

Feature Branch

feature/CLOPS-xxx_short_description

JIRA-xxx should be the JIRA Story or task used to track progress

feature/JIRA-2713_adding_environment_tag

Bugfix Branch

bugfix/CLOPS-xxx_short_description

JIRA-xxx should be the JIRA Story or task used to track progress

bugfix/JIRA-2713_fix_race_condition

Conclusion- AWS Naming Conventions

In conclusion, you can use an AWS Naming Convention based on the requirement of your workload. There are different conventions that can work for different criteria. There is no set mandate, and so it is best to use a naming convention that suits your workload requirement. 

 

Get In Touch If You Have A Business Query

Related Posts