Configuring Services for CloudWatch

The API Gateway and Lambda services both require extra configuration to fully enable the capture of CloudWatch logging, tracing, and metrics data. We’ll cover that configuration here, while the next tutorial will step through the extra client code needed to enable tracing for DynamoDB operations.

Configuring API Gateway for CloudWatch

API Gateway requires account-level permission to write to CloudWatch logs, which we'll step through setting up shortly, in the labs. Once the service has this permission, you can then apply specific CloudWatch settings for each API Gateway resource that you define, which we'll cover here. Most of these settings are applied in the MethodSettings element of the SAM API resource. These can be applied at different levels of granularity, specifying the StageName, HttpMethod, and ResourcePath properties, if desired. In our case, we're not specifying a stage, and we’re wildcarding the latter two properties to apply one configuration to all the endpoints in our APIs.

Here’s what this configuration looks like in the admin.yaml template, shown below:

Here’s a quick overview of these configuration settings:

LoggingLevel

Sets the level of detail for API events to write to the CloudWatch logs. The options are OFF, ERROR and INFO.

DataTraceEnabled

This property determines whether full request and response logging is enabled. We’re using conditions here to only apply this logging for “Dev” environments to illustrate how you might manage this property when you have sensitive data flowing through the API.

MetricsEnabled

This property enables the gathering of CloudWatch metrics for the API.

TracingEnabled

Unlike the properties in the MethodSettings element, this property always applies for the entire API, and it enables X-Ray tracing.

Setting Up Lambda Execution Roles

As noted above, any service that wants to write to CloudWatch logs needs to be granted permission to do so in a service (or execution) role. While this service role can be assigned once, at an account-level for API Gateway, Lambdas need to be assigned individually. The sample code defines a Lambda execution role for this purpose, along with a custom access policy that grants least-privilege logging permissions. Here’s what the access policy looks like in the roles.yaml template:

Immediately following, in the same template, you can see the Lambda execution role that includes a reference to the above access policy in the list of ManagedPolicyArns on line 47:

Configuring Lambdas for CloudWatch

Once granted access through an execution role, no further configuration is needed to enable logging for your Lambdas. However, there are two additional properties that enable tracing and metrics. These can be applied to individual Lambdas, or to all the Lambdas in a SAM template by using the Globals section, as shown below in the admin.yaml template (we’ll cover these resources further, in the Lambdas section of the course):

In the code shown above, line 41 shows the import of a “layer” that’s published in AWS. Layers are a feature that makes it possible to share libraries for Lambdas. This is the mechanism that AWS uses to enable the "Lambda Insights" feature, which sends more detailed performance and resource usage metrics to CloudWatch. Finally, line 44 shows the Tracing property, which is how you enable X-Ray tracing for Lambdas.