Integrating AWS WAF with App Runner

AWS WAF (Web Application Firewall) protects your App Runner services by filtering malicious traffic, reducing resource usage, and improving security. App Runner simplifies deploying web applications, while AWS WAF adds an extra layer of protection against threats like SQL injection and XSS.

Key Takeaways:

• AWS WAF: Blocks harmful HTTP/HTTPS requests using custom or managed rules.
• AWS App Runner: Deploys web apps with minimal effort, handling scaling and HTTPS endpoints.
• Integration Benefits: Secure public endpoints, prevent attacks, and manage traffic efficiently.

Steps to Integrate:

1. Set Up App Runner: Deploy your service from source code or a container image.
2. Create a WAF Web ACL: Define rules like IP restrictions, rate limits, or AWS-managed rule groups.
3. Associate Web ACL with App Runner: Use the AWS Console, CLI, or API to link the WAF to your service.

Note: WAF rules work differently for public and private App Runner services. Private services require security group rules for IP filtering.

Prerequisites for Integration

Before diving into the integration process, make sure you've set up the necessary AWS services and verified regional compatibility. You'll also need specific permissions and a properly configured App Runner service to serve as the foundation for this setup.

AWS Services and Permissions Required

To get started, you'll need access to AWS WAF, App Runner, and IAM. Specific IAM permissions are crucial for associating a WAF web ACL with your App Runner service.

Here are the required permissions:

• For WAF operations:
  • wafv2:AssociateWebACL
  • wafv2:DisassociateWebACL
  • wafv2:GetWebACLForResource
  • wafv2:CreateWebACL
  • wafv2:UpdateWebACL
  • wafv2:GetWebACL
  • wafv2:ListWebACLs
• For App Runner operations:
  • apprunner:AssociateWebAcl
  • apprunner:DisassociateWebAcl
  • apprunner:DescribeWebAclForService

These permissions are essential for creating, managing, and associating WAF web ACLs with an App Runner service, as well as monitoring their configurations.

AWS Account and Region Support

AWS WAF can protect App Runner services in regions where both services are available. However, keep in mind that the WAF web ACL and the App Runner service must exist in the same region. For instance, you cannot protect an App Runner service in us-east-1 using a WAF web ACL created in us-west-2.

When associating a new web ACL with your App Runner service, remember that each service can only have one web ACL at a time. After initiating the association, it may take anywhere from a few seconds to several minutes for the web ACL to propagate fully. During this time, attempting to use it might result in a WAFUnavailableEntityException error.

One key limitation to note: Private App Runner services cannot use WAF source IP rules. This is because request source IP data isn’t forwarded to private services when WAF is in use. If your private service requires source IP or CIDR-based traffic controls, you'll need to rely on security group rules for private endpoints instead of WAF web ACLs.

Additionally, AWS WAF inspects up to 64 KB of request bodies for App Runner services, with a default limit of 16 KB (configurable). Standard AWS WAF pricing applies, but there are no extra charges for using WAF with App Runner.

Once you've confirmed the required permissions and regional setup, you're ready to move on to deploying a basic App Runner service.

Setting Up a Basic App Runner Service

To proceed, ensure you have an App Runner service up and running. This can be deployed from either source code or container images. During setup, configure the following:

• Repository connection
• Build commands
• Start command
• Environment variables

Wait until the service status changes to Running before starting the WAF integration process.

Creating and Configuring a WAF Web ACL

Now that you've got your App Runner service up and running, it's time to strengthen its defenses by creating and configuring a WAF web ACL. A WAF web ACL is essentially a set of rules that determines which requests should be allowed, blocked, or logged based on specific conditions you define. This is a key step in protecting your application from web-based threats.

Defining WAF Web ACL Rules

WAF web ACLs offer multiple rule types to address various security needs:

• Rate-based rules: These are great for mitigating DDoS attacks by limiting the number of requests from a single IP. For example, you can block IPs that exceed 2,000 requests within five minutes.
• IP set rules: These allow you to create lists of IP addresses or CIDR blocks to either allow or block. Use them to deny access from known malicious sources or to permit traffic from trusted networks, like your office.
• Managed rule groups: AWS provides pre-configured rule groups that protect against common threats. Examples include the AWS Core Rule Set (guarding against vulnerabilities like those in the OWASP Top 10), Known Bad Inputs (blocking malicious patterns), and SQL injection prevention.
• Custom rules: These let you define specific conditions based on request details such as headers, query strings, or request bodies. For instance, you might block requests with a specific user agent or allow only those containing certain authentication headers.

Each rule has a priority number, dictating the order in which WAF evaluates them. Lower numbers take precedence. If a rule matches a request, the action (allow, block, or count) is applied, and further rule processing stops unless the action is set to Count.

Once you've defined your rules, you can create the web ACL using your preferred method.

Using AWS Console or AWS CLI

If you prefer a visual workflow, the AWS Management Console makes creating a web ACL straightforward. Start by navigating to the WAF service, selecting Web ACLs, and clicking Create web ACL. Since App Runner is a regional service, choose Regional as the resource type.

During setup, you'll need to specify a default action for requests that don’t match any rules. Most configurations use Allow as the default action, adding rules later to block unwanted traffic.

For those who prefer command-line tools, the AWS CLI provides a powerful alternative. Here's an example command to create a web ACL:

aws wafv2 create-web-acl \
  --scope REGIONAL \
  --default-action '{"Allow": {}}' \
  --name "AppRunnerWebACL" \
  --region us-east-1

After creating the web ACL, you can add rules using additional AWS CLI commands. This method is especially useful for automation and offers fine-grained control.

When incorporating managed rule groups, you can override specific rules. For instance, if the AWS Core Rule Set blocks legitimate traffic, you can modify the problematic rule to Count instead of Block, ensuring you still benefit from the broader protection.

Alternatively, you can define your entire WAF setup in a CloudFormation template. This approach ensures version control and makes deployments consistent across environments.

With your web ACL in place, you’ll want to follow best practices to maximize its effectiveness.

Best Practices for WAF Configuration

• Start with monitoring: Initially, set new rules to the Count action. This logs matches without affecting traffic. Review logs for false positives before switching rules to Block.
• Leverage managed rule groups: The AWS Core Rule Set offers solid protection against common attacks and is regularly updated by AWS. Pair it with SQL injection prevention for a strong baseline defense.
• Set appropriate thresholds for rate-based rules: Configure thresholds that align with your typical traffic patterns. While 2,000 requests per five minutes is a good starting point, adjust as needed for high-traffic applications.
• Prioritize rule order: Place specific rules, like an IP allowlist for your office network, before broader managed rule groups. This reduces processing time and ensures critical rules are applied first.
• Monitor metrics in CloudWatch: Keep an eye on key metrics like blocked, allowed, and sampled requests. A spike in blocked requests could signal an attack or overly restrictive rules.
• Enable WAF logging: Detailed logs in CloudWatch Logs, Amazon S3, or Kinesis Data Firehose can help you troubleshoot and fine-tune your configuration.

Before deploying your WAF setup to production, thoroughly test it in a staging environment. Simulate attack scenarios to confirm that malicious traffic is blocked while legitimate requests flow through, especially for critical API endpoints and forms.

Connecting WAF Web ACL with an App Runner Service

Once your web ACL is configured, the next step is linking it to your App Runner service. This connection ensures incoming requests are filtered according to your defined rules. AWS offers several ways to set up this association, but the App Runner Console is the easiest starting point.

Using the App Runner Console

The App Runner console simplifies the process of associating a web ACL with your service. You can do this either while creating a new service or by updating an existing one.

For new services, go to the App Runner console and select Create an App Runner service. After setting up your source code or container image, move to the Configure Service step. Scroll down to the Web application firewall section under Security. Toggle the Activate button to see your options. If you already have a web ACL, select it from the Choose a web ACL table, which lists all available regional web ACLs in your current AWS region. Need a new web ACL? Click Create web ACL to open the AWS WAF console and set one up.

For existing services, head to the service's Configuration tab and click Edit under Configure service. In the Web application firewall section, activate the toggle and choose your desired web ACL from the list.

Make sure your IAM permissions allow this association.

Timing is key: When a web ACL is created, it may take a few minutes to propagate fully. Trying to associate it too early can result in a WAFUnavailableEntityException. Also, avoid refreshing the browser or leaving the App Runner console during this propagation period, as it might disrupt the process.

After selecting your web ACL, click Next for new services or Save changes for existing ones. To confirm the association, check the Web application firewall section in the service's Configuration tab.

Using AWS CLI or API

For a more programmatic approach, the AWS CLI lets you associate a web ACL with your App Runner service. You'll need the ARNs of both your web ACL and App Runner service.

Run the following command to associate the web ACL:

aws wafv2 associate-web-acl \
  --web-acl-arn "arn:aws:wafv2:us-east-1:123456789012:regional/webacl/AppRunnerWebACL/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" \
  --resource-arn "arn:aws:apprunner:us-east-1:123456789012:service/my-app-service/1234567890123456789012345678901234567890" \
  --region us-east-1

Keep in mind that both the web ACL and App Runner service must be in the same AWS region, as App Runner operates regionally.

To find your App Runner service ARN, use:

aws apprunner list-services --region us-east-1

And to get your web ACL ARN, use:

aws wafv2 list-web-acls --scope REGIONAL --region us-east-1

This method is ideal for CI/CD pipelines. You can include these commands in CloudFormation templates, AWS CDK stacks, or deployment scripts to maintain consistent security settings across environments.

To remove a web ACL later, use the disassociate-web-acl command:

aws wafv2 disassociate-web-acl \
  --resource-arn "arn:aws:apprunner:us-east-1:123456789012:service/my-app-service/1234567890123456789012345678901234567890" \
  --region us-east-1

Public vs. Private App Runner Services

The process for associating a web ACL is the same for both public and private App Runner services. However, there are some key differences to be aware of.

Public App Runner services are accessible over the internet by default. These services work seamlessly with all WAF rule types, including IP-based rules. Source IP information is passed along, enabling rules like rate limiting, IP set restrictions, and geolocation filtering to function correctly.

Private App Runner services, on the other hand, are only accessible within an Amazon VPC. This setup has a notable limitation: source IP rules in WAF web ACLs don't work as expected. AWS doesn't currently support forwarding source IP data to private App Runner services when WAF is involved.

If you need IP-based traffic control for private services, use security group rules for private endpoints instead. Configure your VPC endpoint's security groups to manage traffic by IP ranges, while relying on WAF for other protections like SQL injection and XSS filtering.

Other WAF rule types, such as managed rule groups, custom rules based on headers or query parameters, and geographic restrictions, still function effectively with private services.

sbb-itb-6210c22

Managing and Updating WAF Rules

Once you've integrated AWS WAF with your App Runner service, it's crucial to regularly update and adjust your WAF rules. This helps address new threats, minimize false positives, and maintain optimal performance in line with your application's traffic patterns.

Updating and Fine-Tuning WAF Rules

WAF rules are not a one-and-done setup. As your application evolves and new threats emerge, your rules will need adjustments.

To make changes, use the AWS WAF console. Updates take effect within 60 seconds. Simply navigate to your web ACL, select the rule, and modify settings like rate limits, IP sets, or custom rule conditions.

When adding new rules, pay attention to their priority order - rules with lower numbers are executed first. This ensures critical blocks are processed before less urgent ones. For instance, you might add seasonal IP restrictions, adopt new managed rule groups from the AWS Marketplace, or create custom rules to counter specific attack patterns.

Before fully activating new rules, use the Count mode to monitor their impact. This lets you observe the rule's behavior without blocking legitimate users. Once you're confident the rule is working as intended, you can switch it to Block mode.

Streamline your web ACL by removing rules that show no matches over time or consolidating similar ones. A leaner ACL can improve response times. Also, keep geographic restrictions updated. If your business expands into new regions or you identify threats from specific areas, adjust your geo-blocking rules accordingly. Similarly, IP set rules should reflect changes in your organization's network or newly identified threat sources.

Finally, ensure you have effective monitoring in place to evaluate how your updates perform.

Monitoring WAF Activity

Monitoring is key to understanding both your application's security and the effectiveness of your WAF rules. AWS offers several tools to help you track activity and performance.

CloudWatch metrics provide insights into AllowedRequests, BlockedRequests, and CountedRequests. These metrics can reveal traffic trends and help you assess rule performance. Set up CloudWatch alarms to detect unusual spikes in blocked requests, which could indicate an attack or misconfigured rules.

Enable logging in your web ACL settings to send detailed logs to CloudWatch Logs, S3, or Kinesis Data Firehose. These logs are invaluable for diagnosing false positives or analyzing attack patterns.

You can also use AWS WAF Security Automations to enhance monitoring. This solution automatically creates CloudWatch dashboards and sets up automated responses to common attack patterns. It's especially helpful during sudden traffic spikes or coordinated attacks that might overwhelm manual responses.

Keep an eye on costs, too. AWS WAF charges are based on web ACLs, rules, and request volume. Use AWS Cost Explorer to monitor your monthly expenses, especially if you're processing large traffic volumes or using multiple managed rule groups. Regularly review your enabled rule groups to ensure they provide value.

Performance monitoring is equally important. Track your App Runner service's response times before and after implementing WAF rules. While WAF typically adds minimal latency, complex custom rules or multiple managed rule groups can sometimes slow things down.

During traffic spikes or suspected attacks, real-time monitoring becomes critical. Use the Sampled requests section in the WAF console to quickly review recent requests that matched your rules. This helps you identify whether blocks are justified or if adjustments are needed.

To manage updates effectively, it's also worth comparing different configuration methods.

Configuration Methods Comparison

Choosing the right configuration method can make managing WAF rules more efficient. Each method has its strengths and trade-offs, depending on your team's needs.

The AWS Console is ideal for quick adjustments or troubleshooting live issues. Its visual interface makes it easy to understand rule relationships and test configurations.

The AWS CLI is great for production environments where consistency is key. You can automate tasks like updating IP sets or deploying emergency blocks across multiple web ACLs.

Using infrastructure as code tools like CloudFormation or CDK ensures your WAF configuration is documented, version-controlled, and easily reproducible. This approach is particularly useful for compliance and team collaboration.

Many organizations adopt a hybrid approach, combining infrastructure as code for foundational configurations with console access for real-time adjustments. This blend provides flexibility while ensuring long-term stability.

Establish clear guidelines on when to use each method. For example, use the console for immediate security responses but rely on CLI or infrastructure as code for planned updates. This ensures your WAF setup remains both effective and manageable over time.

Troubleshooting and Best Practices

Integrating AWS WAF with App Runner can come with its own set of challenges. Below are some common issues you might face and practical ways to tackle them.

Common Issues and Solutions

Permission errors:
Double-check that your IAM role includes the necessary permissions, such as wafv2:AssociateWebACL, wafv2:DisassociateWebACL, and apprunner:AssociateWebAcl. Without these, you'll run into "access denied" errors when trying to link your web ACL to your App Runner service.

WAFUnavailableEntityException:
This error often pops up when you try to associate a web ACL immediately after creating it. Give it a few minutes before attempting again.

WAFNonexistentItemException:
This error usually signals that your App Runner service isn't in the right state. Make sure your service is running and not stuck in states like CREATE_FAILED, DELETE_FAILED, DELETED, or OPERATION_IN_PROGRESS.

Handling large requests:
If your requests exceed the standard inspection limits, configure your WAF rules with the Continue action for large content types. This allows AWS WAF to inspect the first 8,192 bytes of a request and continue processing if no threats are found.

Source IP filtering for private services:
For private App Runner services, use VPC security groups to manage source IP restrictions instead of relying on WAF.

False positive blocks:
Use the Sampled Requests feature to review traffic that was blocked. This helps identify rules causing false positives. If needed, switch those rules to Count mode temporarily while fine-tuning their conditions.

Addressing these challenges is just the start. Following best practices will help you maintain a secure and compliant setup.

Security and Compliance Best Practices

To keep your integration secure and functional, it's essential to adopt proactive measures:

• Regularly update and test your WAF rules to stay ahead of new threats. Always test changes in a staging environment first to avoid blocking legitimate traffic.
• Use infrastructure-as-code tools for managing your WAF configurations. This approach makes it easier to track changes and roll back updates if something goes wrong.

Conclusion

By integrating AWS WAF with App Runner, you can effectively secure your containerized applications against threats like web exploits, DDoS attacks, and malicious bots. This protection is achieved through a straightforward setup process that strengthens your application's defenses.

The process involves creating a WAF web ACL with specific rules and linking it to your App Runner service using the AWS Console or CLI. This approach not only reduces the load on your containers but also ensures optimal performance by blocking unwanted requests at the edge, preventing unnecessary scaling and keeping costs predictable.

With monitoring tools like CloudWatch and WAF logs, you gain valuable insights into blocked requests and attack patterns, enabling you to fine-tune rules in real time. To stay ahead of evolving threats, regularly update your WAF rules using infrastructure-as-code practices, avoiding configuration drift and maintaining a strong security posture.

This integration is especially suited for applications handling sensitive data, serving public traffic, or requiring strict compliance. By combining App Runner's ease of use with AWS WAF's advanced security features, you can achieve scalable, reliable protection for modern applications.

FAQs

How can I set up AWS WAF to protect my App Runner service without disrupting legitimate traffic?

To safeguard your App Runner service using AWS WAF without disrupting genuine traffic, start by studying your application's typical traffic patterns. Leveraging managed rule groups is a great starting point since they provide a solid base and reduce the chances of false positives. Begin with less restrictive rules and adjust them gradually as you observe how your traffic behaves.

Keep a close eye on WAF logs and key metrics to spot and resolve any false positives. Testing your rules in a staging environment before rolling them out to production is a smart way to confirm they function as expected. By continuously refining and adjusting your rules, you can strike the right balance between robust security and a seamless user experience.

What should I consider when integrating AWS WAF with private App Runner services, and how is it different from public services?

When working with AWS WAF and private App Runner services, managing traffic becomes a bit different. Unlike public App Runner services, where web ACLs in WAF can directly block malicious traffic, private endpoints require a different approach. Since WAF source IP rules don’t support private endpoints, you’ll need to rely on security group rules to control access.

For private services, it’s crucial to configure security groups to allow traffic only from trusted IP ranges or CIDR blocks. This ensures that your endpoints remain secure. On the other hand, public App Runner services have a more straightforward setup, as WAF can directly filter out web exploits without additional configurations. The key difference here is the extra step needed to safeguard private services effectively.

How can I automate associating and managing AWS WAF web ACLs with App Runner services, and why is it beneficial?

You can set up automated management of AWS WAF web ACLs for AWS App Runner services by leveraging infrastructure-as-code tools like AWS CloudFormation or Terraform. These tools let you define and manage WAF configurations programmatically, using resources such as AWS::WAFv2::WebACLAssociation.

By automating this process, you ensure security policies are applied consistently while cutting down on manual work. This approach streamlines updates, reduces the chances of configuration mistakes, and boosts the overall reliability of your deployments - all while saving valuable time.

Related Blog Posts

• How Automation Rules Work in AWS Security Hub
• AWS App Mesh for Service Mesh Integration
• AWS WAF and Shield Pricing Explained
• CloudFront DDoS Protection: AWS Shield Best Practices