When “DEFAULT” Isn’t: A Small Regex Bug in AWS ApplicationInsights CloudFormation

When “DEFAULT” Isn’t: A Small Regex Bug in AWS ApplicationInsights CloudFormation

I ran into a subtle bug while deploying a CloudFormation stack using AWS::ApplicationInsights::Application. The resource is designed to help you configure CloudWatch Application Insights monitoring through Infrastructure as Code—a great idea in theory. But in practice, I hit a wall over something that should have been simple: setting the Tier field in a ComponentMonitoringSetting.

Here’s what happened.

According to the AWS CloudFormation documentation, the Tier parameter accepts several uppercase string values—things like DEFAULT, SQL_SERVER, and POSTGRESQL. These are all valid according to the underlying CloudWatch API.

However, when I set Tier: DEFAULT, CloudFormation failed the template at validation time with the error: 

plaintext

E3031 'DEFAULT' does not match '^[A-Z][[A-Z]_]*$'  

At first glance, it looked like maybe I’d mistyped something. But this wasn’t a typo in the value—it was an issue with the regular expression used in the resource schema itself.

Why the Regex Fails

The regex pattern ^[A-Z][[A-Z]_]*$ is invalid. Specifically, [[A-Z]_]* is not a legal or meaningful character class. It's likely a mistaken attempt to allow uppercase letters and underscores, but it ends up confusing the validator. The correct version should be: 

plaintext

^[A-Z][A-Z_]*$

That would successfully match values like DEFAULT, SQL_SERVER, and POSTGRESQL—which are, again, valid and supported by the service API.

This isn’t a failure in the service. It’s a minor schema bug in the CloudFormation validation layer—just enough to block deployments that rely on Infrastructure as Code.

What You Can Do Now

Until AWS corrects the schema, here are a few non-destructive workarounds:

• Let CloudFormation decide: Skip the Tier field altogether and just use ComponentConfigurationMode: DEFAULT. That often applies the appropriate monitoring profile automatically.
  
  
• Move to the CLI or SDK: You can configure your Application Insights setup outside of CloudFormation using the AWS CLI or SDK, which bypasses the validation layer entirely.
  
  
• Create a Lambda-backed custom resource: If you must set Tier explicitly in your IaC flow, you can use a Lambda function to call the AWS SDK from within the CloudFormation stack. It’s a bit more work, but it restores control without giving up your stack definition.

No Blame—Just Feedback

This is a good example of how even minor issues in schema validation can break otherwise valid deployments. The service supports what you're asking for, but the template won’t even make it past the front door because of a malformed regex. It happens. And it’s why we report things calmly, clearly, and with the bigger picture in mind.

I’ve submitted a support case to AWS so they can fix the schema in a future update. In the meantime, hopefully this saves someone else a few hours of confusion.

If you’ve hit this issue too—or found another workaround—I’d love to hear how you handled it.

Need AWS Expertise?

If you're looking for guidance on AWS or any cloud challenges, feel free to reach out! We'd love to help you tackle your projects. 🚀

Email us at: info@pacificw.com

Image: Gemini