> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Using Amazon CloudWatch With Bedrock Part 6 > Guide to integrating Amazon Bedrock with CloudWatch for Lambda logging, metrics, alarms, dashboards, and structured logging to monitor model invocations, performance, and cost. Why did we do that? We demonstrated that a Lambda function can call Amazon Bedrock via the AWS SDK. The important detail is that the model invocation occurred inside the Lambda execution environment, so Lambda’s logs and execution metadata become available in CloudWatch. Example Lambda response (the function returned this to the caller): ```json theme={null} { "statusCode": 200, "body": "AWS Lambda is a serverless computing service that enables you to run code without provisioning or managing servers." } ``` Because the Bedrock call ran inside Lambda, CloudWatch receives the Lambda stdout and logger output. This gives you an end-to-end view of what your application sent, what the model produced, and how your app handled the model output. Logs: search and inspect model invocations Start in CloudWatch Logs → Log groups. Use Logs Insights to filter structured logs or text-based messages. For example: ```text theme={null} fields @timestamp, @message | filter modelId = "amazon.nova-micro-v1:0" | sort @timestamp desc | limit 10000 ``` Note: that query assumes your Lambda logger emits structured JSON with a `modelId` field. If your logs are not structured, use text filters such as `@message like /nova-micro/` or adapt to the fields your logger emits. Next, open the log group for your Lambda function. Lambda creates a log group named `/aws/lambda/`; in this example the function is named "AWS Lambda Bedrock Simple Generation", so the log group matches that name. Within the log group you’ll find one or more log streams—typically one per execution environment—so you may need to inspect several streams to find the events you want. A screenshot of the AWS CloudWatch console displaying the log group "/aws/lambda/bedrock-simple-generation" with its details (ARN, creation time, retention) and a list of log streams. A large mouse pointer is visible near the bottom of the screen. Open the most recent stream to view everything the Lambda function wrote to stdout and to the logger. Here is a representative logs excerpt that includes initialization, the received event, the Bedrock request/response, and the Lambda report: ```text theme={null} No older events at this moment. Retry 2026-06-10T15:03:30.435Z INIT_START Runtime Version: python:3.14.v43 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:28933846e9c8fabbcf0f38cf337c13c4e46a0f226f1ff0559d98c271ed4b22d8 [INFO] 2026-06-10T15:03:30.845Z Found credentials in environment variables. START RequestId: d69c4842-3429-414d-ad89-3f1996e28fcb Version: $LATEST [INFO] 2026-06-10T15:03:30.994Z d69c4842-3429-414d-ad89-3f1996e28fcb Lambda function started [INFO] 2026-06-10T15:03:30.994Z d69c4842-3429-414d-ad89-3f1996e28fcb Received event: {"key1": "value1", "key2": "value2", "key3": "value3"} [INFO] 2026-06-10T15:03:30.995Z d69c4842-3429-414d-ad89-3f1996e28fcb BEDROCK_REQUEST: Calling model [INFO] 2026-06-10T15:03:31.671Z d69c4842-3429-414d-ad89-3f1996e28fcb BEDROCK_RESPONSE: AWS Lambda is a serverless computing service that enables you to run code without provisioning or managing servers. END RequestId: d69c4842-3429-414d-ad89-3f1996e28fcb REPORT RequestId: d69c4842-3429-414d-ad89-3f1996e28fcb Duration: 690.08 ms Billed Duration: 1246 ms Memory Size: 128 MB Max Memory Used: 93 MB Init Duration: 555.07 ms No newer events at this moment. Auto retry paused. Resume ``` This output is application-level logging produced in your code via structured logging calls such as `logger.info()` or `logger.exception()`. A plain `print()` would also appear in CloudWatch Logs, but using the standard logging module gives timestamps, levels, and consistent structure that supports reliable filtering and analysis. Use structured logging in Lambda (for example `logger.info(...)`) so CloudWatch Logs and Logs Insights can filter and parse your model invocation fields. Structured logs are easier to query, alert on, and integrate with dashboards. What logs give you (end-to-end visibility) * Application request payloads sent to Bedrock (client request). * Model responses returned by Bedrock (model output). * Application handling of model output, including errors and downstream actions. Metrics: Bedrock metrics in CloudWatch CloudWatch Metrics → All metrics shows available namespaces for the region. If Bedrock is enabled in your region, you will see a Bedrock namespace exposing per-model metrics such as invocation count, input token count, and invocation latency. Select the Bedrock namespace and filter by model ID (for example `amazon.nova-micro` and `amazon.nova-pro`) to view: * Invocations — number of model calls * InputTokenCount — tokens consumed (useful for cost/usage analysis) * InvocationLatency — latency distribution and percentiles You can overlay metrics from multiple models, change chart types, and adjust the time window to analyze both recent and historical behavior. A screenshot of the AWS CloudWatch Metrics console showing selected metrics (e.g., InputTokenCount, Invocations) for amazon.nova model instances. The right side displays a stacked time-series area chart and the lower pane lists metric names and alarm statuses. Metric examples and uses | CloudWatch artifact | Primary use | Example | | - | -: | - | | Log groups & streams | Request-level debugging and tracing | Inspect `/aws/lambda/bedrock-simple-generation` log streams for model request/response | | Metrics (Bedrock namespace) | Aggregation, trends, SLA analysis | `Invocations`, `InputTokenCount`, `InvocationLatency` | | Alarms | Automated detection & remediation | Alarm when 5-min avg Invocations > 3000 for `amazon.nova-micro` | Alarms: automatic detection and response Create an alarm in CloudWatch → Alarms by selecting a Bedrock metric, choosing an aggregation/evaluation period, and setting a threshold. For example, alarm when the five-minute average invocations for Amazon Nova Micro exceeds 3,000. A screenshot of the AWS CloudWatch Alarms console showing a list of alarms, their states (OK, In alarm, Insufficient data), actions enabled, and conditions. The left sidebar navigation and top browser tabs are also visible. When configuring alarm actions you can: * Send notifications via Amazon SNS (email, SMS, push). * Trigger a Lambda function for automated remediation. * Call Auto Scaling or EC2 actions. These capabilities let you connect metric-based detection with operational workflows. A screenshot of the AWS CloudWatch "Create alarm" page showing a small Invocations metric chart on the left and the alarm configuration panel on the right. The Conditions section is visible with a Static threshold selected and a threshold value of 3000 being entered. After selecting actions (SNS topic, Lambda, etc.), finalize and enable the alarm: A screenshot of the AWS CloudWatch "Create alarm" console on the Configure actions step, showing notification settings with "In alarm" selected and options to send to an SNS topic. Below are buttons to add Lambda, Auto Scaling, and EC2 actions. Combine logs, metrics, and alarms for robust observability * Logs: detailed request-level context for troubleshooting. * Metrics: aggregated signals for trends, performance, and cost analysis. * Alarms: automated detection and response tied to notifications or remediation workflows. Benefits you can expect when using CloudWatch with Bedrock * Clear visibility into model usage and the factors that drive cost. * Faster identification of performance issues because device-level and model-level evidence is available. * Anomaly detection and threshold alarms to catch sudden usage spikes (CloudWatch supports anomaly detection models that compare current values to historical baselines). * Better operational control of GenAI apps through dashboards, alerts, and automated remediation. To summarize: CloudWatch turns Bedrock activity into measurable signals you can monitor, analyze, and act upon. Next steps * Implement structured logging in your Lambda handlers to emit modelId, prompt tokens, and response metadata. * Create dashboards that combine both application-level logs (using Logs Insights queries) and Bedrock metrics for a single-pane-of-glass view. * Add alarms for high invocation count, sudden latency increases, or token consumption spikes, and connect alarms to SNS or automated remediation Lambdas. References and further reading * [AWS CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData.html) * [Amazon Bedrock documentation](https://docs.aws.amazon.com/bedrock/) * [Amazon CloudWatch Alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) That wraps up this lesson on using CloudWatch with Bedrock. A hands-on lab is a great next step to measure Bedrock usage and performance using logs, metrics, and alarms. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.