App Runner availability: AWS stopped accepting new App Runner customers on April 30, 2026. Existing customers can continue using the service, including creating new resources. AWS does not plan new features and recommends Amazon ECS Express Mode when migrating. This guide is for teams that already use App Runner. See AWS's availability notice and migration guidance.

AWS WAF can inspect HTTP and HTTPS requests to an App Runner service, then allow or block them according to a web access control list (web ACL). It helps filter web exploits and unwanted request patterns, but it does not guarantee that an application will withstand every attack. This walkthrough covers regional setup, association, testing, and limits for public and private services.

Key takeaways

  • Create a Regional web ACL in the same AWS Region as the App Runner service. A service can have one web ACL associated at a time.
  • App Runner supports WAF associations for public and private services. For private services, AWS does not forward the original source IP to WAF, so source-IP rules do not work as intended.
  • WAF evaluates rules from the lowest numeric priority upward. Allow and Block stop evaluation; Count records a match and continues.
  • WAF inspects up to 16 KB of an App Runner request body by default. You can raise this to 64 KB, with additional charges above the default. Bytes beyond the configured limit are not inspected.
  • Standard AWS WAF charges apply. AWS does not add a separate fee for associating WAF with App Runner.

Prerequisites for integration

Use an existing App Runner service and an AWS identity with permission to manage the web ACL and its association. Confirm the service Region first: AWS WAF and the App Runner service must be in the same Region.

IAM permissions

The CLI discovery commands below need apprunner:ListServices and wafv2:ListWebACLs. The association call needs wafv2:AssociateWebACL permission on the regional web ACL and apprunner:AssociateWebAcl permission on the App Runner service. The verification call also needs wafv2:GetWebACLForResource, wafv2:GetWebACL, and apprunner:DescribeWebAclForService. Creating or editing the web ACL and its rules requires additional WAF permissions.

AWS documents the full integration permission set in its App Runner WAF permissions guide. The apprunner: web ACL actions there are IAM permissions; they are not App Runner CLI commands.

Regional support and service access

App Runner is a regional WAF resource. Create the web ACL with Regional scope in the service's Region; a CloudFront-scoped web ACL cannot be associated with an App Runner service. You can associate a web ACL with more than one supported resource, but each App Runner service can have only one web ACL.

Create and configure a web ACL

In the AWS WAF console, create a web ACL for regional resources and choose the same Region as your App Runner service. Set a default action that matches your policy: use Allow when rules selectively block unwanted requests, or Block when rules explicitly allow approved traffic. Add only protections that fit the application, such as AWS Managed Rules, IP sets, rate-based rules, or custom request-field matches. Follow AWS's web ACL creation guide.

Set rule order and actions deliberately

WAF evaluates rules in priority order, starting with the lowest number. A matching Allow or Block action ends evaluation for that request. A matching Count action records the match and continues to later rules. Keep this in mind when ordering allowlists, managed rule groups, and custom rules: an early Allow can prevent later protections from seeing the request.

Rate-based rules can limit requests that match configured criteria, but there is no universal threshold that is safe for every service. Set limits from observed traffic, and treat rate rules as one request-control measure rather than a guarantee against denial-of-service attacks. Shield Standard is automatic baseline protection against common network and transport layer DDoS events; WAF filters HTTP and HTTPS requests. Neither guarantees that an application will stay available. Shield Advanced's expanded protection is limited to eligible resource types, and App Runner is not on AWS's current list. For the broader relationship between WAF, Shield, and CloudFront, see our CloudFront and Shield DDoS guide.

Associate the web ACL with App Runner

You can associate an existing web ACL from the App Runner console when creating or updating an existing service, from the AWS WAF console, or with the AWS WAF API. AWS documents all three paths in Managing AWS WAF web ACLs.

By default, App Runner blocks a request if it does not receive a response from AWS WAF. Include this behavior in availability testing.

Associate and verify with the AWS CLI

Use the service ARN returned by list-services and the web ACL ARN returned by list-web-acls. Change the Region to match your service and run the snippets in the same shell:

REGION="us-east-1"

aws apprunner list-services \
  --region "$REGION" \
  --query 'ServiceSummaryList[].{Name:ServiceName,Arn:ServiceArn}' \
  --output table

aws wafv2 list-web-acls \
  --scope REGIONAL \
  --region "$REGION" \
  --query 'WebACLs[].{Name:Name,Id:Id,Arn:ARN}' \
  --output table

In the same shell, replace the two placeholder values below with the ARNs from those command outputs, then associate them:

WEB_ACL_ARN='paste-the-ARN-from-list-web-acls'
APP_RUNNER_SERVICE_ARN='paste-the-ServiceArn-from-list-services'

aws wafv2 associate-web-acl \
  --web-acl-arn "$WEB_ACL_ARN" \
  --resource-arn "$APP_RUNNER_SERVICE_ARN" \
  --region "$REGION"

Confirm the association by retrieving the web ACL for the service:

aws wafv2 get-web-acl-for-resource \
  --resource-arn "$APP_RUNNER_SERVICE_ARN" \
  --region "$REGION"

The App Runner service ARN has this form: arn:aws:apprunner:region:account-id:service/service-name/service-id. The WAF web ACL ARN uses regional/webacl and must name a web ACL in the same Region. See AWS's CLI association and verification examples for the current API syntax.

Public and private services

AWS WAF can be associated with either a public or private App Runner service. For a private service, App Runner does not forward the original request source IP to WAF. As a result, source-IP-based WAF rules do not adhere to their IP conditions; this also affects rate rules or geographic rules that depend on the original source IP. AWS recommends using security group rules on the private endpoint for source-IP or CIDR access controls. WAF rules based on other request details can still be useful, but test their behavior with your service's actual traffic. See AWS's private endpoint guidance.

Test rules before blocking traffic

Start in a test or staging environment. For production, first put new rules or managed-rule overrides in Count mode and review their matches against normal application traffic. Count mode observes matches without blocking them, but an earlier terminating Allow or Block rule can stop later rules from running. Once you understand the effects and have addressed false positives, switch the intended protections to their enforcement actions. AWS provides a testing and tuning workflow.

Understand request body inspection limits

For App Runner, AWS WAF inspects the first 16 KB of a request body by default. You can increase the limit to 32, 48, or 64 KB in the web ACL settings. AWS WAF receives only the portion within the configured limit; if the request is allowed, the full request can still reach your application. Configure each body-inspection rule's oversize handling intentionally: Continue inspects the available bytes, while Match and No match treat an oversized component as a match or non-match without applying the rule's inspection criteria. Higher inspection limits can add cost. See AWS's guidance on oversized request components and body inspection limits.

Monitor requests and costs

Enable the web ACL's CloudWatch metrics and request sampling to review allowed, blocked, and counted traffic. For detailed records, configure WAF logging to CloudWatch Logs, Amazon S3, or Amazon Data Firehose. Logs can contain request data, so set access controls and data-protection or redaction rules for sensitive fields. WAF log delivery and request inspection have charges; check the current AWS WAF pricing before enabling options at scale.

AWS charges standard WAF rates for the web ACL, rules, requests, and optional features. There is no extra fee specific to associating WAF with App Runner. Raising the request-body inspection limit above 16 KB can add per-request charges, and logging has separate charges. For a detailed cost breakdown, see our AWS WAF and Shield pricing guide.

Troubleshoot association errors

  • WAFUnavailableEntityException: A newly created web ACL may need a few seconds to several minutes to propagate before App Runner can use it. Wait, then retry.
  • WAFNonexistentItemException: Check the App Runner service state. Association calls fail for services in states such as CREATE_FAILED, DELETE_FAILED, or DELETED, and while a service is being deleted.
  • Unexpected source-IP matches on a private service: Use private endpoint security groups for source-IP or CIDR restrictions; the original source IP is not forwarded to WAF for private App Runner services.
  • Unexpected blocks: Review sampled requests, WAF metrics, and logs. Put the relevant rule in Count mode while you investigate, then retest before returning it to Block.

Web ACL changes and associations take time to propagate. Verify the resulting association and rule behavior before treating the service as protected.

Conclusion

For existing App Runner customers, AWS WAF adds configurable inspection of incoming HTTP and HTTPS requests. Create a same-Region Regional web ACL, associate it with the service, and use staged Count-mode testing before enforcing rules. Account for private-service source-IP limits, body inspection size and oversize handling, and WAF's role as a request filter rather than a guarantee of DDoS protection.