AWS Service Configuration for Log Ingestion
Last updated on 11 June, 2025LogicMonitor needs Amazon Web Services (AWS) service configuration for log ingestion because it enables the platform to collect and analyze log data generated by your AWS services. LogicMonitor provides a centralized view of your entire cloud environment, enabling you to monitor performance, troubleshoot issues, and identify potential problems within your AWS applications by analyzing the detailed logs generated by different AWS services.
For logs that are ingested using CloudFormation stacks, you need to create a CloudFormation template that defines stacks. Stacks are AWS resources for LogicMonitor to access and monitor your infrastructure, including IAM roles with appropriate permissions. After you deploy the CloudFormation stack to provision the resources within your AWS environment, LogicMonitor will begin to collect data from your AWS services. For more information about captured logs using AWS CloudWatch, see Lambda Function Deployment for AWS Logs Ingestion.
Metadata for AWS Logs
The following table lists metadata fields for the AWS Logs integration with LM Logs. The integration looks for this data in the log records and adds the data to the logs along with the raw message string.
Property | Description | LM Mapping | Default |
arn | Amazon Resource Name, unique identifier for AWS resources. | arn | No |
awsRegion | Region for the AWS resource. | region | No |
eventsource | The source service sending the event. | _type | Yes |
ResourceType | Indicates from where the AWS logs are coming from. It also indicates the location of the deployed service. | ResourceType | Yes |
Supported AWS Services for Log Ingestion
For AWS logs that do not use CloudFormation stacks, configurations must occur on the AWS side. The following lists each supported AWS service:
- AWS EC2 Logs
- AWS ELB Access Logs
- AWS RDS Logs
- AWS Lambda Logs
- AWS EC2 Flow Logs
- AWS NAT Gateway Flow Logs
- AWS CloudTrail Logs
- AWS CloudFront Logs
- AWS Kinesis Data Streams Logs
- AWS Kinesis Data Firehose Logs
- AWS ECS Logs
- AWS EKS Logs
- AWS Bedrock Logs
- AWS EventBridge CloudWatch Events Logs
Configure Log Forwarding for AWS
After deploying the Lambda function, configure the individual AWS services to forward logs to the Lambda function. You can find instructions for forwarding logs from the supported AWS services below.
Forwarding EC2 logs
- Open the CloudWatch console using the AWS CloudWatch Logs Agent. For more information, see Quick Start: Install and configure the CloudWatch Logs agent on a running EC2 Linux instance from Amazon.
- Select Actions > Create Lambda subscriptions filter.
- In the Create Lambda subscription filter window, select Lambda Function > LMLogsForwarder (or a different name you used for the Lambda function during stack creation).
- Select Start streaming.
Forwarding ELB Access logs
- In the EC2 navigation page, select Load Balancers and select your load balancer.
- Navigate to Attributes > Access logs andselect Configure access logs.
- Select Enable access logs and select the S3 bucket used to store the logs. You can create a bucket if it doesn’t exist.
- In the S3 bucket, select Advanced settings > Events andadd a notification to All object create events.
- Select Lambda function.
- Select LMLogsFowarder (or a different name you used for the Lambda function during stack creation).
- Select Start streaming.
Forwarding RDS logs
- Configure your RDS instance to send the logs to CloudWatch. For more information, see Monitor Amazon Aurora MySQL, Amazon RDS for MySQL and MariaDB logs with Amazon CloudWatch from Amazon.
- In the CloudWatch console, select the log group that is forwarding the RDS logs.
- Navigate to Actions > Create Lambda subscription filter andselect Lambda function.
- Select LMLogsFowarder (or a different name you used for the Lambda function during stack creation).
- Select Save changes.
Forwarding Lambda logs
- In the CloudWatch console, select log group that is forwarding the Lambda logs.
- Navigate to Actions > Create Lambda subscription filter andselect Lambda function.
- Select LMLogsFowarder (or a different name you used for the Lambda function during stack creation).
- Select Save changes.
Forwarding EC2 Flow logs
- In the Lambda role policy, add the following lines to the permissions:
"logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"
- Navigate to Trust Relationship and add the following line to Service Tag Role:
"vpc-flow-logs.amazonaws.com"
- Create a log group in CloudWatch with the name
/aws/ec2/networkInterface.
- Navigate to the Network Interfaces pageto find your EC2 instance ID. Select the Network Interface row and create a flow log with the following settings:
- Destination Log Group:
/aws/ec2/networkInterface
- IAM Role: the service tag role you previously created.
- Destination Log Group:
- In the Log record format, select Custom Format. The first value under Log Format should be
instance-id
. Set other values depending on your requirements. For more information, see Logging IP traffic using VPC Flow Logs from Amazon. - Navigate to the
/aws/ec2/networkInterface
Log Group. - Navigate to Actions > Subscription filters > Create Lambda subscription filter.
- Select LMLogsFowarder (or a different name you used for the Lambda function during stack creation) and provide the Subscription filter name.
- Select Start Streaming.
Forwarding NAT Gateway Flow logs
- In the Lambda role policy, add the following lines to the permissions:
"logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"
- Navigate to Trust Relationship and add the following line to Service Tag Role:
"vpc-flow-logs.amazonaws.com"
- Create a log group in CloudWatch with the name
/aws/natGateway/networkInterface.
- Navigate to the Network Interfaces page for your NAT Gateway ID. Select the Network Interface row and create a flow log with the following settings:
- Destination Log Group:
/aws/natGateway/networkInterface
- IAM Role: the service tag role you previously created.
- Destination Log Group:
- Navigate to the
/aws/ec2/networkInterface
Log Group. - Navigate to Actions > Subscription filters > Create Lambda subscription filter.
- Select LMLogsFowarder (or a different name you used for the Lambda function during stack creation) and provide the Subscription filter name.
- Select Start Streaming.
Forwarding CloudTrail logs
- On the CloudTrail page of your AWS portal, select Create Trail.
- Provide the Trail name.
- Uncheck Log file SSE-KMS encryption if you do not want to SSE-KMS encrypt your log files.
- Check CloudWatch Logs Enabled and provide the following log group name: /aws/cloudtrail
- If you have existing IAM role CloudTrail permissions, you can provide them in the IAM role field. Otherwise, you can create a new role.
- On the next screen, select the Event type for the logs that you would like to collect. For more information, see CloudTrail concepts from Amazon.
- On the next screen, review the provided configuration and select Create Trail.
- Navigate to the CloudWatch log group page and select the /aws/cloudtrail log group.
- Navigate to Actions > Subscription filters > Create Lambda subscription filter.
- Select LMLogsFowarder (or a different name you used for the Lambda function during stack creation) and provide the Subscription filter name.
- Select Start Streaming.
Forwarding CloudFront logs
- On the CloudFront page of your AWS portal, select the distribution to collect logs.
- Select On for Standard Logging.
- In S3 bucket for logs, select the bucket to store the logs.
- Select Create Distribution.
- Navigate to the S3 bucket you selected to store logs.
- Navigate to Properties > Event notifications and select Create event notification.
- Provide an Event name.
- In the Destination’s Lambda function tab, select LMLogsForwarder (or a different name you used for the Lambda function during stack creation).
- Select Save changes.
Forwarding Kinesis Data Streams logs
Since logs from Amazon Kinesis Data Streams are filtered from AWS CloudTrail, you can follow the CloudTrail instructions to ingest these logs. For more information, see Forwarding CloudTrail logs.
Forwarding Kinesis Data Firehose logs
Amazon Kinesis Data Firehose consists of two kinds of logs: API Logs and Error Logs. API Logs are collected from CloudTrail, so you can follow the CloudTrail instructions to ingest these logs. For more information, see Forwarding CloudTrail logs.
To ingest Error logs:
- In Create delivery system > Configure system, select Enabled for Error Logging.
- This creates a log group in CloudWatch with the delivery system’s name in the format:
/aws/kinesisfirehose/<Delivery system name>
- Navigate to Actions > Subscription filters > Create Lambda subscription filter.
- Select LMLogsFowarder (or a different name you used for the Lambda function during stack creation) and provide the Subscription filter name.
- Select Start Streaming.
Forwarding ECS logs
Since logs from Amazon ECS are filtered from AWS CloudTrail, you can follow the CloudTrail instructions to ingest these logs. For more information, see Forwarding CloudTrail logs.
Forwarding EKS logs
Pre-requisites:
On EKS Cluster, do the following:
- Create a nodegroup on cluster.
- Add Amazon CloudWatch Observability plugin (add-on).
– Or –
Before the EC2 instance logs can be forwarded to LM Logs, they need to be collected into CloudWatch Logs. Forward different EKS logs to cloudwatch.
- To forward application metrics to cloudwatch, see Setting up the CloudWatch agent to collect cluster metrics from Amazon.
- To forward application logs to cloudwatch, see Send logs to CloudWatch Logs from Amazon.
- To forward logs using Fluenbit, see Set up Fluent Bit as a DaemonSet to send logs to CloudWatch Logs from Amazon.
After adding the plugin, the following five different log groups are created into CloudWatch using your cluster-name:
/aws/containerInsights/<cluster-name>/application
/aws/containerInsights/<cluster-name>/host
/aws/containerInsights/<cluster-name>/performance
aws/containerInsights/<cluster-name>/dataplane
/aws/eks/<cluster-name>/cluster
- In the EKS Cluster, create a nodegroup in the EKS cluster.
- Add the Amazon CloudWatch Observability plugin (add-on). For more information, see Quick start with the Amazon CloudWatch Observability EKS add-on from Amazon.
Sending EKS logs
- Go to CloudWatch and select the log group that you want to forward logs.
- Navigate to Actions > Subscription filters > Create Lambda subscription filter.
- Select LMLogsFowarder (or a different name you used for the Lambda function during stack creation) and provide the Subscription filter name.
- Select Start Streaming.
Forwarding Bedrock logs
- The following two types of logs are supported by AWS Bedrock:
- Model invocation logging. For setting up the Model Invocation Logging, see Monitor model invocation using CloudWatch Logs from Amazon.
- Knowledge Base Logging. For sending logs from the knowledge base to Cloudwatch, see Monitor knowledge bases using CloudWatch Logs from Amazon.
- Create a log group in CloudWatch with name that contains “bedrock”.
Note: The log streams name for modelinvocation logs contain the string “modelinvocations”. The log group name for knowledge-based logs contains the string “knowledge-base” or “vendedlogs”.
- Navigate to the Log Group you created with the name that contains “bedrock”.
- Navigate to Actions > Subscription filters > Create lambda subscription filter.
- Select Lambda Function and select LMLogsForwarder (or a different name you used for the Lambda function during stack creation).
- Select Start streaming.
The Model Invocation logs will be mapped to the Bedrock model resource created in LogicMonitor. The knowledge-base logs will be mapped to the AWS account resource created in LogicMonitor.
Forwarding EventBridge (CloudWatch) logs
Amazon EventBridge (CloudWatch) Events provide real-time event streams that describe changes in AWS resources. You can use simple rules to setup, match, and route events to functions or streams through AWS EventBridge. For more information, see CloudWatch Events from Amazon.
Requirements
Set up your AWS and LogicMonitor integration. For more information, see AWS Logs Ingestion.
Creating Amazon EventBridge Rule
Create one rule for each service. The event pattern in the rule specifies which service events will be sent to the target. For the target, specify the Lambda function as LMLogsForwarder or the Lambda that sends logs to LM. The currently supported services for CloudWatch events are S3, Lambda, ECS, Kinesis, SQS, EC2, and Account.
To create a rule to setup CloudWatch events, do the following:
- Go to Amazon EventBridge web page and select Rules.
- On the Define rule detail page, provide the name and description for the rule.
- To choose a Rule type, select Rule with an event pattern. This ensures that whenever an event is generated, it sends the events to the target.
- For Method, select the Use Pattern Form method to get readymade pattern for a specific service.
- In the Event source field, select AWS services.
- In the AWS service field, select a service. LogicMonitor currently supports S3, Lambda, ECE, Kinesis, SQS, EC2, and Account services for CloudWatch events.
- In the Event type field, select AWS API Call via Cloudtrail. As per the current implementation, LogicMonitor supports only AWS API calls via Cloudtrail. The events coming from the other types are ignored.
- In the Select target(s) tab, do the following:
- For Target types, select AWS service.
- For Select a target, select Lambda function.
- For Function, select LMLogsForwarder or the Lambda that sends logs to LM.
9. Select Next to review the rule and then select Create.
When the rule is successfully created, you can view the logs in the LM Logs page. You can also view the message in JSON format in the Overview panel.
For more information, see Creating Amazon EventBridge rules that react to events from Amazon.