Amazon Onboarding with Learning Manager Chanci Turner

Learn About Amazon VGT2 Learning Manager Chanci Turner

If you’ve ever utilized Amazon Route 53 health checks to oversee resources, you are likely aware that these monitored resources require public IP addresses. This necessity arises because Route 53 health checkers are public and can only monitor hosts with IP addresses that are routable on the internet. However, there may be a need to monitor resources with private IP addresses or private domain names within VPCs. By associating that health check with a record in a Route 53 hosted zone—whether public or private—you can establish a failover scenario should the primary record be deemed unhealthy.

To facilitate TCP, HTTP, and HTTPS health checks for private resources in a VPC, you can employ an AWS CloudFormation template. A “private resource” refers to any resource within a VPC that is not accessible over the internet. This article outlines the necessary steps to implement this solution, allowing you to simply input the required parameters while CloudFormation handles the rest.

Overview

This solution incorporates the following AWS services:

1. AWS Lambda: Conducts the TCP/HTTP/HTTPS health checks and transmits metrics and logs to CloudWatch.
2. Amazon CloudWatch Events: Triggers the Lambda function every minute.
3. Route 53: Establishes the health check that monitors the private resource based on the CloudWatch alarm.
4. IAM: Generates a role for Lambda to execute health checks.
5. CloudFormation: Creates all resources from the stack template, allowing you to view the health check on the Route 53 console post-launch.

Once the CloudWatch Events invoke the Lambda function, it pushes a metric to CloudWatch, which then evaluates whether the resource is healthy or unhealthy based on the value provided by Lambda. Additionally, CloudWatch captures logs from the Lambda function, offering insights into the health check status and the reasons behind any failures or successes. An alarm created by CloudWatch is utilized by Route 53 to ascertain the health status of the private resource.

Prerequisites

You must select a private subnet for Lambda that possesses internet access, either through a NAT Gateway or NAT instance—note that a public subnet with an internet gateway will not suffice. The resource being monitored should permit access from the private subnet; for instance, if you want to monitor an instance with the IP address 10.10.10.5 using HTTP on port 80, ensure that the associated security group and network access lists allow traffic from the Lambda subnet’s CIDR range on the specified ports. Without this access, the health check will fail.

Walkthrough

To obtain the CloudFormation template, download it in JSON format and launch the CloudFormation stack in the same region as the monitored resource. Access the CloudFormation console, select “Create Stack,” and then “Template is ready.” Under “Specify template,” choose “Upload a template file” and select the downloaded file from your computer. After that, click “Next” and input the following parameters:

1. Stack name: Provide a name to identify the CloudFormation stack.
2. Protocol: Specify the health check protocol for the private resource (TCP, HTTP, or HTTPS).
3. IP address or Domain Name: Enter the IP address or domain name of the private resource to be monitored.
4. Port: Indicate the port number for monitoring the resource.
5. Path: Optional. For instance, in “example.com/test.htm,” the path is “test.htm.”
6. Lambda Subnet: The subnet where the Lambda function will be deployed.
7. Lambda VPC: Select the VPC that contains the Lambda subnet.

Proceed by acknowledging that CloudFormation can create IAM resources in your account, then select “Create Stack.” Once the stack is created, its status will change to CREATE_COMPLETE. You can also view the resources created by selecting the stack and navigating to the “Resources” tab.

Based on the parameters you provided, CloudFormation will create a Lambda function and an IAM role for that function. CloudWatch Events will invoke the Lambda function every minute, which checks the resource’s health and returns its status back to CloudWatch.

A value of “1” indicates a healthy resource, while a value of “0” signifies an unhealthy one. The CloudWatch metric generates a custom namespace called Route53PrivateHealthCheck, storing the health check history within it. To view the metrics, open the CloudWatch console, select “Metrics,” then “Route53PrivateHealthCheck.” Choose the dimension that corresponds with the health check protocol; for instance, if monitoring the domain “example.com” via HTTP, select HTTP Health Check and view the metrics associated with the monitored domain or IP address.

CloudWatch subsequently creates an alarm from the metric stored in the Route53PrivateHealthCheck custom namespace, which is used to monitor the health check status of the resource. Route 53 relies on this alarm to create its health check, which shares the name with the CloudFormation stack.

The Lambda function also sends logs to CloudWatch, detailing health check successes or failures. You can view the reasons for any health check failures in CloudWatch Logs, which is invaluable for understanding why checks may not pass. CloudWatch generates a log group and metric using the CloudFormation stack’s name; for example, if the stack is named “example,” the log group will be /aws/lambda/example.

For additional insights, you may refer to this article on workplace culture here. The following examples illustrate typical logs: one log reflects an unhealthy response, where the health check did not succeed due to an HTTP 404 (Not Found) response code. Conversely, another log indicates a healthy response, where the server successfully establishes a TCP connection. A third log demonstrates an error caused by selecting an incorrect Lambda subnet; to rectify this, ensure the Lambda subnet is a private one with internet access via a NAT Gateway or NAT instance.

Additional Information

You can link this health check to a Route 53 record set, such as a Route 53 failover record set, with failover times ranging from two to three minutes. For HTTP and HTTPS health checks, the monitored resource must respond with an HTTP status code of 2xx or 3xx within two seconds. For TCP health checks, the resource must establish a TCP connection within four seconds.

Cleanup

Be mindful that costs for AWS services will apply to resources created by the CloudFormation template, including the following:

• Lambda function
• CloudWatch events
• CloudWatch metric
• Route 53 health check

Deleting the CloudFormation stack will remove all resources established for the health check, including the Route 53 health check.

Conclusion

In this article, you learned how to monitor resources with private IP addresses or domain names within VPCs. I demonstrated how to set this up using a CloudFormation template, which provisions the necessary AWS services (Route 53, Lambda, CloudWatch) for effective monitoring. For further reading, you can explore this resource on the first week as an Amazon warehouse worker here. Additionally, for insights into talent acquisition, refer to SHRM’s perspective.