DEV Community: Geovane Oliveira

Protecting an EC2 hosted web application with AWS WAF in practice

Geovane Oliveira — Thu, 08 Jan 2026 00:29:40 +0000

Web applications on EC2 are everywhere. And honestly, a lot of them are just sitting there exposed to the internet with nothing more than a Security Group between them and every bot, scanner, and attacker out there.

This article walks through building a straightforward architecture to answer one specific question: How do you protect a web application on EC2 from common web attacks without touching the application code?

We'll use AWS WAF for Layer 7 protection, Security Groups for network control, and AWS Certificate Manager for encrypted transport, all at minimal cost and complexity.

Understanding network layers before adding security controls

Before jumping into AWS services, let's get clear on how network communication actually works. The OSI model helps here, but we'll keep it practical.

Layer 3 – Network layer

Deals with IP addresses. This is about knowing where traffic is coming from and where it's headed.

Layer 4 – Transport layer

Deals with ports and protocols. This controls how connections get established, think TCP on port 80 or 443.

Together, these two layers answer questions like: Who's sending this traffic? Which port are they using? Should this connection even be allowed?

Layer 7 – Application layer

This is where HTTP and HTTPS live. It understands URLs, headers, query strings, request bodies and the actual content of what's being sent.

Layer 7 answers a different kind of question: What is the user actually trying to do?

Here's the thing: most web attacks happen at Layer 7, not at the network level. Understanding this distinction is critical.

What a Security Group is and how it works

Security Groups are probably the first security control you run into in AWS. They're virtual firewalls that control network level access to things like EC2 instances and load balancers.

A Security Group evaluates traffic based on:

Source IP address
Destination port
Protocol

From the OSI perspective, Security Groups operate at Layer 3 (Network) and Layer 4 (Transport).

Key characteristics:

Stateful – if traffic is allowed in, the response is automatically allowed out
Allow only – you can't write deny rules, only allow rules
Everything else is denied by default

Example rules:

Allow inbound TCP traffic on port 80 from anywhere (0.0.0.0/0)
Allow SSH on port 22 only from your office IP
Deny everything else (implicit)

Security Groups are essential. They're your first line of defense.

What Security Groups cannot protect against

But here's the limitation: Security Groups don't understand HTTP or HTTPS content at all.

They can't:

Inspect URLs
Analyze query strings
Detect SQL injection attempts
Catch Cross Site Scripting (XSS)
Identify malicious payloads in request bodies

From a Security Group's perspective, if port 80 is open and the source IP is allowed, the request gets through no matter what's actually inside that request.

This is a fundamental limitation when you're trying to protect web applications.

Why application layer protection is required

Web attacks are application layer problems. That means you need Layer 7 inspection.

This is where AWS WAF comes in.

AWS WAF is a fully managed Web Application Firewall that inspects HTTP and HTTPS requests before they ever reach your application. It looks at:

URL paths
Headers
Query strings
Request bodies

Based on rules you define (or use AWS Managed Rules), it can:

Allow requests
Block requests
Count requests for monitoring

The best part? No agents on your EC2 instances. No changes to your application code.

Why an Application Load Balancer is part of the design:

AWS WAF can't attach directly to an EC2 instance. It needs to be associated with one of these:

Application Load Balancer
API Gateway
CloudFront

For this architecture, the Application Load Balancer serves as:

The public entry point
The integration point for AWS WAF
The boundary between the internet and your compute layer

Even if you are only running a single EC2 instance, this design mirrors what you would see in production environments.

Architecture overview

The architecture below shows the scenario we are going to discuss in this article.

Figure 1: Conceptual architecture for protecting an EC2-hosted web application using AWS WAF attached to an internet-facing Application Load Balancer

The flow works like this:

Internet traffic hits the Application Load Balancer
AWS WAF inspects HTTP requests at Layer 7
Allowed requests get forwarded to the EC2 instance
Security Groups restrict network level access between components

Architecture components:

Amazon EC2 – Runs a simple Nginx web application in a public subnet

Application Load Balancer – Exposes the application to the internet and routes traffic to EC2

AWS WAF – Inspects and filters HTTP requests before they reach the application

AWS Certificate Manager – Provides free SSL/TLS certificates for HTTPS encryption

Systems Manager Session Manager – Provides secure, SSH free access to EC2 instances via IAM

Auto Scaling Group – Maintains a single EC2 instance (and makes it easy to scale later if needed)

Security Groups – Enforce strict Layer 3 and Layer 4 access rules

Each component protects a specific layer. There's no redundancy or overlap.

Setting up the infrastructure

Let's walk through the key configuration steps. I'll focus on the security specific settings that matter most.

Step 1: Creating the Application Load Balancer

First, we need to set up the ALB that will serve as our public entry point.

Figure 2: Application Load Balancer basic configuration

Key settings to configure:

Scheme: Internet facing
IP address type: IPv4
Listeners: HTTP (port 80) and HTTPS (port 443)
Availability Zones: Select at least two for high availability

The ALB needs to be in a public subnet since it's receiving traffic directly from the internet.

Step 2: Configuring Security Groups

Security Groups control network level access. We need two distinct groups here.

ALB Security Group:

Figure 3: Security Group rules for the Application Load Balancer

Inbound rules:

Allow HTTP (port 80) from 0.0.0.0/0
Allow HTTPS (port 443) from 0.0.0.0/0

EC2 Security Group:

Figure 4: Security Group rules for the EC2 instance

Inbound rules:

Allow HTTP (port 80) only from the ALB Security Group

Note: Unlike traditional setups, we're not opening SSH port 22. Access to the instance for management purposes is handled through AWS Systems Manager Session Manager, which uses IAM authentication and doesn't require any inbound ports to be open.

This is crucial: the EC2 instance never accepts traffic directly from the internet. Only the ALB can reach it on port 80, and administrative access is through SSM Session Manager only.

Step 3: Creating the AWS WAF Web ACL

Now we add the Layer 7 protection. This is where AWS WAF comes in.

Figure 5: Creating a Web ACL in AWS WAF

When creating the Web ACL:

Give it a descriptive name (e.g., ec2-app-protection-waf)
Select Application Load Balancer as the resource type
Associate it with the ALB you created earlier

Step 4: Adding AWS Managed Rules

Instead of writing custom rules from scratch, we'll use AWS Managed Rule Groups. These are maintained by AWS and updated automatically.

Recommended rule groups to enable:

Core rule set (CRS) – Protects against common attacks like OWASP Top 10
Known bad inputs – Blocks requests with patterns associated with exploit attempts
SQL database – Prevents SQL injection attacks
Linux operating system – Blocks requests targeting common Linux vulnerabilities

Each rule group adds a layer of protection. Start with these four since they cover the most common attack vectors.

Step 5: Associating WAF with the ALB

Once the Web ACL is configured, associate it with your Application Load Balancer.

The association happens in one of two ways, depending on where you started the configuration. If you created the Web ACL from the WAF console, you selected the ALB during the initial setup under (Associated AWS resources). If you're adding WAF to an existing ALB, you will find the option in the Load Balancer console under the (Integrated services) tab.

From the Load Balancer perspective, you will see a section labeled (AWS WAF) where you can attach a Web ACL. Click "Edit" and select your newly created Web ACL from the dropdown. The attachment is immediate there is no downtime, no need to restart anything.

Once associated, you will see the Web ACL name displaied in the ALB's integrated services section. You can verify the reverse connection by going back to the WAF console, selecting your Web ACL, and checking the (Associated AWS resources) tab. Your ALB should be listed there.

This is the critical connection point. Every HTTP request hitting your ALB will now pass through AWS WAF inspection before reaching your EC2 instance. The WAF evaluates each request against your rule groups in order of priority, and either allows it through, blocks it with a 403 response, or counts it for monitoring purposes depending on how you've configured each rule.

The inspection happens inline with minimal latency, typically adding only single digit milliseconds to request processing time. If WAF blocks a request, the connection never reaches your application layer. The request is terminated at the ALB with a 403 Forbidden response.

Step 6: Configuring IAM Role for Systems Manager

To enable secure, SSH free access to the EC2 instance, we attach an IAM role that allows Systems Manager Session Manager to function.

Figure 7: IAM role configuration for Systems Manager access

The IAM role includes the AmazonSSMManagedInstanceCore managed policy, which provides:

Permission for the SSM agent to communicate with Systems Manager service
Ability to retrieve commands and send outputs
CloudWatch Logs integration for session logging (optional but recommended)

Note on SSM Agent: If you are using Amazon Linux 2023 (as in this setup), the SSM agent comes pre installed and enabled by default. For other AMIs like Ubuntu or older Amazon Linux versions, you may need to install the agent manually. The combination of the IAM role and the pre installed agent is what enables Session Manager to work immediately after instance launch.

Once attached, you can access the instance through the AWS console or CLI without opening SSH ports or managing key pairs. All sessions are authenticated through IAM and can be logged for audit purposes.

Step 7: Monitoring and testing

After everything is configured, you can monitor WAF activity through CloudWatch metrics.

AWS WAF provides real time metrics that show how your Web ACL is performing. These metrics are automatically published to CloudWatch and typically appear within 5 to 10 minutes of activity.

Key metrics to watch:

AllowedRequests: Legitimate traffic getting through
BlockedRequests: Malicious requests stopped by WAF
CountedRequests: Requests matching rules in count mode

To view these metrics:

Navigate to the AWS WAF console
Select your Web ACL
Go to the Overview tab
CloudWatch metrics will display showing request patterns over time

You can also view detailed logs in CloudWatch Logs if you enable WAF logging.

Transport security with HTTPS

All traffic between clients and the Application Load Balancer is encrypted using TLS 1.2 or higher. The SSL certificate is provided by AWS Certificate Manager at no cost and renews automaticaly.

Figure 10: SSL/TLS certificate from AWS Certificate Manager

The ALB is configured to:

Accept HTTPS connections on port 443 with a valid SSL certificate
Redirect all HTTP traffic to HTTPS (301 permanent redirect)
Use modern cipher suites (TLS 1.2+ only)
Serve a certificate trusted by all major browsers

This ensures that sensitive data cannot be intercepted or read by attackers performing man-in-the-middle attacks. The certificate is issued and managed by AWS Certificate Manager, which handles automatic renewal before expiration.

Video walkthrough: For a complete hands on demonstration of this setup, check out the video tutorial below where I walk through each step in the AWS console.

[Vídeo soon]

What AWS WAF protects against in practice

Using AWS Managed Rules, AWS WAF can block common attack patterns like:

SQL injection attempts
Cross-Site Scripting (XSS)
Path traversal attacks
Malformed or suspicious HTTP requests
Basic automated scanners and bots

Important point: AWS WAF doesn't fix insecure code. What it does is reduce your exposure by blocking known malicious patterns before they ever reach your application.

What this architecture does NOT cover (and why it matters)

This architecture provides solid foundational protection with network segmentation, application layer filtering, encrypted transport, and IAM based instance access. However, it's important to understand its limitations. This is a strong starting point that demonstrates core security principles, not a complete enterprise grade solution.

What's missing for a production environment:

Network Isolation:

EC2 in public subnet (production should use private subnet, see "Ideal Architecture" below)
EC2 has public IP (though no direct access is possible due to Security Groups)
No VPC Endpoints for fully isolated SSM access
No NAT Gateway for controlled outbound traffic from private instances

Advanced DDoS Protection:

No AWS Shield Advanced for sophisticated volumetric attacks
No rate based rules in WAF to limit request velocity per IP
No geographic restrictions (geo blocking) for region specific threats

Monitoring and Threat Detection:

WAF logging disabled (to minimize costs for this demo)
No AWS GuardDuty for threat intelligence and anomaly detection
No Security Hub for centralized security findings across services
No VPC Flow Logs for network traffic analysis
No CloudWatch Alarms for proactive alerting on suspicious activity

Identity and Secrets Management:

No AWS Secrets Manager for database credentials or API keys
Session Manager logging not enabled (optional enhancement)
No MFA requirement for Session Manager access

Compliance and Governance:

No AWS Config for continuous compliance checking
No automated patch management with Systems Manager Patch Manager
No backup strategy with AWS Backup
No vulnerability scanning with AWS Inspector

Advanced Application Protection:

No AWS WAF Bot Control for sophisticated bot mitigation
No reCAPTCHA challenges for suspicious activity
No account takeover prevention features
No fraud detection patterns

Content Delivery:

No CloudFront for global edge caching and additional DDoS protection
No origin shielding to reduce load on the ALB

Recommendation: For production, place CloudFront in front of the ALB to:

Hide the ALB's DNS name from public access
Add an additional WAF layer at the edge
Improve global performance with caching
Protect against DDoS attacks with AWS Shield

Ideal architecture for production:

For production workloads, the recommended architecture would place the EC2 instance in a private subnet with no public IP address and use VPC Interface Endpoints for Systems Manager connectivity. Here's what that would look like:

Enhanced Network Architecture:

Key differences:

EC2 in private subnet - No public IP, no direct internet access
VPC Interface Endpoints - Enable SSM access without internet gateway (~$21.60/month for 3 endpoints)
NAT Gateway - If EC2 needs outbound internet access (~$32.40/month + data transfer)
CloudFront - Global distribution and edge protection

Why not include this in the current architecture?

VPC Interface Endpoints cost approximately $0.01/hour per endpoint (~$7.20/month each). For Systems Manager to work in a private subnet, you need 3 endpoints:

com.amazonaws.region.ssm
com.amazonaws.region.ec2messages
com.amazonaws.region.ssmmessages

Total cost: ~$21.60/month just for the VPC Endpoints, plus additional complexity in setup and troubleshooting. For an educational article focused on WAF and application security fundamentals, this additional cost would make the architecture less accessible for learning purposes.

The current implementation keeps the EC2 in a public subnet but eliminates SSH exposure entirely through Systems Manager Session Manager. While the instance has a public IP, the Security Group ensures no direct access is possible, only the ALB can reach it on port 80. This achieves approximately 90% of the security benefit of a private subnet at 0% of the additional cost, making it ideal for learning, development, and testing environments.

Why this matters for your security journey:

This architecture demonstrates Layer 3, 4, and 7 protection fundamentals with encrypted transport, IAM based access control, and zero SSH exposure. It's an excellent educational starting point and works well for:

Development and testing environments
Learning AWS security concepts and best practices
Understanding the defense in depth model
Proof of concepts and demos
Small internal tools with limited exposure
Personal projects and portfolios

However, for production workloads handling real user data, PII, or serving public traffic at scale, you need the additional layers mentioned above. Security is not a single solution, it's a layered approach where each control addresses specific attack vectors and threat models.

Recommended next steps:

Enable Session Manager logging to CloudWatch for audit trails (minimal cost)
Add rate-based rules to WAF for basic request rate limiting
Enable CloudWatch logging for WAF and create alarms for blocked requests
Implement GuardDuty for threat detection ($4-$10/month for light usage)
Use Security Hub for centralized security findings (additional cost)
Evaluate private subnet migration with VPC Endpoints when budget allows
Consider CloudFront for global distribution and additional edge protection
Enable automated patching with Systems Manager Patch Manager

Each of these topics deserves its own deep dive, which I plan to cover in future articles as part of a comprehensive AWS security series.

AWS WAF pricing is based on:

Number of Web ACLs
Number of rules
Number of requests inspected

A few things to know for this setup:

AWS WAF is not included in the AWS Free Tier
For low traffic environments, costs are typically minimal
Costs stay predictable as long as you clean up resources after testing

If you're just experimenting, expect single digit dollar amounts per month for WAF itself, assuming moderate traffic.

Conclusion

Security Groups and AWS WAF aren't competing solutions. They work at different layers and solve different problems.

Security Groups control who can connect.

AWS WAF controls what those connections are trying to do.

Understanding which control applies at which layer is what makes it possible to build secure, scalable architectures, even for relatively simple workloads.

Protecting a web application doesn't require complex tooling. It requires putting the right controls at the right layers.

If you're running web applications on EC2 without WAF, this architecture is a solid starting point.

A note on this content

This article documents my learning journey with AWS security architecture. I'm sharing what I've learned and built, not claiming to be an expert. If you spot something that could be improved, or if you have a better approach, I genuinely want to hear about it.

Security architecture is complex, and there are often multiple valid ways to solve the same problem. The setup I've described here prioritizes learning and understanding core concepts over production grade completeness. Real production environments would require additional layers like GuardDuty, Security Hub, comprehensive logging, and a more robust network isolation strategy.

If you have feedback, corrections, or suggestions, please reach out that's how we all get better.

Thanks for reading.🙂

Securing Serverless APIs with Amazon Cognito and API Gateway JWT Authorizers

Geovane Oliveira — Wed, 24 Dec 2025 13:41:36 +0000

Introduction

Securing APIs is one of those topics that looks simple at first, but quickly becomes complex in real world scenarios.
When you move to a serverless architecture, this challenge becomes even more critical.

Many implementations end up pushing authentication logic into Lambda functions, creating custom token validation, extra code paths, and unnecessary operational overhead.

In this article, I will walk through a practical and production ready approach to secure an AWS API Gateway endpoint using Amazon Cognito and the native JWT Authorizer, without Lambda authorizers or custom authentication logic.

This setup is cost efficient, scalable, and relies entirely on managed AWS services.

All the reference code and supporting artifacts used in this article are available in the following GitHub repository:
aws-secure-serverless-api-cognito-jwt

Architecture Overview

The architecture used in this experiment is the following:

Amazon Cognito User Pool for authentication

API Gateway HTTP API
Native JWT Authorizer
AWS Lambda as the backend
CloudWatch Logs for observability

The key idea is to let Amazon Cognito handle authentication, while API Gateway is responsible for validating JWTs before the request ever reaches Lambda.

This means invalid or expired tokens never invoke your backend code.

The full request flow is illustrated in the diagram below:

Step 1: Creating the Cognito User Pool and App Client

We start by creating a Cognito User Pool and an App Client.

Important configuration points:

Enable USER_PASSWORD_AUTH
Disable client secret (required for public clients and Postman testing)
Use email as a sign-in alias

This App Client will be responsible for issuing Access Tokens and ID Tokens.

This corresponds to step 1 in the architecture, where the user authenticates directly with Amazon Cognito.

User confirmation requirement:

When users are created manually or via the AWS Console, they may initially be in the FORCE_CHANGE_PASSWORD or UNCONFIRMED state.

For this experiment, the user must be fully confirmed before authentication succeeds.

To ensure this, the user account was confirmed using AWS CloudShell and the AWS CLI, setting a permanent password and moving the user to the CONFIRMED state.

This step is important because Cognito will reject authentication attempts for users that are not fully confirmed.

Once the user is confirmed, authentication via Postman works as expected.

Step 2: Authenticating with Cognito

Authentication is performed using the InitiateAuth API.

Using Postman, we send a request to the Cognito endpoint with:

AuthFlow: USER_PASSWORD_AUTH
ClientId
Username and password

If authentication succeeds, Cognito returns:

AccessToken
IdToken
RefreshToken

At this point, we already have everything needed to call a protected API.

Step 3: Configuring the API Gateway JWT Authorizer

Instead of using a Lambda Authorizer, we configure a native JWT Authorizer directly in API Gateway.

Key settings:

Issuer: Cognito User Pool issuer URL
Audience: Cognito App Client ID
Identity source: Authorization header

This tells API Gateway exactly how to validate incoming JWTs automatically.

Step 4: Protecting the API Route

Next, we attach the JWT Authorizer to the /secure route.

Once attached:

Requests without a token return 401 Unauthorized
Requests with invalid or expired tokens are rejected
Only valid tokens are allowed through

All of this is enforced by API Gateway itself, before Lambda is invoked.

Step 5: Lambda Backend and Token Claims

At this stage, authentication and token validation are already completed.

The Lambda function does not validate JWTs, does not decode tokens, and does not contain authentication logic.

API Gateway injects the decoded JWT claims directly into the request context, under:

event.requestContext.authorizer.jwt.claims

Below is the complete Lambda function used as the secure backend:

import json

def lambda_handler(event, context):
    print("Lambda secure-api-backend INVOCADA")
    print("RequestId:", context.aws_request_id)

    claims = event["requestContext"]["authorizer"]["jwt"]["claims"]

    print("JWT claims recebidas:")
    print(json.dumps({
        "sub": claims.get("sub"),
        "email": claims.get("email"),
        "username": claims.get("cognito:username"),
        "issuer": claims.get("iss"),
        "token_use": claims.get("token_use"),
        "scope": claims.get("scope")
    }))

    response = {
        "message": "Authorized request",
        "user": {
            "sub": claims.get("sub"),
            "email": claims.get("email"),
            "username": claims.get("cognito:username"),
            "issuer": claims.get("iss"),
            "token_use": claims.get("token_use"),
            "scope": claims.get("scope")
        }
    }

    return {
        "statusCode": 200,
        "headers": {
            "Content-Type": "application/json"
        },
        "body": json.dumps(response)
    }

This keeps the backend extremely simple and focused:

API Gateway handles security
Lambda consumes already validated identity data
Logs provide full traceability

Step 6: Validation and Results

We tested three different scenarios:

No token
401 Unauthorized

Invalid token
401 Unauthorized

Valid Access Token
200 OK and Lambda executed

CloudWatch Logs confirm that the Lambda function is only invoked when the token is valid, proving that the security boundary is enforced at the API Gateway level.

Reference Implementation

The complete reference implementation, including the Lambda function, Postman collection, and architecture diagram, is available on GitHub:
aws-secure-serverless-api-cognito-jwt

Conclusion

Using Amazon Cognito together with API Gateway JWT Authorizers is one of the cleanest and most efficient ways to secure serverless APIs on AWS.

There is no custom authentication code, no Lambda Authorizers, and no additional infrastructure to manage.

API Gateway becomes the security gate, and Lambda focuses only on business logic.

This is a pattern I recommend for modern, scalable, and secure serverless applications.

A note on this content

If you have feedback, corrections, or suggestions, please reach out that's how we all get better.

Thanks for reading.🙂