The AWS integration is used to fetch logs and metrics from Amazon Web Services.
Use the AWS integration to collect metrics and logs across many AWS services managed by your AWS account. Visualize that data in Kibana, create alerts to notify you if something goes wrong, and reference data when troubleshooting an issue.
Extra AWS charges on CloudWatch API requests will be generated by this integration. Please see API Requests for more details.
The AWS integration collects two types of data, logs and metrics, across many AWS services.
Logs help you keep a record of events that happen in your AWS account. This may include every user request that CloudFront receives, every action taken on your services by an AWS user or role, and more.
Metrics give you insight into the state of your AWS services. This may include understanding where you're spending the most and why, the volume of storage you're using, CPU utilization of your instances, and more.
For a complete list of all AWS services and the data streams available for each, see Reference.
The AWS integration uses different AWS API to bootstrap and collect metrics and logs. The following table illustrates which APIs are used by the AWS integration and how.
| AWS API Name | AWS API Count | Frequency | Datastream |
|---|---|---|---|
| IAM ListAccountAliases | 1 | Once on startup | all |
| STS GetCallerIdentity | 1 | Once on startup | all |
| EC2 DescribeRegions | 1 | Once on startup | all |
| CloudWatch ListMetrics | Total number of results / ListMetrics max page size (500, based on AWS API ListMetrics | Per region per collection period | metrics related only |
| CloudWatch GetMetricData | Total number of results / GetMetricData max page size (500, based on AWS API GetMetricData | Per region per namespace per collection period | metrics related only |
| CloudWatch DescribeLogGroups | Total number of results / DescribeLogGroups max page size (50, based on AWS API DescribeLogGroups | Per region per collection period | logs related only |
| CloudWatch FilterLogEvents | Total number of results / FilterLogEvents max page size (1MB or 10'0000 events, based on AWS API FilterLogEvents | Per log group per region per collection period | logs related only |
| CostExplorer GetCostAndUsage | Total number of results / GetCostAndUsage max page size (8192, based on AWS API GetCostAndUsage | Per CostExplorer Group Definition per region per collection period | AWS Billing |
| S3 ListObjectsV2 | Total number of results / ListObjectsV2 max page size (up to 1,000, based on AWS API FilterLogEvents | Per bucket per region per collection period | logs related only |
| S3 GetObject | 1 | Per object per collection period | logs related only |
| SecurityHub GetFindings | Total number of results / GetFindings max page size ( 100, based on AWS API GetFindings | Per region per collection period | AWS Security Hub |
| SecurityHub GetInsights | Total number of results / GetInsights max page size ( 100, based on AWS API GetInsights | Per region per collection period | AWS Security Hub |
Each of these APIs may generate extra charges on your AWS Account. Please refer to AWS Princing for more information.
For each AWS service you enable metrics data collection for, the AWS integration will collect metrics in all the AWS regions where there are available metrics for that service. The collection period is also set to sensible defaults that should fit the majority of use cases.
The extra-charges generated by GetMetricData API calls are proportional to the frequency we collect data and the amount of metrics that are queried for. If you are concerned about the cost derived by enabling any metrics collection, we recommend reviewing the following parameters:
Regions. By selecting only the AWS Regions you are interested in, you can make sure that no unnecessary Cloudwatch API call is performed against irrelevant AWS regions.Collection PeriodandData Granularity. By settingCollection PeriodandData Granularitytogether, you can control, respectively, how frequently you want your metrics to be collected and how granular they have to be. If you can tolerate an extra delay in retrieving metrics as trade off, you may consider settingdata_granularityand increase the value forCollection Periodto reduce extra charges. For example, settingData Granularityto your current value forPeriod, and doubling the value ofPeriod, may lead to a 50% savings.Tags Filter. By specifying a tag, you can ensure that no Cloudwatch API call is performed for AWS resources you are not interested in.
The include_linked_accounts parameter is used to enable the inclusion of metrics from different accounts linked to a
main monitoring account. By setting this parameter to true, users can gather metrics from multiple AWS accounts that are
linked through the CloudWatch cross-account observability.
By default, the include_linked_accounts parameter is set to false, meaning that only metrics from the main monitoring
account are collected. When set to true, the parameter allows the CloudWatch ListMetrics API to include metrics from
the monitoring account and all linked source accounts in the returned data, providing a comprehensive cross-account view.
Note: Users should ensure that the necessary IAM roles and policies are properly set up in order to link the monitoring account and source accounts together. Please see Link monitoring accounts with source accounts for more details.
Before using the AWS integration you will need:
- AWS Credentials to connect with your AWS account.
- AWS Permissions to make sure the user you're using to connect has permission to share the relevant data.
AWS credentials are required for running AWS integrations. There are a few ways to provide AWS credentials:
- Use access keys directly
- Use temporary security credentials
- Use a shared credentials file
- Use an IAM role Amazon Resource Name (ARN)
Access keys are long-term credentials for an IAM user or the AWS account root user. To use access keys as credentials, you need to provide:
access_key_id: The first part of the access key.secret_access_key: The second part of the access key.
For more details see AWS Access Keys and Secret Access Keys.
Temporary security credentials can be configured in AWS to last for some period of time.
They consist of an access key ID, a secret access key, and a security token, which is
typically returned using GetSessionToken.
IAM users with multi-factor authentication (MFA) enabled need to submit an MFA code
while calling GetSessionToken.
For more details see Temporary Security Credentials.
You can use AWS CLI to generate temporary credentials.
For example, you would use sts get-session-token if you have MFA enabled:
aws> sts get-session-token --serial-number arn:aws:iam::1234:mfa/your-email@example.com --duration-seconds 129600 --token-code 123456Then, use the response to provide the following options to the AWS integration:
access_key_id: The first part of the access key.secret_access_key: The second part of the access key.session_token: A token required when using temporary security credentials.
Because temporary security credentials are short term, after they expire, you will need to generate new ones and manually update the package configuration to continue collecting AWS metrics. This will cause data loss if the configuration is not updated with the new credentials before the old ones expire.
If you use different credentials for different tools or applications, you can use profiles to configure multiple access keys in the same configuration file. For more details see Create Shared Credentials File
Instead of providing the access_key_id and secret_access_key directly to the integration,
you will provide two advanced options to look up the access keys in the shared credentials file:
credential_profile_name: The profile name in shared credentials file.shared_credential_file: The directory of the shared credentials file.
Note: If you don't provide values for all keys, the integration will use defaults:
- If
access_key_id,secret_access_keyandrole_arnare all not provided, then the package will check forcredential_profile_name. - If there is no
credential_profile_namegiven, the default profile will be used. - If
shared_credential_fileis empty, the default directory will be used.- In Windows, shared credentials file is located at
C:\Users\<yourUserName>\.aws\credentials. - For Linux, macOS, or Unix, the file is located at
~/.aws/credentials.
- In Windows, shared credentials file is located at
An IAM role ARN is an IAM identity that you can create in your AWS account. You determine what the role has permission to do. A role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role it provides you with temporary security credentials for your role session. IAM role ARN can be used to specify which AWS IAM role to assume to generate temporary credentials. For more details see AssumeRole API documentation.
To use an IAM role ARN, you need to provide either a credential profile or
access keys along with the role_arn advanced option.
role_arn is used to specify which AWS IAM role to assume for generating temporary credentials.
Note: If role_arn is given, the package will check if access keys are given.
If they are not given, the package will check for a credential profile name.
If neither is given, the default credential profile will be used.
Specific AWS permissions are required for the IAM user to make specific AWS API calls. To enable the AWS integration to collect metrics and logs from all supported services, make sure these permissions are given:
ce:GetCostAndUsagecloudwatch:GetMetricDatacloudwatch:ListMetricsec2:DescribeInstancesec2:DescribeRegionsiam:ListAccountAliaseslogs:DescribeLogGroupslogs:FilterLogEventsorganizations:ListAccountsrds:DescribeDBInstancesrds:ListTagsForResources3:GetObjectsns:ListTopicssqs:ChangeMessageVisibilitysqs:DeleteMessagesqs:ListQueuessqs:ReceiveMessagests:AssumeRolests:GetCallerIdentitytag:GetResources
Use the AWS integration to connect to your AWS account and collect data from multiple AWS services. When you configure the integration, you can collect data from as many AWS services as you'd like.
If you only need to collect data from one AWS service, consider using the individual integration (for example, to only collect monitoring metrics for EC2, you can configure only the AWS EC2 integration).
For step-by-step instructions on how to set up an integration, see the {{ url "getting-started-observability" "Getting started" }} guide.
Some AWS services send monitoring metrics to CloudWatch with a latency to process larger than the integration collection period. This will cause data points missing or none get collected by the agent. In this case, please specify a latency parameter so collection start time and end time will be shifted by the given latency amount.
In order to check how much the latency is, you can log into the AWS CloudWatch portal. Wait till a new point to show up in AWS CloudWatch and record the current timestamp. Compare the timestamp of this latest data point with the current timestamp to see what's the difference. This difference can be used as latency.
For example, the screenshot below is taken at 2023-05-09 22:30 UTC and the timestamp for the last data point is
2023-05-09 22:15 UTC. This means there is a 15min delay between the current time and CloudWatch. With this information,
we should add a latency configuration for 15m when adding the integration.
Below is an overview of the type of data you can collect from each AWS service. Visit the page for each individual AWS integration to see details about exported fields.
| Service | Metrics | Logs |
|---|---|---|
| API Gateway | x | |
| Billing | x | |
| CloudFront | x | |
| CloudTrail | x | |
| CloudWatch | x | x |
| DynamoDB | x | |
| EBS | x | |
| EC2 | x | x |
| ECS | x | |
| ELB | x | x |
| Fargate | x | |
| Kinesis | x | |
| Network Firewall | x | x |
| Lambda | x | |
| NAT Gateway | x | |
| Redshift | x | |
| RDS | x | |
| Route 53 | x | |
| S3 | x | x |
| S3 Storage Lens | x | |
| SNS | x | |
| SQS | x | |
| Transit Gateway | x | |
| Usage | x | |
| VPC Flow | x | |
| VPN | x | |
| WAF | x | |
| Custom | x |