info FYI AWS use “CloudWatch” in docs, “cloudwatch“ in cli/sdk, “monitoring” as the API endpoint, and “cloud-watch” in other service API calls like when setting flow logs for VPC, log_destination_type = “cloud-watch-logs”

Custom log groups

Now it’s possible to use a custom log group for a lambda function. Use this to send logs from multiple lambda functions to the same log group - each function gets it’s own log stream! Previously, every lambda function created it’s own cloudwatch log group (with a random suffix). This log group wasn’t removed up if the function was deleted. A log expiry duration like 7 days would only delete the log streams inside the log group. This resulted in proliferation of dead log groups which had to be deleted/cleaned up manually. The problem is severe in accounts where there are lots for short lived lambda deployments, like lower development environments.

Ref

cloudwatch log query

fields @timestamp, eventSource, eventName, @message
| filter ispresent(errorCode) and readOnly = 0 and userIdentity.accountId = '000123456789'

fields @timestamp, recipientAccountId, eventName, eventSource, userIdentity.arn, @message
| filter eventName in ["RunInstances","AttachInternetGateway","CreateEgressOnlyInternetGateway","AssociateAddress","CreateVpcPeeringConnection","AcceptVpcPeeringConnection"] and not ispresent(errorCode)

fields @timestamp, recipientAccountId, eventName, eventSource, userIdentity.arn, @message
| filter eventName in ["RunInstances"] and not ispresent(errorCode)
| filter requestParameters.networkInterfaceSet.items.0.associatePublicIpAddress=0

cloudwatch

Composite alarms can send Amazon SNS notifications when they change state, and can create Systems Manager OpsItems or incidents when they go into ALARM state, but can’t perform EC2 actions or Auto Scaling actions.