Using CloudWatch to Monitor VPN Connections

VPNs are essential for modern internet security, and most organizations use them as part of their IT infrastructure. Cloud IT systems are no different, however in a cloud environment there are some interesting opportunities for automating the monitoring and maintenance of IT resources. A great example in AWS is that you can set up CloudWatch alarms to track the status of your resources and take automatic action in case of a failure event. Once you have a functional alarm, you can do things like send notification emails, repair resources, and run serverless code using AWS Lambda. By leveraging the power of serverless functions, the alarm responses you can design are only limited by your creativity.

CloudWatch Logs Retention Periods

If you’re not familiar with CloudWatch Logs its a feature of the CloudWatch service which allows us to persist logs from applications and operating systems on the AWS platform.

Once you’ve installed - and configured - the Unified CloudWatch Log agent, you’re able to gather logs from both EC2 and Server instances (on-premise).

By default, CloudWatch Logs stores log data indefinitely. This is fantastic, but we need to remember that we pay for log storage. While the costs are not high, this is one of those services that can quietly sneak up on you and end up costing a fair amount every month.

Using CloudWatch Log Insights and AWS Athena to troubleshoot Network issues

Enabling logs and configuring them is an important step in securing your AWS environment, however you have to also be using them effectively! Just monitoring your environment isn’t enough, you should also be proactive with the data you’re collecting. Today I’ll focus on VPC Flow Logs, where and how they’re stored, and how to use that data to troubleshoot common network issues.

Finding your Logs

First off, determine if VPC Flow Logs are enabled. There are two possible ways to deliver flow logs data; to CloudWatch Logs or to an S3 bucket. If Flow Logs already exist you’ll be able to see the destination.

Monitoring a Web Server on AWS

Web servers break. Thankfully, we have tools like Autoscaling for EC2 and Elastic Load Balancers to minimize the impact of server downtime, but it remains a fact of IT life that servers can fail for any number of reasons. To get ahead of a failure event, it’s good practice to have some monitoring set up on your machines. In this article, we’ll go through some basic monitoring you can deploy on an Apache EC2 instance and integrate with Cloudwatch Metrics.

Monitoring AWS Health Events

Monitoring AWS Health Events

Every so often, infrastructure in an AWS availability zone (or region) breaks down or a bug is discovered with a service. When this happens, AWS sends a notification to affected accounts and an email to the account owner. That’s pretty useful if you are the sole owner of an account, but what if you need those emails to reach multiple users? You could always forward them, but that requires action on your part. Instead, let’s take you out of the equation by setting up a system that will automatically forward those health notifications to a group of users.

Monitoring Workspaces With Amazon EventBridge

Because of COVID-19, many of our customers have implemented work from home solutions for their employees. While many options are available, Amazon Workspaces offers a cost-effective, easy to use remote desktop solution.

Last week, we helped one of our AWS Managed Services customers deploy approximately four hundred Windows Workspaces across several AWS accounts.

One of their requirements is to report on daily usage. While Amazon CloudWatch provided us with much of the information we required to meet the customer’s needs, we did build a custom solution for reporting.

Monitoring Burstable T2 EC2 Instances

Recently, I was working with a client who was leveraging Burstable T2 EC2 instances for their web infrastructure - something which I regularly recommend to my clients. In this situation though we were receiving reports from the application team about odd behaviour. On what seemed like a random schedule the websites would stop responding to requests entirely or complete the requests at a reduced rate.

We immediately started to comb through our logs in an attempt to determine the cause and implement a fix. Based on CloudWatch metrics which we were already capturing it appeared as though we had a memory leak in one of the applications running on the Apache Server.