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:
| Product1-prod |
| App Naming | {{appName}} – {{environment}} [[number]]-[[region]]-{{scope}}[[number]] | Environment should be one of:
Scope should be used if necessary and it can reflect components of an application
| 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:
| 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:
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:
Route type Number:
| 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
|
| Route Tables | {{account_naming}} – {{routeType}} – rt [[- zone]] | Route type is one of the following:
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:
If multiple are needed, increment number. Account level resource name:
| 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:
| 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:
Scope can be one or the following
| 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:
| 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:
Deployment Type is one of the following:
| 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:
Deployment Type is one of the following:
| 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:
Deployment Type is one of the following:
| 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:
Deployment Type is one of the following:
| 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:
Deployment Type is one of the following:
| 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:
| 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:
Account level group purpose can be one of the following:
Option account level group access can be one of the following:
| 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:
Account level group purpose can be one of the following:
| 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:
| 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:
| 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:
Account level product names can be one of the following:
Level of Access must be one of the following:
| 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 |
| 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:
Certificate Type should be one of the following:
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):
Alarm Metric should match the metric name in lowercase dashed style such as:
Check Status should be one of:
| 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:
| 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):
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:
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.
