Insights
Read Time: 2 mins

Naming Convention for AWS Resources and CloudWatch Alarms

In some of our recent work we found that creating a component register for AWS deployed resources (with a unique ID for every resource) was extremely helpful in setting up alarms. The register could be used to set up a consistent naming convention that could be used to pull out meaningful context and extra information in a highly efficient way.

The Component Naming Convention allows us to consistently identify deployed resources in respect to: 

  1. What Product they belonged to
  2. What Environment were they for (e.g. dev/sit/uat/prod)
  3. What sort of component (though that would be obvious) (e.g. Lambda, Database, WAF)
  4. What Application/Business Service, and optionally what sub component of that service was this component
  5. A unique numeric identifier that was managed in a centralised location (e.g. a configuration management database, or documentation in Confluence).

Naming Pattern for Deployed Resources

The pattern for the above is:

${Product}_${Environment}_${ComponentType}_${ServiceName}_${ServiceComponent}_${ComponentReference}

A Lambda function would then have a Name like the following:

productA_uat_Lambda_Integration_Requeue_C149

And the IAM Role it executes with would be:

productA_uat_IAMRole_Integration_C145

This naming standard also helps when viewing these resources in the AWS console as the resources are ordered by name, so that resources for the same Product, Environment, and Service are together.

Naming Convention for CloudWatch Alarms

We also use a similar standard for naming CloudWatch Alarms.  

This has two main purposes for us:

  1. Easily identify exactly what the Alarm means and the implications
  2. Allow information to be decoded from the Alarm name and sent to a user in a different format (email, slack, etc).

The pattern for Alarms is similar to the component naming:

${Product}_${Environment}_${ComponentType}_${ServiceName}_${ServiceComponent}_${ComponentReference}_${AlarmSeverity}_${AlarmType}

For the same Lambda function above, we would configure a Throttling Alarm with the following name:

productA_sit_Lambda_Integration_C149_Critical_T002-Lambda-Throttling-Alarm

For each type of AWS resource, we define an AlarmType that uniquely identifies the nature of this alarm.

These AlarmTypes are documented (e.g. on Confluence) to detail what metrics the Alarm is configured to be triggered by.

The table below shows the naming parts used for both the Component Name and Alarm Name:

 

Some examples we’ve used for the AlarmType specifically for Lambda functions:

T001-Lambda-Error-Alarm

T002-Lambda-Throttling-Alarm

T003-Lambda-High-Invocations

T004-Lambda-High-Concurrent-Executions

T005-Lambda-High-Duration

T006-Lambda-High-Unreserved-Concurrent-Executions

T007-Lambda-Error-Percentage-Alarm

 

We’ve used the following when creating CloudWatch alarms for Aurora MySQL databases:

T040-Aurora-High-CPU

T042-Aurora-Free-Local-Storage

T043-Aurora-Database-Connections

T044-Aurora-Commit-Latency

T045-Aurora-Insert-Latency

T046-Aurora-Update-Latency

 

Need help on AWS? Get in touch here.
Author Details
Jeremy Ford
Jeremy Ford
Application Development Lead
Jeremy has over 16 years’ experience in software engineering. He specialises in Java and Web technologies and has extensive experience across all phases of the SDLC. Jeremy is the Application Development Lead for Intelligent Pathways and has led the successful delivery of multiple solutions for our clients utilising agile principles and processes. Jeremy is also a member of Intelligent Pathways’ internal consulting group, which identifies and recommends suitable technologies, coding practices and standards across the company.
Send Email
Got an enquiry? Intelligent Pathways wants to hear from you.
  • This field is for validation purposes and should be left unchanged.