here are some common standards followed by all templates that you should be aware of. Some of the standards I have learned to be best practices, some other have I have developed from experience as well serving practices. Feel free to follow them or adjust as per your standards.

Naming resources is one of the crucial standards you must have. No matter what standard you follow, I can assure you, even the worst standard followed is better than no standard at all. 

The resources are named as per the pattern:

ENVIRONMENT_SOLUTIONNAME_EXTRAS

As per the environment, I usually define them as letters, D = Development, S = Staging, T = Test, P = Production. The specific environment value is defined as a variable "env" and you can adjust this by changing the default value.

E.g.

"${var.environment_prefix}_${var.solution_prefix}${var.customer_prefix}"

Rationale: 

1. The environment variable: making changes in a running infrastructure may have repercussions to your business, therefore, you want to make sure that you are always aware of which environment you are working in. By putting the first letter as identifier of the environment, you make sure that this is the first thing that your eye catches when you cross check which resource you are touching.

2. Solution prefix: this is your solution identifier. If your solution is named "YourCRM", then it is a good practice all resources of this solution to have this on their name

3. Customer prefix: this is a specific thing to your needs. Often in large organizations, this is used for different reasons. If you do not need it, simply leave the variable empty. If you use it, make sure you use an underscore to split the prefix from solution prefix.

Always tag your resources. What tags you use may be relevant to your needs and organization, I would recommend you use at least these: