When you create a CloudFormation template for a Log Group, you can provide a name. This is can be very useful when navigating Cloudwatch. But the log group name needs to be unique for the entire account. There are other resource types like this.
For Proton, it would make sense to use the Service Instance name in the Log Group name. But in a Proton Service Template, it would make sense to make the log group name {{service_name}}_{{service_instance_name}}. You can't use the instance name alone, since multiple services can have instances with the same name. So this would be globally unique. But neither of these values are available, only the environment and service instance inputs. Note that service_name is available in pipelines, but not service instance templates.
The Proton sample templates actually have named log groups. It works around the lack of a globally-unique name by adding a unique_name input property. But this is a problem for two reasons. First, it's more cognitive overload for the developer and when I first used it, it confused me a bit. Second, there is no guarantee the developer enters a globally unique name, which would fail Cloudformation provisioning.
So making service and service instance name would allow properties like unique_name to be unnecessary. However there is one problem. Service and instance names can be max of 100 characters, which means {{service_name}}_{{service_instance_name}} could be up to 201 characters. If you use that for something like SQS::QueueName, which has a max length of 80 characters, a long service or service instance name could violate that length and result in CloudFormation problems. I'm not sure how to solve that problem. Maybe you could offer a property like service_instance_global_name that has a max length of 60 or something and uses some kind of hash suffix when the service or instance has a long name, like what CDK does.
This can now be used! Our public templates will be adjusted accordingly, as unique name is no longer a required field. Public documentation will follow soon
When you create a CloudFormation template for a Log Group, you can provide a name. This is can be very useful when navigating Cloudwatch. But the log group name needs to be unique for the entire account. There are other resource types like this.
For Proton, it would make sense to use the Service Instance name in the Log Group name. But in a Proton Service Template, it would make sense to make the log group name
{{service_name}}_{{service_instance_name}}
. You can't use the instance name alone, since multiple services can have instances with the same name. So this would be globally unique. But neither of these values are available, only the environment and service instance inputs. Note thatservice_name
is available in pipelines, but not service instance templates.The Proton sample templates actually have named log groups. It works around the lack of a globally-unique name by adding a unique_name input property. But this is a problem for two reasons. First, it's more cognitive overload for the developer and when I first used it, it confused me a bit. Second, there is no guarantee the developer enters a globally unique name, which would fail Cloudformation provisioning.
So making service and service instance name would allow properties like
unique_name
to be unnecessary. However there is one problem. Service and instance names can be max of 100 characters, which means{{service_name}}_{{service_instance_name}}
could be up to 201 characters. If you use that for something likeSQS::QueueName
, which has a max length of 80 characters, a long service or service instance name could violate that length and result in CloudFormation problems. I'm not sure how to solve that problem. Maybe you could offer a property likeservice_instance_global_name
that has a max length of 60 or something and uses some kind of hash suffix when the service or instance has a long name, like what CDK does.