Naming conventions.

[rquadling]

WIBNI (It would be nice if) the AWS ruleset could validate the naming conventions of resources as they are seemingly inconsistent.

For example:

╷
│ Error: updating tags for ELB (Elastic Load Balancing) Target Group (arn:aws:elasticloadbalancing:eu-west-1:0123456789012:targetgroup/ticketing-dt-staging-wildcards/0123456789abcdef): operation error Elastic Load Balancing v2: AddTags, https response error StatusCode: 400, RequestID: 01234567-0123-0123-0123-0123456789ab, api error ValidationError: 1 validation error detected: Value 'Ticketing - All other elements (wildcard)' at 'tags.1.member.value' failed to satisfy constraint: Member must satisfy regular expression pattern: ^([\p{L}\p{Z}\p{N}_.:/=+\-@]*)$
│ 
│   with module.ecs_service.aws_lb_target_group.target_group["wildcards"],
│   on .terraform/modules/ecs_service/routing.tf line 3, in resource "aws_lb_target_group" "target_group":
│    3: resource "aws_lb_target_group" "target_group" {
│ 
╵

I guess terraform validate should also pick these up.

Whilst I'm NOT a full on go developer, considering this sort of check is hopefully a simple one to template out (a list of resource properties and the regex), it could be easily maintainable?

[rquadling]

And JUST for fun (sigh!)

╷
│ Error: updating tags for ECS (Elastic Container) Task Definition (arn:aws:ecs:eu-west-1: 0123456789012:task-definition/ticketing-dt-staging-backoffice:1): operation error ECS: TagResource, https response error StatusCode: 400, RequestID: 01234567-0123-0123-0123-0123456789ab, ClientException: Some tags contain invalid characters. Valid characters: UTF-8 letters, spaces, numbers and _ . / = + - : @.
│ 
│   with module.ecs_service.aws_ecs_task_definition.task["backoffice"],
│   on .terraform/modules/ecs_service/task_definitions.tf line 86, in resource "aws_ecs_task_definition" "task":
│   86: resource "aws_ecs_task_definition" "task" {
│ 
╵

The cause? The use of a , in the value for a tag.

[bendrucker]

Whilst I'm NOT a full on go developer, considering this sort of check is hopefully a simple one to template out (a list of resource properties and the regex), it could be easily maintainable?

Can you explain an algorithm/data structure for doing this in words or pseudocode? I'm not clear on what "naming conventions" is, is this actually about tagging limitations in various AWS service?

[rquadling]

The regex rules are defined as follows (purely examples):

resource_property_regex_rules = [
  some_resource.account_id  = "/^[0-9]{12}$/"
  some_resource.description = "/^([\p{L}\p{Z}\p{N}_.:/=+\-@]*)$/"
]

property_regex_rules = [
	tags.Name  = [
		regex = "/^[\p{L}\p{N} _./=+\-:@]+$/"
		exclude_resources = [
			a_resource_that_has_tags_as_a_key_value_pair
		]
	]
	tags.Value = [
		regex             = "/^[\p{L}\p{N} _./=+\-:@]+$/"
		exclude_resources = [
			a_resource_that_has_tags_as_a_key_value_pair
		]
	]
	tags..key = [
		regex = "/^[\p{L}\p{N} _./=+\-:@]+$/"
		exclude_resources = [
			a_resource_that_has_tags_as_set_of_objects
		]
	]
	tags..value = [
		regex = "/^[\p{L}\p{N} _./=+\-:@]+$/"
		exclude_resources = [
			a_resource_that_has_tags_as_set_of_objects
		]
	]
]

1. Get all the resources and property names. As this is only "keys", it should be fairly quick.
2. Flatten them into dot notation, so module.big_module.module.small_module.some_resource.name.property. This allows us to identify what property we're looking at.
3. Consideration of sets (some tags are key/value, others are sets of objects with Name/Value properties) will need to be handled.

The above may already be handled. I don't know.

3. Extract the regex rule from the full path - some_resource.property.
4. Is there a regex rule for the some_resource.property?
   Yes. Validate the value of the property against the regex.
   Matches = No problem
   Fails = Report module.big_module.module.small_module.some_resource.name.property has a problem value. It MAY be that there could be other failures. I'd rather have all the errors in 1 go.
5. Is there a regex for the property alone (I'm thinking of tags here)?
   Yes. Is there an exclusion for some_resource (it may be that a some_specific_resource.tag, for some reason, has a different set of rules - sort of just dealing with more inconsistencies)?
   Yes. Validate the value of the property against the regex.
   Matches = No problem
   Fails = Report module.big_module.module.small_module.some_resource.name.property has a problem value.

It maybe that the tags regex work is probably more easily identified by the nature of the tags. If they are a set of objects, then validate with one set of rules. If it is a key/value object, then validate with that set of rules.

It MAY be that not all tags on all resources have the same rules. If that case, the resource_property_regex_rules set will have an entry.

It is also NOT just about tags. Different properties have different lengths. Some are 255. Some are 128, 64, or 32. I've been told there is one that is 17. If you are generating/composing content for these values dynamically, then knowing before you've deployed half the things you're doing does feel related of lint/validation.

So would this be feasible and maintainable.

[bendrucker]

I'm NOT a full on go developer

I am not looking for you to try to pseudocode a rule, just explain the business logic. Don't get bogged down in how to implement. Explain the issue and how you'd detect it systematically. Take your stream of consciousness and distill it into a clear root cause analysis for us. Even the title needs clarification—validation rule ≠ "conventions."

Is tag validation standard across all services and the rule just implements one pattern for keys and another for values? Or is it per-service? If rules differ by service, have you checked the AWS API models (Smithy) to see if the tag patterns are available in machine readable format?

None of the above should involve reading any Go code.

It is also NOT just about tags... I've been told there is one that is 17... So would this be feasible and maintainable.

The hearsay/vagaries don't make a good case. We need documentation of either:

1. Two tag validation rule for all services (key, value)
2. Per service, but documented in Smithy models

Which, respectively, translates to:

1. A handwritten rule.
2. Adding support to the generator so that it can produce generated rules for each resource with tag support.

Or perhaps a combination of the two if tag keys were standard across all services, whereas tag values had service-specific rules.

[rquadling]

I asked ChatGPT to collate some inconsistencies.

Observed Inconsistencies in AWS API Validation of Human-Readable Text Fields

Aspect	Example Services / Fields	Allowed	Disallowed	Notes
Unicode letters	Amazon Connect Name	✔	—	Uses \p{L} and \p{Z}
Unicode letters	EventBridge RuleName	—	✔	ASCII only
Spaces in names	Amazon Connect Name	✔	—	Human-readable
Spaces in names	EventBridge RuleName	—	✔	No whitespace allowed
Newlines in descriptions	Amazon Connect Description	✔	—	Explicitly allowed
Newlines in descriptions	WAFv2 Description	—	✔	Must not start/end with whitespace
Any character allowed	Amazon Bedrock Description	✔	—	Regex [\s\S]+
Control characters	Most services	—	✔	Explicitly or implicitly rejected
Leading/trailing whitespace	WAFv2 Description	—	✔	Regex enforces non-whitespace edges
Leading/trailing whitespace	Bedrock Description	✔	—	No trimming or validation
ASCII-only names	EventBridge, IAM	✔	—	Common but undocumented rule
Unicode mark characters	Translate Description	✔	—	Uses \p{M} explicitly
Length enforced in regex	Translate Description	✔	—	{0,256} inside regex
Length enforced separately	Most services	✔	—	Regex + Length Constraints split
Regex published	WAFv2, Connect	✔	—	Explicit Pattern: in API docs
Regex not published	API Gateway v2 Stage	—	✔	Constraints described in prose
Same field name, different rules	name, description	✔	✔	Varies per service
Provider validation	Terraform AWS provider	—	✔	Does not enforce content rules
Static tooling validation	Terraform Validate / TFLint	—	✔	Errors surface only at apply
API rejection timing	AWS API	✔	—	Fails late with opaque errors

Summary

AWS applies service-specific, inconsistent, and often undocumented content validation to human-readable text fields such as names and descriptions.

These constraints are not enforced by Terraform Validate or TFLint, causing errors to surface only at apply time.

A heuristic, warning-based approach in TFLint’s AWS ruleset could surface many of these issues earlier without introducing provider-level breaking changes.