DEV Community: Esther Awudu

Your First AWS WAF Setup

Esther Awudu — Wed, 17 Dec 2025 01:33:12 +0000

Your first successful project on the AWS Cloud, perhaps a cloud résumé or a static website, marks a significant milestone. Yet, deployment is only half the battle. To fortify this new public endpoint, integrating a Web Application Firewall (WAF) isn't just an option; it is the standard best practice for maintaining a defensible security posture from day one.

WAF is an AWS security tool that helps protect your endpoints from web attacks. Through Web ACLs(Access Control List)/Protection packs, you can define rules by which traffic will be filtered before accessing your resources.

In this article, I walk you through setting up your first web ACL in the AWS environment. Let's get started!

Step 1

In the AWS Management Console, in the search bar at the top, enter WAF, and under Services, click the WAF & Shield result:

AWS Shield is a subscription service from Amazon that protects your resources against denial of service (DOS) attacks. You will not use AWS Shield in this.

Step 2

In the left-hand menu, under AWS WAF, click Protection packs (web ACLs):

Step 3
On the right-hand side, click create Protection packs (web ACLs):

You will see a multi-step wizard load.

Step 4

In the App category section, select Other: You can select multiple categories at once. Choose what applies best to your endpoint.

Step 5

Click Add resources, followed by Add regional resources:

Step 6

In the list, select the resource to protect ( an Elastic Load balancer, CloudFront distribution, API gateway etc) and click Add:

Step 7

In Choose initial protections section, select Build your own pack from all of the protections AWS WAF offers:

Step 8

Under Add rules section, select AWS-managed rule group , and click Next :

Managed rule groups are pre-configured sets of rules available either directly from AWS or through AWS Marketplace security vendors. They are designed to provide immediate protection without requiring you to write individual rules.

You have three main options for WAF rules:

Custom Rules: You can create and define your own rule groups containing rules tailored specifically for your application.

AWS-Managed Rules: AWS provides certain rule groups, some of which can be used at no extra charge.

Marketplace Rules: Rules offered by third-party sellers on the AWS Marketplace generally require a separate subscription fee and associated charges, which are billed in addition to your standard AWS WAF request fees.

Step 9

You will see the list of AWS-provided rule groups. Find and select SQL Database:

The selection of this rule Group targeting SQL injection (SQLi) provides an immediate defense against one of the most common and damaging web attacks.

A SQL injection attack occurs when an attacker embeds malicious SQL code within a standard web request (like a form submission or URL parameter). If the targeted web application is poorly secured, it may execute this malicious code against its backend database.

Successful SQLi attacks grant the attacker unauthorized access to modify or delete data, and can potentially lead to full system compromise by enabling them to escalate privileges.

While modern, well-written applications employ safeguards (like parameterized queries) to prevent SQLi, information security experts strongly advocate for Defense in Depth. This strategy layers multiple security controls—like using a WAF in front of the application layer—to ensure that if one defense fails, the others remain active.

This specific type of Web ACL rule is invaluable when migrating legacy applications to the cloud. These older systems often have undocumented or vulnerable security models, making the WAF rule group an essential, compensating security control to protect the application while permanent code-level fixes are developed.

Step 10

To finish adding managed rule groups, scroll to the bottom and click Add rule, leaving all other settings at their defaults:

Step 11

To start adding your own rule, click Add rule > select Custom rule > click Next > select Custom rule once more > click Next:

The rule builder page will load.

Step 12

In the Action field, select Count: When creating custom rules in WAF Web ACLs, it's recommended to start with Count mode as a critical security best practice focused on mitigating risk and preventing service disruption. Count mode acts as a non-terminating testing phase that allows you to evaluate your rules without blocking any legitimate user traffic.

Step 13

In the Name field, enter the name of your rule:

Below the Rule name section, you will see If a request and a drop-down with matches the statement selected.

A rule can contain multiple statements. You can configure the rule to match when various conditions, including:

At least one statement matches
All statements match
The statement doesn't match the request This allows for complex and sophisticated rules. You will configure one statement in this rule.

Step 14

Fill out the following:

Inspect: select Body
Statement:
- Oversize handling: select Continue
- Match type: select Size greater than
- Size in bytes: type 512

You have configured the condition to match web requests where the body is greater than 512 bytes. Be aware that AWS WAF only checks the first 8192 bytes of requests that it processes.

At the end of the page, there are a few useful options you should be aware of:

Custom request: For Count actions, this allows you to add a header to a web request. When the action is Block, you can specify a custom HTTP response code, add headers, and define the response body.
Add label: Requests can be labelled by this rule, and then other rules can reference this rule by its label.

Leave both these options at their defaults.

Step 15

Click Add rule:

You will be returned to the Add rules page. Here you can also specify the order in which rules are evaluated when the Web ACL is processing a web request.

Notice 200 WCU and 1 WCU next to each rule. Web ACLs have a budget measured in Web ACL Capacity Units (WCUs), which limits the number of rules that can be used in a single Web ACL. The capacity is a measure of how much computing resource is required to apply the rules. Individual rules can have different WCUs depending upon how complex the rule is.
WCUs do not affect pricing.

Step 16

In the main Create protection pack (web ACL) page, scroll down to the Name and description section, and in the Name field, enter your preferred ACL name and description:

Step 17

Click Create protection pack (web ACL):

Note: It may take up to a minute for the Web ACL to be created.

When complete, the Web ACLs list page will load and you will see a success notification:

Step 18

Select the newly created web ACL, and then navigate to Manage resource:

Step 19

Make sure your resource is populated as shown below. If not, click on Add regional resources and add your resource:

Congratulations, you have successfully created a web ACL with two rules! One rule for detecting web requests containing SQL injection attacks, and another rule for detecting web requests with a large body size.

Set Up AWS Alerts to catch Cost Spikes and Security Risks

Esther Awudu — Thu, 18 Sep 2025 04:52:58 +0000

Surprise bills are no fun.
Running into them is almost inevitable, especially if you're just getting started. With AWS shifting to a credit-based free tier, it's important than ever to keep your experiments budget-friendly. In this article, I'll walk you through how to set up simple alerts using Amazon CloudWatch to monitor:

- Unexpected charges
- Root account logins
...and there's a challenge at the end for you to try. Let's get started!

Using CloudWatch to monitor Unexpected Charges

Step 1 : Enable Billing metrics

In the management console, navigate to "Billing Preferences" under "Billing and Cost Management" .
Under "Alert Preferences", check the option to "Receive CloudWatch billing alerts".
Click Update to confirm your changes.

Step 2: Create CloudWatch Alarm

In the console, navigate to CloudWatch and choose New Alarm.
Under "Specify metric and conditions", select the "Total Estimated Charge" metric under "Billings" .

Under Conditions is where you define the criteria that will trigger your alarm. In the example below, I set the threshold value to $10. As soon as the estimated charge on my account reaches or exceeds $10, the alarm will be triggered. Adjust this threshold to a value that suits your needs.
Next, we go to "Step 2: Configure actions". Here, we define what happens when the alarm is triggered. In our case, we want a notification delivered to us. For the alarm state trigger, we use the "In Alarm" option.
The notification is delivered via Email through Amazon SNS ( Simple Notification Service). If you do not have an SNS topic set up, you can create one within this step with an active email address. We leave everything else as the default.
Remember to verify your email as the recipient before messages can be sent!
The next step, "Add Alarm details," we give our Alarm a meaningful name. The alarm description is optional; however, it is good practice to set it up. It gives additional context to the alarm being received, especially where you have multiple alarms set up. The format of this body of text follows regular HTML rules.
Finally, Review all settings and create your alarm.

Once created, your alarm will appear in the CloudWatch dashboard, actively monitoring your AWS charges.

Using CloudWatch to monitor Root account usage

By default, AWS records the last 90 days of events within an account in the CloudTrail event history. However, the default events do not support triggering alerts, event metrics, and long-term storage. We thereby create a new trail and configure CloudWatch Alarms on it

Step 1 : Create CloudTrail Trail.

In the console, navigate to CloudTrail and select Create new trail.
Under Step 1: Choose trail attributes:
Create a name for your trail under Trail Name.
Under Storage Location, select Create new bucket. This will serve as the destination of your trail logs. A bucket name would be automatically generated.
Ensure the options for Log file SSE-KMS encryption and Log file validation are unchecked.
This is disabled to save costs, reduce complexity, and avoid potential integration or permission challenges, especially in a low-risk environment. But in production, it's best practice to enable both for security and audit integrity
Under CloudWatch Logs;
Enable CloudWatch Logs

Select New under Log group. A log group name would be automatically generated for you. Ensure you take note of this name.

Under IAM Role select new. An IAM policy would be generated that allows CloudTrail to send events to your CloudWatch group. Name this role and proceed to the next step, "Choose Log events".
In Step 2: Choose Log events, select Management events under Events.
Scrolling down to Management Events, ensure Read and Write is checked.
Review your changes and create the trail. Confirm your trail has been created in the CloudTrail dashboard.

Step 2: Set up Metric Filter for Cloudwatch log group

In CloudWatch, identify the log group you created in Step 1.
Select the log group, click Actions, and select the Create Metric Filter option.
Here in Step 1: Define Pattern, we enter the following metric filter

{ $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
#This filter will go through our CloudTrail log for root user login activity

Leave all other options as default and move to Step 2

In Step 2: Assign Metric, define a Filter name.

Under Metric Details, define;
A Metric Namespace (AccountSecurity)
*A Metric Name *(RootUserLoginCount)
*A Metric Value *(1)

Leave all other details as default and review your changes before making them. Your new metric filter will be immediately available!

Step 3: Create CloudWatch Alarm based on MetricFilter

Once your Metric Filter becomes available, select it in your dashboard and create an alarm based on it. This will also be available under Metrics.
Ensure the right metric has been selected and Statistic is set to sum. Leave other details under metric as default.
Under Conditions, set the following;
Threshold type **: Static
**Whenever metric (RootUserLoginCount) is : Greater/Equal
than.....: 1

Move to the next step.

In Step 2: Configure actions, set Alarm state trigger as In Alarm. Choose/Create an SNS Topic for the new alarm.

Add Alarm details
Review your changes and create your alarm.

Now, it's time to test! Log in to your root account to trigger the CloudWatch Alarm and notification.

Setting up CloudWatch Alerts is one of the best early steps you can take in securing your AWS account. It helps you stay in control of costs and spot suspicious activity before it escalates.

Challenge: Set up a CloudWatch metric filter and Alarm that checks for IAM Policy/Role changes. Comment on what filter you came up with, and let's engage!

Troubleshoot corner
I am not receiving a notification after logging into my root account. Try the following;

Ensure your email is a verified recipient of the SNS topic.
Publish a message to the SNS topic designated for the RootUserLogin Alarm.
Ensure you are using the custom Metric Filter you created.

If this still fails, create a second alarm with the custom Metric Filter.

References

Published my first article!

Esther Awudu — Sat, 31 May 2025 20:46:12 +0000

Esther Awudu

May 28 '25

Securing your AWS Account: A beginner's guide

#aws #cloudcomputing #beginners #cybersecurity

Comments 2

4 min read

Securing your AWS Account: A beginner's guide

Esther Awudu — Wed, 28 May 2025 13:08:51 +0000

Kudos for creating your account! However, your setup does not end there. Amazon Web Services runs on a shared responsibility model where you, the client, play a significant role in securing your account just as much as your cloud provider would. Without playing your role, you might end up leaving your environment open to determined snoopers. Fortunately, AWS provides a well-documented guide on security principles to abide by, and this article focuses on steps that are essential for beginners. Starting with securing the root account.

I. Implement a strong identity foundation.
Your root user account is what you are first logged into upon creating your AWS account. It comes with full access to all AWS services and resources. That's a lot of power - and risk, and with great power comes great responsibility. To ensure your account remains secure, you need to;

Avoid using the root account for daily tasks. Yeah I get it, might seem counterintuitive. What's the point of creating an account and NOT using it? You need to understand the amount of power your root account holds. A compromised root account can grant attackers full control of your AWS environment, leading to data breaches, loss of critical data, and more.
To avoid leaving your account vulnerable, create an IAM user with admin privileges for day-to-day management and use that instead.
Secondly, enable multi-factor authentication (MFA) on the root user. This adds an extra layer of protection in addition to a strong password.A virtual MFA application is a great strat to enable MFA on your account. I use Microsoft's Authy, but would recommend Google Authenticator.
Rotate your access keys. AWS recommends your access keys every 3 months (90 days) to minimize the risk of compromised keys and unauthorized access to your resources.

P.S. This is all free to set up!

II. Maintain traceability.

"By failing to prepare, you prepare to fail". This is a quote you need to especially live by in the cloud.
Preparing for the worst-case scenario better prepares and protects you from failure and long downtimes.
In recovery, you'll need access to your account's activity history to help diagnose your incident. This is where CloudTrail comes in. CloudTrail records all API activity in your AWS account - think of it like a security camera for your cloud. It is free to access on your account and is enabled by default.

When creating trails, it is recommended to enable the trail in all regions (even those you don't actively use).
In addition, make sure you store these logs in a secure S3 bucket with limited access.

You can capture a wide range of events within your account with Cloudtrail.

Additionally set up Cloudwatch alarms to trigger notifications ona wide range of activities that may happen within your account. As a beginner, it is best to set up anomaly detection on your account.
You can go a further step by integrating your logs with Amazon CloudWatch for real-time monitoring and alerts. More on this later in upcoming articles.

III. Review your resources frequently.
I've seen a lot of learners fall into the trap of deploying very cool projects only to leave them catching dust without maintenance and reviews. These are the kind of loopholes attackers take advantage of to exploit your resources. If only there was a way to review the configurations within your account to monitor for changes to your resources. Well, as in most cases, AWS has a tool for that. Enter, AWS Config.

AWS Config provides a detailed view of the resources associated with your AWS account, including how they are configured, how they are related to one another, and how the configurations and their relationships have changed over time.This is key in identifying posssible vulnerabilities and unauthorized changes.

In setting up Config, you have the option of a "1-click setup". With this option, AWS creates all necessary AWS resources for you, including AWS IAM service roles and S3 bucket for configuration records.It also configures AWS Config Recorder to continuously track the configuration for all resources – except for AWS IAM. However, you would still need to select rules. Rules are essentially compliance checks that are evaluated against by Config to manage your ideal configurations. The resulting compliance is displayed for you. AWS has a wide range of managed rules that check compliance for multitudes of resources.

Security isn't a one-time task - it's a continuous process. As you explore AWS, follow these practices to protect your account, your data, and your peace of mind. Strong security habits start now. The earlier you build them, the safer your cloud journey will be.