[chatbot] L2 should know log group is always created in us-east-1

[humanzz]

❓ General Issue

There are global AWS services that publish metrics/logs to us-east-1 regardless of the region of the stack where they are being deployed e.g. Chatbot. Unfortunately, I don't have an aggregate list for all such services.

For customers deploying stacks in non us-east-1 region, this poses challenges to configure resources (e.g. log groups, set retention periods) and/or create resources e.g. alarms via CDK/CloudFormation.

There're currently 2 features which ease these pains

1. CloudWatch cross-region dashboards
2. CDK's LogRetention custom resource and its cross-region support

I think there are multiple layers to this story

1. CloudWatch resources (CloudFormation/CDK) e.g. Alarms do not support cross-region metrics
2. CDK does not provide resources/guardrails for cross-region resources e.g. log groups, failing to create alarms based on cross-region metrics

• In a recent PR for Chatbot's SlackChannelConfiguration, I was looking to expose metrics methods and log group
• If trying to import the loggroup from arn of a cross-region log group, the import succeeds, however the resulting ILogGroup exposes methods e.g. addStream which are likely to generate wrong resources
• metrics are cross-region, and can be used correctly with dashboards. However, when trying to use the metric in an Alarm, a wrong resource will be generated which drops the region and creates an alarm that is useless and deceiving the customer into a false sense of safety.

The Question

I think the minimum should be to build guardrails for resources like log groups/alarms that represent cross-region resources such that if they get used to create dependent resources, errors should be thrown to inform the user that this is not supported.

Environment

• CDK CLI Version: 1.62.0

[rix0rrr]

The only way for us to add this information is to build an L2 construct.

If we have an L2 construct, it should know about this kind of behavior.

If we don't have an L2 construct, then we don't have a place to put any kind of knowledge/behavior like that. There are no other ways for us to build "guard rails" like that.

There's no point in this being a generic "frameworky" ticket. Unless I'm misunderstanding, we should treat this as bug reports against individual services with weird behaviors (such as Chatbot). Redirecting.

[humanzz]

I do agree that this requires L2 constructs and that it's through L2 constructs that the right object representations for cross-region log groups and metrics should be created (metrics already support that, log groups there's no such representation) and then the Global services L2 constructs should use an expose them. If you ask me more concretely about what I hope to see

1. Some object/representation for a cross-region log group or at the very least for ILogGroup methods to throw errors when the log group is cross-region. Any L2 construct accepting ILogGroup should implement guardrails if it's creating resources based on those
2. Alarms should be updated to not silently accept cross-region metric objects and should throw errors
3. Any Global L2 service should expose the correct metric/log group representations... and be smart in knowing whether it's running in us-east-1 or running cross-region

Having said that, I think it's wrong to classify this issue as [chatbot] as there's nothing wrong in chatbot right now; it doesn't expose a property for log group... and it exposes metrics using the correct region.

If you have to classify this as anything that's not general I'd say it's for both [logs][cloudwatch] as a 1st step

1. [logs] to allow representing cross-region log groups
2. [cloudwatch] so that alarms don't incorrectly generate the wrong alarm resources based on metrics that are cross-region

[MrArnoldPalmer]

Moving this to @aws-cdk/aws-cloudwatch upon further inspection.

[github-actions]

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.