More Haste, Less Speed

Now you can click the Test button to see if you can connect to the Internet over TCP port 443. Success is denoted this time if the output in the green bar at the top of the page shows:

{
  "TimeTaken": 187,
  "Available": "1"
}

To make sure it's working, alter your test event to a funny port number on which your destination definitely isn't listening (e.g., TCP port 4444) and see what happens. If you get a 0 for Available , you know the test is working as hoped.

Incidentally, you can ignore the CloudWatch errors if you notice them. In Listing 3 you can see the CloudWatch IAM policy auto-generated when you create the Lambda function. By default, it's trimmed down and will cause a relatively trivial CloudWatch metrics error, because it doesn't have a cloudwatch:PutMetricData permission, which the script would need.

01 {
02   "Version": "2012-10-17",
03   "Statement": [
04     {
05       "Effect": "Allow",
06       "Action": "logs:CreateLogGroup",
07       "Resource": "arn:aws:logs:eu-west-1:XXXXXXX:*"
08     },
09     {
10       "Effect": "Allow",
11       "Action": [
12         "logs:CreateLogStream",
13         "logs:PutLogEvents"
14       ],
15       "Resource": [
16         "arn:aws:logs:eu-west-1:XXXXXX:log-group:/aws/lambda/internet-access-function:*"
17       ]
18     }
19   ]
20 }

Completely Hopeless

Now that your monitoring Lambda function is working, you can schedule it to run periodically to monitor a website by using CloudWatch in AWS.

In the CloudWatch section in the AWS Management Console, start with Events | Rules and choose the Schedule radio button (Figure 4). In the Targets section you want to select Lambda function in the drop-down and then select the name of your function (i.e., internet-access-function ).

Figure 4: Setting up a schedule for a Lambda function in CloudWatch.

Next, click the blue Configure details button, add a name for the rule, and then click the blue Create rule button. Make sure the name doesn't contain spaces. To continue, click on Logs on the left-hand side; then, choose your Lambda function name, which in turn will reveal the log for each execution.

The top log entry offers some bad news (Figure 5). As you can see, the Lambda function's script defaults to Google in Australia (where the authors of the script reside), so you need to add your test event parameters into the CloudWatch rule. If the PutMetrics error is jumping out at you, then you can either adjust your IAM permissions, remove it from the Lambda function's script, or, of course, just ignore it.

Figure 5: To monitor the desired website, you need to adjust the input parameters of your CloudWatch rule.

Fear not, however. If you go back into the configuration, you can adjust the run-time parameters of the CloudWatch rule with relative ease. To do so, select your Lambda function and copy the PortCheck test event you created as JSON earlier and simply add this to your rule.

Where do you paste it, you may well ask? Look inside your CloudWatch rule config and tick Constant (JSON text) under the Configure input drop-down options and then paste in the content used previously:

{
"HOSTNAME":"www.devsecops.cc",
"PORT":"443",
"TIMEOUT":5
}

Having saved that change, you can now see in your CloudWatch log (Figure 6) that the Lambda function is indeed checking the correct website and logging its output for future reference.

Figure 6: Happiness is probing the correct website address.

Now that you can see the intended website, you can alter your rule's schedule to monitor its uptime every minute or every day – or, in fact, whatever time period you desire. You can even use a cron format, if you prefer.

If you want to go a step further, you can also create metrics for your CloudWatch rule and create a Simple Notification Service (SNS) topic so that email alarms are triggered when the website is unavailable. That part of the jigsaw puzzle is relatively easy to pick up if you haven't done it before. Remember to disable the CloudWatch rule once you've finished testing to avoid the potential of an email storm.

Now that you have a shiny new working Lambda function that can be scheduled to run whenever you like, I'll spend a moment looking at what a more complex workflow might look like if you were running your Lambda function inside a VPC.

Don't Be Careless

At the beginning of this article, I mentioned that Internet access is trickier if you have a more mature infrastructure and host your Lambda functions inside a VPC so that they can access nonpublic resources securely, as well as the Internet. Table 1 shows the workflow involved.

A minor caveat is that if you're testing against existing networking that is already running important services, it's possible to tie yourself in knots and break things horribly.

To get started, try to create, where possible, these new resources inside a new VPC for testing purposes. Some of the resources should definitely be deleted afterward – especially the Elastic Network Interface (ENI) – to save ongoing costs for Elastic IP addresses. Consider yourself suitably warned!

If you are familiar with the innards of AWS and have looked through Table 1, I could be forgiven for summarizing it in one sentence: "To access resources inside a VPC, use a private subnet and a NAT gateway and then connect that to a public subnet, which by inference has an Internet gateway attached for external Internet access."

I've had success with the above approach, so bear this workflow in mind for future reference if you foresee a need.