Innovative Software Technology-Securing On-Premises Web Applications with AWS WAF via CloudFront

Protecting on-premises web applications with cloud-native security services like AWS WAF can seem challenging. Traditionally, Web Application Firewalls (WAFs) are associated directly with AWS resources such as Application Load Balancers or API Gateways, not with standalone EC2 instances or external IP addresses. However, a creative approach allows you to extend AWS WAF’s robust protection to your on-premises infrastructure.

This guide details a step-by-step implementation for securing an on-premises web application using AWS WAF, facilitated by an AWS CloudFront distribution. We’ll cover the necessary SSL/TLS certificate creation, CloudFront deployment with WAF integration, and critical DNS routing configurations, all aligned with the security best practices of the AWS Well-Architected Framework.

Why AWS WAF for On-Premises?

For organizations with on-premises web applications that require WAF protection but want to avoid the overhead of deploying and managing a local WAF solution, AWS WAF offers a compelling alternative. As a fully managed service, AWS WAF simplifies security by allowing you to define rules without worrying about underlying infrastructure.

Key benefits include:
* Managed Rules: AWS WAF provides pre-configured managed rule sets that automatically detect and mitigate common web vulnerabilities like those listed in the OWASP Top 10. AWS continuously updates these rules.
* Custom Rules: You can create your own custom rules (stateful or stateless) to allow or block specific IP addresses, apply geographical restrictions, or leverage regular expressions for fine-grained control.
* Reduced Operational Burden: By offloading WAF management to AWS, you free up resources that would otherwise be spent on provisioning, patching, and maintaining a local WAF appliance.
* Rapid Deployment: Configuring AWS WAF is typically much faster than setting up traditional on-premises WAF solutions, making it ideal for scenarios where time is critical.

Whether your goal is to enhance web application security or meet regulatory compliance, understanding how to integrate AWS WAF with an on-premises application is invaluable.

Architectural Overview

This implementation assumes your on-premises server hosts a web application accessible via HTTPS on port 443, using a public IP address and a domain (e.g., www.yourdomain.com) resolved through an A-type DNS record.

Our solution will involve:
1. Two SSL/TLS certificates: One for the CloudFront distribution and another for the on-premises server’s origin domain.
2. Installation of the appropriate SSL/TLS certificate on the on-premises server.
3. Creation of an AWS CloudFront distribution configured with its certificate, pointing to a new origin domain that resolves to your on-premises server. This distribution will be protected by AWS WAF.
4. A CNAME DNS record to direct traffic for your main domain (www.yourdomain.com) to the CloudFront distribution.
5. An A-type DNS record for the origin.yourdomain.com subdomain, pointing directly to the on-premises server’s public IP address.
6. Configuration of the on-premises application to exclusively accept traffic originating from CloudFront.

The final traffic flow will be:
1. www.yourdomain.com
2. DNS resolution to CloudFront
3. CloudFront distribution (protected by AWS WAF)
4. CloudFront requests origin.yourdomain.com
5. DNS resolution to the on-premises server’s public IP
6. On-premises server

Prerequisites

To follow this guide, you will need:
* An active AWS account with IAM permissions for CloudFront, AWS WAF, Amazon Route 53, and AWS Certificate Manager (ACM).
* Administrative access to your authoritative DNS provider (e.g., Cloudflare, Amazon Route 53).
* An on-premises server hosting a web application on port 443, with a public IP address. This includes:
* The ability to obtain new SSL/TLS certificates from a public Certificate Authority (CA) for a new subdomain (e.g., origin.yourdomain.com).
* Permissions to install new certificates on the on-premises server.
* Permissions to modify the web application’s configuration on the on-premises server.

Implementation Steps

This section provides a detailed walkthrough for integrating AWS WAF with your on-premises application, illustrating how ACM certificates, DNS records, CloudFront, and AWS WAF components work together.

1. Create and Install SSL/TLS Certificates

We need two distinct certificates for this setup: one for your main domain (e.g., www.yourdomain.com) to be used by CloudFront, and another for the new origin domain (origin.yourdomain.com) to be installed on your on-premises server.

For the On-Premises Server:
1. Using your preferred public Certificate Authority (CA), obtain a new SSL/TLS certificate valid for origin.yourdomain.com.
2. Install this new certificate on your on-premises server, ensuring it replaces any existing certificate for the origin domain or is configured alongside it if you are using multiple hosts on the same server.
3. Validate the installation using online SSL checkers (e.g., sslshopper.com) to confirm the certificate is valid for origin.yourdomain.com and has not expired.

For CloudFront (using AWS Certificate Manager – ACM):
1. In the AWS Management Console, navigate to AWS Certificate Manager.
2. Click “Request a certificate,” then select “Request a public certificate” and proceed.
3. Enter www.yourdomain.com (and any other alternative names like yourdomain.com) in the “Domain names” field.
4. Choose “DNS validation” as the validation method and click “Request.”
5. ACM will create a CNAME record that you must add to your authoritative DNS provider. If you use Amazon Route 53, you can often click a button to automatically create these records. Otherwise, manually add the CNAME name and value to your DNS configuration.
6. Once the DNS record propagates, the ACM certificate status will change from “Pending validation” to “Issued,” confirming successful issuance.

Note: AWS ACM now offers an “Allow export” feature for public certificates, which means you could potentially use ACM to generate the certificate for your on-premises server as well.

2. Create the CloudFront Distribution

This distribution will serve as the entry point for your web application, inspecting traffic with AWS WAF before forwarding it to your on-premises origin.

In the AWS Console, go to Amazon CloudFront.
Click “Create a CloudFront distribution.”
Under “Distribution options,” provide a “Distribution name” and ensure “Single website or app” is selected for “Distribution type.”
In the “Custom domain” section, you might be able to add www.yourdomain.com if your domain is managed by Route 53 in the same AWS account. Otherwise, you’ll add it later.
Click “Next.”
For “Origin type,” select “Other” since your origin is on-premises.
In the “Origin” section, specify origin.yourdomain.com as the “Custom origin.” Leave “Origin path” empty.
In the “Settings” section:
- Configure “Origin settings” as needed, or use defaults.
- For “Cache settings,” choose “Customize cache settings” and set “Origin request policy” to “AllViewer.” Adjust other cache parameters if required.
Click “Next.”
In the “Enable Security” section, select “Enable security protections.” You can optionally enable “SQL protection” and “Rate limiting” here, which will automatically create and associate a basic AWS WAF web ACL with your distribution.
Click “Next.”
If you specified your custom domain earlier and it’s managed by Route 53 in the same account, CloudFront will automatically detect the ACM certificate for www.yourdomain.com. If not, you’ll configure the TLS certificate in the next steps.
Click “Next” and review the distribution details, then click “Create distribution.”
The distribution will begin deploying. If you didn’t configure your custom domain or TLS certificate earlier (e.g., if using a different DNS provider or AWS account for Route 53):
- Once the distribution is created (even if still deploying), go to its settings.
- Edit the “General” section to specify www.yourdomain.com in “Alternate domain name (CNAME)” and select the ACM certificate you created earlier under “Custom SSL certificate.” Save changes.
Wait for the distribution to finish deploying. Once complete, copy the Distribution domain name (e.g., d1234.cloudfront.net), as you’ll need it for DNS configuration.

3. Configure DNS Routing

This step redirects your main domain traffic through CloudFront and ensures CloudFront can reach your on-premises origin.

For www.yourdomain.com to CloudFront:
- In your authoritative DNS provider, create a CNAME record (or an Alias record if using Route 53) for www.yourdomain.com.
- Point this record to the Distribution domain name you copied from your CloudFront distribution.
For origin.yourdomain.com to On-Premises:
- Create an A-type DNS record for origin.yourdomain.com.
- Point this record to the public IP address of your on-premises server.

After this, your www.yourdomain.com traffic will flow through CloudFront and be protected by WAF. However, origin.yourdomain.com remains directly accessible and unprotected. The next step addresses this vulnerability.

4. Restrict Access to the On-Premises Server

To ensure only WAF-inspected traffic reaches your on-premises server, you must restrict direct access to origin.yourdomain.com. The recommended method involves CloudFront sending a custom HTTP header with a secret value.

In the AWS Console, navigate to your CloudFront distribution, then go to the “Origins” tab.
Select your configured origin (origin.yourdomain.com) and click “Edit.”
Under the “Settings” section, find “Add custom header.” Add a new custom HTTP header with a unique, secret key-value pair (e.g., X-Origin-Verify: YourSecretValue).
Save the changes. CloudFront will now include this header in all requests it forwards to your on-premises origin.
Finally, configure your on-premises web server (e.g., Nginx, Apache, IIS) to only accept requests that contain this specific custom HTTP header with the correct secret value. All other requests should be rejected.

This final step is crucial to prevent direct access to your on-premises server, thereby guaranteeing that all incoming traffic is inspected and filtered by AWS WAF.

Cost Structure

Understanding the potential costs is important. The prices below are estimates as of October 2025 and can vary by region and actual usage.

Amazon CloudFront:
- Data transfer out (first tier): ~ USD 0.085 per GB (US/Mexico/Canada/Europe).
- HTTP/HTTPS request cost: ~ USD 0.01 per 10,000 requests.
- Free Tier: Includes 1 TB data transfer out and 10 million requests per month.
AWS WAF:
- Web ACL cost: USD 5.00/month per Web ACL.
- Cost per rule: USD 1.00/month per rule.
- Cost per inspected request: USD 0.60 per million requests.
Amazon Route 53:
- Public hosted zone: USD 0.50/month for the first 25 zones.
- DNS query cost: ~ USD 0.40 per million queries (first 1 billion queries).
AWS Certificate Manager (ACM):
- Public certificates used with integrated services like CloudFront typically incur no additional cost.

Monthly Cost Estimate Example:

Assuming: us-east-1 region, 1,000 GB outbound data from CloudFront, 10 million CloudFront requests, one AWS WAF Web ACL with one rule, one Route 53 hosted zone with two records, one ACM certificate, and modest DNS queries.

Component	Estimated Monthly Cost (USD)
CloudFront – Data Out	85.00
CloudFront – Requests	10.00
WAF – Web ACL	5.00
WAF – Rules	1.00
WAF – Inspected Requests	6.00
Route 53 – Hosted Zone	0.50
Route 53 – Records	0.00
Route 53 – DNS Queries	0.05
ACM – Certificate	0.00
Estimated Total	~ USD 107.55

Lessons Learned and Best Practices

Precise FQDN Certificates: Always request certificates for the exact Fully Qualified Domain Name (FQDN) you intend to use. Wildcard certificates (*.yourdomain.com) are more expensive and often unnecessary.
Customize WAF Rules: While basic WAF protection is enabled by default, tailor your web ACL with additional rules specific to your application’s vulnerabilities and traffic patterns. This includes protection against OWASP Top 10 threats, SQL injection, and rate limiting.
Enforce Origin Access Restrictions: It is critical to restrict direct access to your on-premises server from the public internet. Failure to do so leaves your server exposed and bypasses WAF inspection. The custom HTTP header method is highly recommended.
Rotate Secrets: As a security best practice, periodically renew the secret value of your custom CloudFront HTTP header (e.g., annually) to mitigate risks from potential leaks.

Conclusion

Even when a full migration to the cloud isn’t feasible, AWS WAF provides an accessible and effective solution for bolstering the security of on-premises web applications. By leveraging a CloudFront distribution as a proxy, you can seamlessly integrate a managed web application firewall, ensuring that all traffic is rigorously inspected and filtered by AWS WAF before reaching your on-premises server. This approach significantly enhances the application’s security posture without requiring substantial local infrastructure investment or management.

Further Exploration

For more in-depth information and specific technical details, refer to the official AWS documentation:
* What is Amazon CloudFront?
* Amazon CloudFront Pricing
* What is AWS WAF?
* AWS WAF Pricing
* Using AWS WAF with Amazon CloudFront
* What is AWS Certificate Manager?
* AWS Certificate Manager Pricing
* What is Amazon Route 53?
* Amazon Route 53 Pricing

I encourage you to implement this solution and experience the benefits firsthand. Share your thoughts and discoveries in the comments!