AWS and Terraform Naming Best Practices

Terraform patterns

Terraform and AWS resource naming should follow a company standard. Each company has different requirements and the standard should be adjusted.

Best Practice: Terraform Naming Patterns: Name each Terraform variable following a pattern of elements that indicate all the information.

Terraform variable naming

AWS Component / Service

Follow this pattern. Use lowercase and underscores as a separator.

• Provider: a prefix specifying the name of the provider, in this case, was (AWS in lowercase)
• Resource: a short name identifying the resource, in this case:
  • sn: for a subnet
  • rt: for routing table
  • igw: for Internet gateway
  • ir: for Internet route
  • rds_sn: RDS Subnet
  • rds-mariadb: for RDS MariaDB type of resource
  • sg-rds-mariadb: for RDS Security Group for MariaBD type of resource
  • sr-rds-mariadb: for RDS Security Rule for MariaBD type of resource
  • ec2: for an EC2 Instance
  • sg-ec2: for an EC2 Security Group 
  • sr-ec2: for an EC2 Security Rule 
• Environment: for resources that are not to be shared between environments, a 3-letter acronym for the environment:
  • pro: production
  • pre: preproduction
  • dev: development
• Visibility: for resources that can be either public or private, a 3-letter acronym for the visibility:
  • pub: for public resources
  • pri: for private resources
• Unique ID/Name: a unique number or name related to the resource.
  • For Networks: In this case, the third octet in the IP address (172.17.NN.0) is used because it is different in all the subnets.
    The idea behind having a unique ID on the names is to be able to see errors from copy/paste easily by detecting anti-patterns.
  • For Databases: Use the DB resource number: e.g. this will be the RDS MariaDB 01 for Public Zones and Pro-Environment. We might have a new RDS DB in the future, adding a number now will make it easier to grow the infrastructure later on.
  • For Database security group: Use a number, e.g. this will be the RDS MariaDB security group 01 for Public Zones and Pro Environment. We might have new security groups in the future, adding a number now will make it easier to grow the infrastructure later on.
  • For Database security rules: Description of the purpose of the rule: Using a description like instances_to_db_port explains the intended usage of the rule. In this case, it is a rule to allow access from the EC2 instances to the RDS Database port.
  • For EC2: Use a name and number, e.g. this will be an EC2 instance for WordPress wp number 01 for Public Zones and Pro-Environment. We might have new EC2 instances for WP in the future, adding a number now will make it easier to grow the infrastructure later on.
  • EC2 security group: use a number, e.g. this will be the EC2 security group 01 for Public Zones and Pro-Environment for wp. We might have new security groups in the future, adding a number now will make it easier to grow the infrastructure later on.

Examples:

• aws_sn_za_pro_pub_32 = { …}
• aws_rds_mariadb_pro_pub_01 = { …}
• aws_sg_rds_mariadb_pro_pub_01 = { …}
• aws_sr_rds_mariadb_pro_pub_01_instances_to_db_port = { …}
• aws_ec2_pro_pub_wp_01 = { …}

Resource naming patterns

The name of each resource should follow a pattern. Use lowercase and a dash as a separator.

• Cloud: a prefix specifying the unique name of this cloud across all available clouds and providers. In this case, the prefix will be ditwl which stands for Demo IT Wonder Lab in lowercase.
• Resource: a short name identifying the resource, in this case, sn stands for subnet
• Environment: for resources that are not to be shared between environments, a 3-letter acronym for the environment:
  • pro: production
  • pre: preproduction
  • dev: development
• Visibility: for resources that can be either public or private, a 3-letter acronym for the visibility:
  • pub: for public resources
  • pri: for private resources
• Unique ID: a unique number related to the resource.
  In this case, the third octet in the IP address (172.17.NN.0) is used because it is different in all the subnets.
  The idea behind having a unique ID on the names is to be able to see errors from copy/paste easily by detecting anti-patterns.
  
  It is important to have a unique prefix so that external elements (like a Monitoring System) can differentiate each element in multi cloud/client environments.

Example:

name =”ditwl-sn-za-pro-pub-32″

Using a consistent pattern allows the name to include all the needed information to understand its purpose making the description almost unnecessary.