I am struggling to match CloudWatch metric count (as shown in CloudWatch Console ) with count shown in Billing (Estimate for current month ). Attached here are both screen shots.
1) According to below billing screen shot, I should have 10+9.597 = 19.597 metric Alarms
2) According to CloudWatch Console, I have only 3 Alarms. Infact I don't remember of creating more.
I have couple of In Alarms, but in current month ( billing period July ), have only one, see screen shot below.
Couple of In Alarms are shown in red, but they are for last month, which is already billed.
Let me know please if you need more information or any specific screen shot from aws console.
4) Output of aws query
aws cloudwatch describe-alarms --query 'MetricAlarms[*].[AlarmName]' --region us-east-2 > metric-alarams
Music-ReadCapacityUnitsLimit-BasicAlarm
Music-WriteCapacityUnitsLimit-BasicAlarm
TargetTracking-table/TextNote-AlarmHigh-09765769-6e5d-6cab83249c9d
TargetTracking-table/TextNote-AlarmHigh-82c98240-0435-101ab605b404
TargetTracking-table/TextNote-AlarmLow-a0552914-7d04-bd0d74cb9d9a
TargetTracking-table/TextNote-AlarmLow-d4b5d3ff-9b62--b6fafd379abe
TargetTracking-table/TextNote-ProvisionedCapacityHigh-1fc9e0fc--8fc1-c5830689655d
TargetTracking-table/TextNote-ProvisionedCapacityHigh-e2f0ac8b--8826-fd764296f4e8
TargetTracking-table/TextNote-ProvisionedCapacityLow-3e182ade--a070-3d1a515b01a5
TargetTracking-table/TextNote-ProvisionedCapacityLow-e8f2afd9--8ccf-d7dad436cedb
TargetTracking-table/TextNote/index/textNoteSecondaryIndex-AlarmHigh-7693771a-92ee-8cd83a388fec
TargetTracking-table/TextNote/index/textNoteSecondaryIndex-AlarmHigh-b761bab7-a8e6-8386252be6b2
TargetTracking-table/TextNote/index/textNoteSecondaryIndex-AlarmLow-2bc4ee0c-95c6-31721866055d
TargetTracking-table/TextNote/index/textNoteSecondaryIndex-AlarmLow-8b591a75-be8f-ff3209a4b54e
TargetTracking-table/TextNote/index/textNoteSecondaryIndex-ProvisionedCapacityHigh-a369b9dc-8d8f-40d2bb7966cb
TargetTracking-table/TextNote/index/textNoteSecondaryIndex-ProvisionedCapacityHigh-d65c9c16-9313-aed4e691d811
TargetTracking-table/TextNote/index/textNoteSecondaryIndex-ProvisionedCapacityLow-3bd977f5-9acb-b6608ff14d91
TargetTracking-table/TextNote/index/textNoteSecondaryIndex-ProvisionedCapacityLow-f852b0c7-b066-5ac2734d9a65
TargetTracking-table/texthash-AlarmHigh-26e45329-b495-85f3eda0f92e
TargetTracking-table/texthash-AlarmHigh-7b2169a1-d914-50d8b09341d8
TargetTracking-table/texthash-AlarmLow-844f04e2-8e2d-b38bb95e8f1b
TargetTracking-table/texthash-AlarmLow-f7ae2480-7cb8-0bf1adffece6
TargetTracking-table/texthash-ProvisionedCapacityHigh-ad8c3e30-9861-feb73bb2b88f
TargetTracking-table/texthash-ProvisionedCapacityHigh-dc6e4a74-beab-1e55e10f25f6
TargetTracking-table/texthash-ProvisionedCapacityLow-7f34588a-872e-26413a88f905
TargetTracking-table/texthash-ProvisionedCapacityLow-c8bbf607-962b-c7ecd956a6f2
awsec2-i-0fc458fad8fc7fac2-LessThanOrEqualToThreshold-CPUCreditBalance
To view the alarm names of all the billable CW alarms in the us-east-2 region, use the following AWS CLI command:
aws cloudwatch describe-alarms --query 'MetricAlarms[*].[AlarmName]' --region us-east-2
You can delete them using:
aws cloudwatch delete-alarms --region us-east-2 --alarm-names ...
Related
How visualize the count of AWS IAM users in AWS Managed Grafana? Is it some Cloudwatch metrics (f.e. AWS/Usage)?
AWS cli can show this info aws iam get-account-summary with the response:
{
"SummaryMap": {
"Users": 27,
......
}
}
After thorough googling I found no Cloudwatch metrics for the IAM or other ways.
In my AWS organization we have multiple (5+) accounts and a Cloudtrail trail for management events with Cloudwatch log group for all the accounts and regions in the org.
For the log group there is a series of generic metric filters setup, each with a Cloudwatch alarm. These are all tied to one or more SNS topics and associated subscriptions and all out of the box.
For example:
aws logs put-metric-filter --log-group-name CLOUDWATCH-LOG-GROUP --filter-name FILTER-NAME --metric-transformations metricName=METRIC-NAME,metricNamespace=NAMESPACE,metricValue=1 --filter-pattern '{ ($.eventName = ConsoleLogin) && ($.errorMessage = "Failed authentication") }'
Creates a metric filter for any failed logins on console for any of the accounts that sets the metric value to 1 when a match for the filter pattern is found in the log.
Paired with
aws cloudwatch put-metric-alarm --alarm-name METRIC-NAME-alarm --metric-name METRIC-NAME --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace NAMESPACE --alarm-actions SNS-TOPIC-ARN
This creates a simple alarm that fires an event to the SNS topic.
The major drawback here however is if my org account ID is #1234 and my worker account ID is #4321 and the failed login happens at the worker account, the Alarm that is sent refers only to the org account ID and I need to login and look to figure out where this happened.
Now, I can add a dimension to the metric-transformation to include something to help me differentiate (for example recipientAccountId). That would look something like
aws logs put-metric-filter --log-group-name CLOUDWATCH-LOG-GROUP --filter-name FILTER-NAME --metric-transformations metricName=METRIC-NAME,metricNamespace=NAMESPACE,metricValue=1,dimensions={"Account"=($.recipientAccountId)} --filter-pattern '{ ($.eventName = ConsoleLogin) && ($.errorMessage = "Failed authentication") }'
But, in order for the Cloudwatch alarm to trigger, it appears that the dimension must also be included there, it isn't possible to have one Alarm for all the possible Value that exist. Which then seems to require one Alarm per recipientAccountId (ACCOUNT-ID in the below).
Ex:
aws cloudwatch put-metric-alarm --alarm-name METRIC-NAME-alarm --metric-name METRIC-NAME --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --dimensions Name=Account,Value=ACCOUNT-ID --namespace NAMESPACE --alarm-actions SNS-TOPIC-ARN
Is this correct?
All of this is really just to include some metadata with the alarm to let me know which Account triggered, is there a better solution?
How to use Cloudtrail to get who created IAM user , how to get this from logs
If the IAM user was created inside the last 90 days, you can find who created the user using CloudTrail Event history.
Using the AWS CLI:
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=CreateUser --region us-east-1
Using the Console: Go to Event History in CloudTrail Service, choose the EventName filter with a value of CreateUser. You have to use the region us-east-1 to view the events.
If the IAM user was created outside the 90 days time window, you can still find out who created the user if you have a trail enabled in CloudTrail. You can use Amazon Athena or some other method to search the log files created by CloudTrail in S3.
References:
https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-cli.html (Note the disclaimer for global services post November 22, 2021)
https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html
https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html
I'm using Ansible to configure AWS Auto Scaling Groups (ASG). Looking at the ec2_asg_module options, there's none for enabling Monitoring in cloudWatch. However, that option can be enabled either form the AWS CLI or the AWS Console.
In the Console, it is labeled as "Group Metric Collection".
Keep in mind that I do not want to monitor the EC2 instances, but the Auto Scaling Group itself.
Thank you.
I submitted a PR last year to add 2 AWS modules : boto3 and boto3_wait.
These 2 modules allow you to interact with AWS API using boto3.
For instance, you could enable group metrics on the ASG by calling enable_metrics_collection method on AutoScaling service :
- name: Enable group metrics
boto3:
service: autoscaling
region: us-east-1
operation: enable_metrics_collection
parameters:
AutoScalingGroupName: my-auto-scaling-group
Granularity: 1Minute
Feel free to give the PR a thumbs-up if you like it! ;)
I'm having trouble attaching previously created alarms to an auto scaling group policy. I have created the policy like so:
aws autoscaling put-scaling-policy --policy-name my-scaleout-policy --auto-scaling-group-name my-group --scaling-adjustment 2 --adjustment-type ChangeInCapacity
However, I can't seem to find the correct CLI command to attach an already created alarm my-cpu-alarm to the policy.
Update the existing alarm & add the policy ARN in --alarm-actions parameter.
You can use the put-metric-alarm command for this.
Note that you will have to give all the original parameters to update the alarm as they are overwritten.
You can get the alarm parameters using describe-alarm.