DEV Community: Geovane Oliveira

How I passed the AWS Security Specialty and how you can too

Geovane Oliveira — Mon, 01 Jun 2026 03:30:54 +0000

Introduction to AWS certifications

First things first, lets understand what the AWS Security Specialty certification is and where it fits in the AWS certification ecosystem.

AWS certifications are divided into levels, each one targeting a different stage of your journey:

Practitioner
Associate
Professional
Specialty

The practitioner level is where most people start.
It focuses on foundational cloud concepts and basic AWS knowledge.

As of today, there are two certifications at this level:

AWS Cloud Practitioner
AWS AI Practitioner

The Cloud Practitioner covers core concepts like IAM, security, availability, pricing, and general cloud architecture.

The AI Practitioner follows a similar structure, but focused on AI concepts and AWS AI services.

The associate level is where things start to get more practical.

At this level, you are expected to understand how to design and build solutions using AWS services.
Some well-known certifications here are:

Solutions Architect Associate
Developer Associate
CloudOps Engineer Associate (formerly SysOps Administrator)
Data Engineer Associate
Machine Learning Engineer Associate

The professional level goes much deeper.

Here, you are expected to design complex architectures, handle trade offs, and make decisions based on real world constraints.

The main certifications are:

Solutions Architect Professional
DevOps Engineer Professional
Generative AI Developer Professional

Finally, we have the specialty certifications.

These are focused on specific domains and require deep knowledge in a particular area.

Examples include:

Security Specialty
Machine Learning Specialty (Retired)
Advanced Networking Specialty

And this is exactly where things start to get serious.

At this level, AWS is no longer testing if you understand the services.
It's testing if you can actually apply them in complex, real world scenarios.

What it is and who this certification is for

The AWS Security Specialty is one of the most difficult certifications in your AWS journey.

This exam expects that you already know the basics and are comfortable with complex and long detailed scenarios that you often come across when designing and securing AWS workloads.

So the exam will not ask you what GuardDuty is or what WAF is.
Instead, it will present you with a detailed scenario, and you, as a security engineer, will have to find the solution that best fits the situation.

Just like in the real world, a single service will not solve your need.
It's a combination of services and configurations tailored to your scenario.

Because of that, you need to have a solutions architect mindset with an additional layer SysOps and of course deep security expertise.

Without this knowledge, you won't be able to come up with a solution.

It's highly recommended that you have already passed the Solutions Architect certification before attempting the Security Specialty.
Although this is not a hard prerequisite, it is strongly recommended.

The AWS Security Specialty is intended for experienced security professionals who work mainly securing AWS environments.

AWS recommends that you have at least 3 to 5 years of hands on experience with AWS security, plus strong knowledge of vendor neutral security principles that can be applied to any cloud provider or application. That's where certifications like CompTIA Security+ and CCSP comes in to give you a solid and agnostic knowledge.

This is a Specialty level certification, which means you are expected to have deep knowledge of security and securing AWS workloads at an enterprise level.

The questions are scenario based, usually long, with long and very similar answer options. But only one answer will satisfy the scenario, which my result in you flagging a lot of questions to review later on.

Be prepared for a mental endurance test that will chalenge not only your technical knowledge, but also your ability to maintain focus for up to 3 hours of long scenario based questions (or 3h30 if you are not a native english speaker and apply for the ESL extra time).

How to prepare for the exam

Before you try the Security Specialty, you need to have both security foundational and advanced knowledge and AWS foundational and advanced knowledge.

For security knowledge, there are many ways you can achieve it.

I highly recommend that you study for CompTIA Security+, which will give you very solid, vendor neutral security knowledge that you can apply in any environment or application.

You will learn concepts like:

least privilege
cryptography
authentication and authorization
defense in depth
Threat vectors

There are also many foundational, intermediate, and advanced courses available on AWS Skill Builder.

Some of them are paid, but most are free, and you can also earn badges to show on your LinkedIn profile.

But remember, this does not replace the necessary hands on experience.

Many courses offer guided labs, but the best way to learn is by actually building something, applying the security concepts, breaking things, fixing things, and testing different approaches.

You should also build your portfolio, which will help you gain experience, increase your confidence, and improve your attractiveness for job opportunities.

Here's a list of courses and materials I do recommend for your security journey:

- AWS Security Fundamentals
- Ultimate AWS Certified Security Specialty SCS-C03 By Stephane Mareek (This is a must have course)
- AWS Skill Builder Exam Prep Plan Security - Specialty (SCS-C03)

Extras:
- Foundations of Cybersecurity by Google
- CompTIA SY0-701 Security+ Free Training Course - Professor Messer

My journey to AWS Security Specialty

As a cloud security engineer, I already have extensive knowledge about cybersecurity and solutions architecture, which helped me a lot in my journey to the Security Specialty. But that doesn't mean it was easy.

It does help, but the exam explores many AWS services that you might not have much familiarity with in your daily work. That's why you really need to practice in the AWS console and also take as many practice exams as you can.

My first attempt was back in August 2024, after studying for more than six months. I almost passed on my first try. I scored 718 points, which is very close to the passing score.

I became really frustrated because I missed it by just a few questions, and I knew how much effort and time I had put into my preparation. I knew I had the necessary knowledge, but it wasn't enough.

After the exam, I tried to remember some of the questions I was unsure about and started researching the AWS documentation to check if my understanding was correct.

Then I outlined what wasn't clear yet so I could better prepare for a second attempt.

I identified some services and details that weren't clear in my head, like S3 retention modes and some tricky details about SCP in AWS Organizations.

And one important lesson:

Do not underestimate any service. Even the ones you think might not appear in your exam will show up. You need to understand the details of everything outlined in the exam guide.

My second attempt

My second attempt was almost two years later, in February 2026, after studying for about a month and a half.

During this time, I:

Reviewed Stephane Maarek's course
Completed Tutorials Dojo practice exams
Reviewed my previous notes
Added new notes for topics that were still unclear

Once I started consistently scoring above 800 in practice exams, I knew I was ready. At that point, I realized that waiting longer would only make me more anxious.

During the exam, I felt that it was slightly less complicated than my first attempt. In many questions, I felt very confident about my answers, but I stayed calm and focused.

I finished the exam with about 20 minutes left (with ESL extra time). I reviewed the questions I wasn't so sure about, but I kept my original answers.

In my first attempt, I realized that I probably lost points because I changed answers that were already correct when I was reviewing, so watch out for that.

So this time, I trusted my reasoning. I finished the exam knowing that I had done my best.

The final result arrived one day later.

I passed with a score of 804.

How I studied for the Security Specialty and how the exam felt

When preparing for an AWS exam, I always start with Stephane Maarek's courses. They are my go to recommendation for anyone studying for AWS certifications.

Neal Davis courses are also a great option, but I see them more as a complement to gain deeper understanding.

Another must have resource is Tutorials Dojo. Their practice exams are very well crafted, with detailed explanations that help you identify and close knowledge gaps.

Once you consistently score above the passing score, you know you are ready to take the exam.

AWS Skill Builder is also a good complementary resource. It provides practice exams created by AWS, which are closer to the real exam experience.

One thing that helped me a lot was creating mental acronyms and references to remember concepts and details. Because even if you are an experienced security professional, it's almost impossible to remember every detail of every AWS service in depth. And for this exam, you need depth.

Not only in security services, but also in services like:

CloudWatch
Lambda
S3
EC2
KMS
Organizations

This level of depth is what separates a passing score from a failing score.

Mental models and tricks I used during the exam

Before anything, one important clarification:

During the exam, you are not allowed to consult anything.
No notes, no documentation, no external resources.
**Everything you need must already be inside your head.**

These mental models and shortcuts are not something you will create during the exam. They are something you need to study, practice and internalize beforehand. If you rely on memorizing during the exam, you’re already too late.

These are some of my personal notes and mental shortcuts that helped me recall concepts quickly during the exam. You should create your's and use this as an starting point of what you should expect. And remember, if you only take notes but doesnt understand what they mean and how every service and configuration works in AWS, then you are studying the wrong way, and this is a recipe for failing any exam you take.

Security Group vs NACL

Security Group = "Security with memory" (stateful)

Imagine a security guard at a private party:

Entry: You show your invitation and get in
Exit: The guard remembers you and lets you leave

If inbound is allowed, outbound response is automatically allowed.

NACL = "Security with amnesia" (stateless)

Imagine a guard that forgets everything:

Entry works normally
Exit requires a new check

You must explicitly allow outbound traffic.

NACL works at subnet level.

Inspector vs Detective vs Audit Manager

Inspector = Find vulnerabilities before attackers
Detective = Understand what happened after an event
Audit Manager = Build compliance reports continuously

Endpoint types

Gateway Endpoint = S3 and DynamoDB
Interface Endpoint = almost everything else

Audit tools comparison

Audit Manager = compliance evidence
Config = configuration tracking
Inspector = vulnerabilities
Detective = investigation

KMS

Cannot delete immediately
Minimum 7 days
Default 30 days
Keys are regional

Remediation patterns

Config → EventBridge → Lambda
Trusted Advisor → EventBridge → Lambda
GuardDuty → EventBridge → Step Functions
Security Hub → EventBridge → Step Functions
Config → SSM Document

S3 retention

Governance = flexible
Compliance = cannot be disabled
Legal Hold = independent

Versioning must be enabled

SCP

Management Account is not restricted

Management Account = SCP immune

Secrets

Parameter Store = simple
Secrets Manager = advanced
ACM = certificates

Security Hub

Needs AWS Config
Organizations only for multi account

Networking

NAT Gateway = outbound only
Internet Gateway = inbound and outbound

IAM Access Analyzer

Finds external access
Works on resource policies
Regional

Load balancers

ALB = Layer 7
NLB = Layer 4
GWLB = inspection

Endpoints summary

Gateway Endpoint

S3 and Dynamo
Free

Interface Endpoint

Most services
Paid

Final thoughts

This certification was one of the most challenging steps in my AWS journey. Not only because of the difficulty, but because it forced me to think differently.

It's not about memorizing services. It's about understanding how to combine them to solve real problems.

And more importantly, it's about making decisions under pressure, with incomplete information, just like in real world scenarios.

Failing my first attempt was frustrating, but it was also necessary. It showed me that knowing is not the same as being ready.

The second attempt was different. Not because the exam was easier, but because my mindset was.

If you are preparing for this exam, focus on:

understanding the "why" behind each service
practicing real scenarios
identifying your weak points early
and building confidence through repetition
And make sure to practice with hands on in AWS, not just theory

And one important thing:

You won't pass this exam by luck. And you definitely won't pass it by just watching courses.

You need real hands on practice.

Build things in AWS.
Break them.
Fix them.
Test different approaches.

That's where the concepts actually become clear.
You pass when your reasoning becomes natural.

When you stop thinking "which service is this" and start thinking "what problem am I solving". That's when everything clicks.

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.🙂