Passing the AWS Security Specialist Cert Part 2: Logging & Monitoring

This is part two of our series on the AWS Security Specialist SCS-C02 certification! In part one, we looked at a broad overview of the cert and the two foundational AWS services covered in two of the six test domains: IAM and KMS.

We’ll continue the series today with the next domain: Logging and Monitoring. This is a critical domain. With no logging and monitoring, you have no idea what is happening in your environment. You don’t know when things are working as they should and when there are problems. You don’t know if someone is actively trying to hack your applications, or worse, has already gained access. 

Developers need application logs, and historical metrics to troubleshoot problems and improve performance. Security teams need access logs, AWS resource calls, and network logs to investigate incidents. Infrastructure engineers need to keep a tidy house in their AWS accounts and audit items like rotating access keys and properly locked down security groups. All this data must be available both in real-time and archived away for reviewing history and possible compliance reviews.

What good are logs, though, without alerts? No one has the bandwidth to crawl through lines and lines of logs looking for problems. We need alerts to catch anomalies, metrics hitting thresholds of poor performance, and security configurations out of compliance.

This is a tall order to keep your AWS accounts on lock and under close surveillance. Luckily, AWS provides some core services to help you out, namely: CloudTrail, CloudWatch, AWS Config, and Trusted Advisor.  

Related: Passing the AWS Security Specialist Exam Part 3: Incident Response and Infrastructure Security.

Ready to Learn AWS Skills in 2025?

AWS is the undisputed leader in the cloud computing market. If you’ve been thinking about earning a certification or upskilling this year, learning AWS is as safe a bet as any. Find the online AWS training you need at CBT Nuggets. 

No matter if you are brand new to the cloud or a seasoned networking pro, our courses can get you up to speed on the latest AWS technologies and best practices. Our AWS cloud training maps to highly valued certifications—and covers skills that many organizations desperately need. 

Not a CBT Nuggets subscriber? Sign up for a 7-day free trial to get a feel of what it’s like to learn IT with us. Explore our AWS training and start learning skills that can help you level up your career today!

CloudTrail

CloudTrail, in AWS’s words, “monitors and records account activity across your AWS infrastructure, giving you control over storage, analysis, and remediation actions.” In more specific terms, it logs every single API call that happens on your account. They can be from actions taken from the AWS console, from the AWS CLI, or from an SDK. CloudTrail logs any and all API calls.

These API calls can be any request made to an AWS resource, requests like uploading a file to a bucket, creating a new EC2 instance, updating a Lambda function, or even listing the available CloudTrail trails (trails are how CloudTrail logically groups its logs). 

Take note of what CloudTrail isn’t. It is not application logs, resource usage, or the like. It’s more about auditing calls to AWS resources.

So, what’s in a typical CloudTrail log? Take a look at an example (details have been drastically truncated, see this page for the full log.)

...
        "userIdentity": {
            "type": "IAMUser",
            "principalId": "111122223333",
            "arn": "arn:aws:iam::111122223333:user/myUserName",
            "accountId": "111122223333",
            "accessKeyId": "AKIAIOSFODNN7EXAMPLE",
            "userName": "myUserName"
        },
        "eventTime": "2019-02-01T03:18:19Z",
        "eventSource": "s3.amazonaws.com",
        "eventName": "ListBuckets",
        "awsRegion": "us-west-2",
        "sourceIPAddress": "1.2.3.4",
        ...
    },
}

There’s a lot here, but skimming through, we see the event source (S3), the action taken (listing all the buckets in the account), the user’s name, ARN, access key, the region, and source IP address of the request. This request could have come from the AWS CLI by running a command like aws s3 ls. It also might have come from a user in the AWS console; when the page is loaded, which shows all your buckets, under the hood the console makes an API call to S3, which CloudWatch also logs.

One default best practice you must always remember (both for real life and the exam) is to protect your CloudTrail logs at all costs! CloudTrail sends all its logs to an S3 bucket that you sent up when enabling it. The policies on this bucket must be strict: no read access for anyone except admins and auditors. 

To further protect the logs, digest files were created in the same bucket. These digests contain hashes for the log files that can be used to verify that they haven’t been tampered with.

There is a lot more that can be said about CloudTrail, but for now, we must move on in our monitoring adventures to CloudWatch. 

Related: Passing the AWS Security Speciality Cert Part 1: Identity and Access Management & Data Protection

CloudWatch

Per AWS, CloudWatch “collects and visualizes real-time logs, metrics, and event data in automated dashboards to streamline your infrastructure and application maintenance.” Phew. Basically, it’s what we determined CloudWatch is not: application logs, performance metrics, resource events, and the like. It's broken up into three components: CloudWatch itself, CloudWatch Logs, and EventBridge.

CloudWatch proper is where all your metrics are aggregated. You can build dashboards showing specific metrics on certain resources (like the CPU usages on your EC2 instances), then create alarms based on those metrics (like when an EC2 instance stays over a certain CPU percentage for too long). Those alarms can be sent to a notification service like SNS to text or email you.

CloudWatch Logs is like it sounds on the tin, the logs from your applications, operating systems, and certain AWS services. The classic example is EC2. You must install the CloudWatch agent on your instance and configure it to gather logs. The agent then ships the logs over to the CloudWatch API. Then, you'll be able to view, filter, and search those logs.

Then, we finally have EventBridge (formally CloudWatch Events). This is a system with rules that, when triggered, take action against a target. The events themselves that trigger the rules can be one of many types, like a resource state change (like an EC2 instance being created or stopped), specific types of API calls from CloudTrail, custom events from CloudWatch logs (like HTTP status codes from Apache logs), or scheduled events (like cron jobs).

AWS Config

A lesser-used but still important service, AWS Config “continually assesses, audits, and evaluates the configurations and relationships of your resources.” Basically, how are things configured now, when they change, who did it, and when?

Imagine you have an EC2 instance with a security group. Best practice says that port 22, the SSH port, should never be opened up to the public internet, so that’s how you have your security group configured. Then, one day you notice the group has changed, and 22 is open to the entire internet! Perhaps a rogue developer wanted SSH access directly from home. But who was it?

AWS Config to the rescue! After hunting down the security group in question, you can look at a timeline of every change, including who did it and when. But AWS Config has more tricks up its sleeve. Triggered rules can also initiate action, like a Lambda script that edits the security group to close the port and keep the security group in compliance.

Many of the common rules that you can implement (like monitoring for open SSH) are already built in as AWS Managed Rules; all you need to do is enable them on your instances. Of course, you can write your own custom rules, both for alerting and compliance, to remediate issues via Lambda.

Trusted Advisor

One final essential service to know for the security certification is Trusted Advisor. This is a set of compliance best practice checks that run against your entire account, advising you of any potential problems that need attention and their remediation.

Other helpful categories of checks include cost optimization, performance, fault tolerance, and service limits. The AWS docs list all the available checks for each category.

Trusted Advisor should definitely be your trusted ally in keeping your account properly configured based on AWS’s own recommendations. It can also send data into CloudWatch, from which you can create alarms and notifications—which is way handier than trying to keep an eye on it manually.

Keep Learning: Incident Response and Infrastructure Security 

With that, we have finished our overview of the AWS Security Specialist cert's monitoring and logging domain! Next time, we’ll visit two more domains: Incident Response and Infrastructure Security!

Ready to start training for the AWS Certified Security – Specialty (SCS-C02)? Sign up for a free 7-day trial with CBT Nuggets.