- Newest
- Most votes
- Most comments
There are three different elements to be managed: 1) configuring the sharing between source and monitor accounts, 2) creating metrics and 3) creating alarms based on those metrics.
-
Configuration of the source side of the sharing is set up with IAM, which can be automated with CloudFormation. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html provides the template. The monitoring side of the sharing looks to be console only at this point, which is a shame, but in most cases I guess you'd only want to do this once so not too much of an overhead.
-
Metrics stay in the source accounts so can be managed as they are in a non-shared account: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudwatch-alarm-metric.html
-
Ideally the metric property would have an AccountId property. Perhaps this is what's coming soon? As a work-around you can use the Metrics property of the alarm with a MetricDataQuery, which does have an AccountId property. That would make an alarm something like this for a cross account alarm on EC2 CPU, deployed to the monitoring account based on a metric from a source account:
Resources:
CrossRegionAlarm:
Type: AWS::CloudWatch::Alarm
Properties:
AlarmDescription: Alarm to prove cross account works in CFN
Threshold: '80'
ComparisonOperator: GreaterThanThreshold
EvaluationPeriods: '1'
Metrics:
- Id: metricOne
AccountId: '<your source account here>'
Label: EC2 Max CPU in account
MetricStat:
Metric:
Dimensions:
- Name: InstanceId
Value: <your instance id>
MetricName: CPUUtilization
Namespace: AWS/EC2
Period: '60'
Stat: Maximum
ReturnData: True
Relevant content
- asked 4 months ago
- Accepted Answerasked 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a month ago
- AWS OFFICIALUpdated 2 months ago
- AWS OFFICIALUpdated 5 months ago