AWS and Terraform Naming Best Practices

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

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: fro 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 this unique prefix as external elements (like Monitoring System) will have to be able to differentiate between many clouds.

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.

Table of Contents
Primary Item (H2)Sub Item 1 (H3)Sub Item 2 (H4)
Sub Item 3 (H5)
Sub Item 4 (H6)

Related Cloud Tutorials

AWS Security Groups’ Best Practices
AWS Security Groups are virtual firewalls that control inbound and outbound traffic to and from Amazon Web Services (AWS) resources, such as EC2 and RDS instances.
How To Debug Terraform
Enable Terraform debug Terraform uses the value from the environment variable TF_LOG to define the LOG level. Available values are TRACE, DEBUG, INFO, WARN or ERROR. Additionally, you can specify a destination file for the log by setting the environment variable TF_LOG_PATH to the full path of the desired destination. Set the debug variables and […]
AWS Tagging Best Practices
Effective infrastructure resource tagging can greatly improve management, IaC, monitoring and cost visibility in AWS.
How to Deploy Applications in Kubernetes using Terraform
How to publish multiple replicas of an Application (from the Docker Registry) and create a NodePort in Kubernetes using Terraform (in 10 seconds)
Terraform logo
HCL
HashiCorp Configuration Language HCL is a domain-specific language developed by HashiCorp, a company known for its infrastructure automation tools such as Terraform, Vault, Consul, and Nomad. HCL is designed specifically for writing configuration files that define infrastructure components and their settings. It is used in HashiCorp’s suite of tools to create and manage infrastructure as […]
AWS Terraform module
IaC
Infrastructure as Code IaC is an approach to managing and provisioning computing infrastructure through machine-readable code and automation, rather than manual processes. In IaC, infrastructure is defined, configured, and managed using code, which can be version-controlled and treated like any other software application. IaC involves: IaC provides several benefits, including improved efficiency, reduced manual errors, […]
AWS S3
AWS S3, is a highly scalable and durable object storage used for data storage, backup, content distribution, data archiving, and as a foundation for building cloud-native applications.
AWS EC2
Amazon Elastic Compute Cloud, is a web service offered by Amazon Web Services (AWS) that provides resizable and scalable compute capacity in the cloud. In simple terms, AWS EC2 allows you to launch and manage virtual machines, known as instances, in the AWS cloud.
AWS AMI
AWS AMI, or Amazon Machine Image, is a pre-configured virtual machine image used to create and launch Amazon Elastic Compute Cloud (EC2) instances
Terraform Cloud Agents in a Kubernetes Cluster
What are the Terraform Cloud Agents? With Terraform Cloud Agents, a company can manage its private infrastructure as code and benefit from all the functionality of Terraform in a SaaS scenario.
1 2 3

Javier Ruiz

IT Wonder Lab tutorials are based on the rich and diverse experience of Javier Ruiz, who founded and bootstrapped a SaaS company in the energy sector. His company, which was later acquired by a NASDAQ traded company, managed over €2 billion per year of electricity for prominent energy producers across Europe and America. Javier has more than 20 years of experience in building and managing IT companies, developing cloud infrastructure, leading cross-functional teams, and transitioning his own company from on-premises, consulting, and custom software development to a successful SaaS model that scaled globally.

One comment on “AWS and Terraform Naming Best Practices”

Leave a Reply

Your email address will not be published. Required fields are marked *


linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram