Hi all, I'm trying to create an alarm action and add it to an existing alarm; the alarm is created in a separate stack where the metric is created and the action is created in the service stack, where an ecs service and its auto scaling policies is defined, and I would like to create the upscale and downscale actions and attach them to the existing alarm in the service stack by exporting the alarm arn from the metric stack, is this possible? thank you!

This sounds like a use case for stack references to me. You can reference the outputs of another stack using the StackReference resource.

yes, i got that setup already, but im not sure if it's possible to simply add an autoscaling action separately from the creation of the alarm... the aws provider documentaiton shows how to create an alarm with actions in one single resource:

bat = aws.autoscaling.Policy(...)
bat_metric_alarm = aws.cloudwatch.MetricAlarm(
    ...
    alarm_actions=[bat.arn]
)

but not how to add the action to an existing alarm... is that possible at all? i thought it was...

Ah, I see. I misunderstood the question. I would suspect you could just add that line to your stack

alarm_actions=[myReferenceArn]

and it you can update the existing alarm without replacing it. The AWS api supports updating the AlarmActions. Caveat: I am not super familiar with this resource.

That sounds to me like its the wrong way up - the metric and the alarm are dependent on the service rather than the other way round. I'd probably be thinking in terms of the autoscale policy arn as an output from the service stack and then using that with the alarm?

well, the metric is just the metric, and an alarm can be created based on what that metric means in practice, so, for example, reaching 90% or 95% ram in an ECS task can be in alarm no matter what, one can then decide to create whatever actions is needed, for example one may attach an autoscaling policy or simply send an email to an ops engineer... I suppose I was expecting the ability to create actions and then attach/detach them to a given pre-existing alarm but that doesn't seem the case as the alarm actions are only modified through a put method to the alarm resource, not by posting/creating a separate "action association" resource... the only way to decouple alarm creation to actions seems to be by setting up the alarm with a single action to post the alarm transition to an sns topic and then subscribe lambdas (or other compute) to it

I'm not nearly good enough at Metrics / Alarms (yet) - once upon a time I had colleagues who were much better 🙂 But this is about dependencies rather than anything else and the alarm depends on the metric and the action, the metric depends on the service (unless it doesn't in that it's more generic? that's a piece I'm not clear on!), and the action depends on the service... So we end up with interesting problems of how to group things together to reflect that dependency graph and those don't necessarily match the way we think about grouping things. I'm adding IaC as I go on top of existing "stuff" and I'm almost certain I'd have circular dependencies if I were to try to bring this all up from scratch 😖 Arguably the best solution to at least some of my problems is to get to a point where I can and do bring it all up from scratch 😁

oh i see the confusion... no, metrics do not in general depend on the service: suppose you have an info email address and you want to be notified when the inbox grows too large; in this case one can create a metric to track the number of unopened emails in the inbox and then an action to email me depending on this metric; in this example the metric is populated by a little lambda that checks the inbox size every 30 secs and post the number of unopened emails to the "inbox-size-metric"; a "too-many-unopened-emails" can be created when the inbox reached 1,000 emails and trigger the sending of an email; suppose that then you develop AI service that summarises the info emails, extracts action lists from the email and posts the actions to an employee worklog, a new action to scale up/down the AI service when the alarm triggers is then only added at a later stage (when the AI service has been developed)...