AWS WAF also allows you to get detailed logs for every request that comes through. Compared to the sampled web requests, which provide information about several requests, it includes every request that passes through the WAF and which rule or set of rules matches that particular request. With Full Logs enabled, you have all the details about what kind of request came in and what type of operations the WAF performed rather than just a simple set of metrics, and you can use these detailed logs for tasks such as security analytics, automation, auditing, and compliance.
The following is the feature set of Full Logs with WAF:
AWS WAF Full Logs provide comprehensive insights into the traffic that your web applications receive, enhancing your ability to monitor, analyze, and respond to potential security threats. These logs provide a detailed record of requests and responses, including HTTP headers, IP addresses, and query strings. By detailing incoming and outgoing traffic, these logs allow users to identify suspicious patterns, unusual behaviors, or potentially malicious activities. This helps you and your organization stay ahead of attackers by enabling proactive response measures and timely adjustments to your security rules.
Although sampled requests (which you can return with the GetSampledRequest query) do produce some information, it will only return a maximum of 500 log files from the first 5,000 requests your WAF has received. This can be insufficient for a firewall with a lot of active traffic constantly traveling across it. As a security professional, you most likely need to examine all the traffic to verify when an event has happened and not just a traffic sample.
Keeping in mind the preceding comparison between WAF Full Logs to WAF sampled requests, you can now look at the various services that send their logs to the CloudWatch service.
Most services send their logs to the CloudWatch Logs service. This section deals with the different services that generate logs and then send those logs to CloudWatch.
Note
Chapter 8, CloudWatch and CloudWatch Metrics, will discuss in detail how to utilize the capabilities of CloudWatch as a whole, including log retention, log querying, metrics, and events (including Amazon EventBridge).
Although you will not be made to memorize the list of services that can push their logs out to CloudWatch Logs for the exam, it is recommended that you have a robust understanding of which services do not have the ability to send logs to CloudWatch Logs without an intermediary step. Further, knowing the services that send their logs out to CloudWatch Logs (think Lambda functions) still helps you when it comes to reading and understanding the test questions.
One of the best ways to retain this information is not to study these lists but rather to perform hands-on exercises with the services. Table 7.1 shows a comparison of AWS services and how their logs can be delivered using Amazon S3, CloudWatch Logs, and Kinesis Data Firehose as the three primary sources for log ingestion:
| Log Type | Amazon S3 | CloudWatch Logs | Kinesis Data Firehose |
| Amazon API Gateway access logs | ü | ||
| Amazon Chime media quality metrics logs and SIP logs | ü | ||
| CloudFront access logs | ü | ||
| CloudWatch Evidently evaluation event logs | ü | ü | |
| Amazon ElastiCache for Redis logs | ü | ü | |
| AWS Global Accelerator flow logs | ü | ||
| Amazon MSK broker logs | ü | ü | ü |
| Amazon MSK Connect logs | ü | ü | ü |
| AWS Network Firewall logs | ü | ü | ü |
| Network Load Balancer access logs | ü | ü | |
| Amazon Route 53 resolver query logs | ü | ü | |
| Amazon SageMaker events | ü | ||
| EC2 Spot Instance data feeds | ü | ||
| AWS Step Functions Express workflow logs | ü | ||
| AWS Step Functions Standard workflow logs | ü | ||
| Storage gateway audit logs | ü | ||
| Storage gateway health logs | ü | ||
| Amazon VPC Flow Logs | ü | ü | |
| AWS WAF logs | ü | ü | ü |
Table 7.1: Log types and methods of storage
As you can see from the preceding table, most services allow you to send logs to the CloudWatch service. Some of the services allow more than one location to send their log files. Finally, a select number of services, such as CloudFront access logs, only allow their logs to be delivered to an S3 bucket.
In addition to the pros and cons of storing logs in S3 versus CloudWatch Logs earlier in the chapter, you also need to grasp how to use native tools to sift through the mountain of log files to find the information you are seeking quickly. That said, if you are going to use any of the three aforementioned options, logging to an S3 bucket, using CloudWatch Logs, or having logs streamed via Kinesis Data Firehose, the correct IAM permissions need to be in place so that the corresponding service can place the logs in the desired storage. The following section discusses those permissions.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
