Deploy Radware Cloud WAAP for AWS Container Workloads
Containerized applications on AWS can scale quickly, but their public endpoints still require consistent protection. AWS Fargate tasks, Amazon EKS services, and Kubernetes ingress resources may change location as deployments roll, making a static security model difficult to maintain.
Radware Cloud WAAP provides a reverse-proxy layer for web application security, API protection, bot management, and distributed denial-of-service mitigation. The service can inspect traffic before it reaches an AWS load balancer or Kubernetes ingress, while the application remains distributed across containers.
A reliable deployment starts with traffic flow, DNS, certificates, and origin access. Security policies should be tested in detection mode before enforcement so legitimate API calls, health checks, and application workflows are not interrupted.
Design the traffic path first
A typical architecture places Radware Cloud WAAP between the client and an AWS-facing endpoint. Public DNS directs the application hostname to the WAAP service, which evaluates each request and forwards approved traffic to an Application Load Balancer, Network Load Balancer, or another reachable origin.
For Fargate, the origin is commonly an ALB target group associated with an ECS service. The load balancer distributes requests to Fargate tasks without exposing task IP addresses directly. For EKS, the origin may be an ALB created by the AWS Load Balancer Controller, an NLB fronting a Kubernetes Service, or an ingress gateway.
Keep the application hostname stable even when tasks, pods, or load balancer addresses change. The WAAP configuration should point to a durable AWS origin name rather than an individual container address. This separates application scaling from the external security layer.
Prepare AWS and application prerequisites
Before creating the WAAP application, document the public hostnames, URL paths, HTTP methods, API endpoints, expected request sizes, and upstream ports. Include WebSocket or streaming requirements if the workload uses them. Record the health-check path and the response code that indicates a healthy service.
TLS requires particular attention. The certificate presented to users is normally associated with the WAAP hostname, while the connection from Radware to AWS can use a separate certificate on the origin load balancer. Configure end-to-end encryption where possible, validate the origin certificate, and ensure the forwarded host header matches the certificate and virtual host configuration.
The origin must be reachable from Radware’s service. A public load balancer is straightforward but should be restricted so users cannot bypass the WAAP hostname. If the origin is private, verify that the selected Radware connectivity option supports the required AWS VPC design, routing, and firewall rules. Security groups, network ACLs, and route tables must permit only the intended traffic.
Publish a Fargate application behind WAAP
For an ECS service using Fargate, start with a functioning ALB listener and target group. Confirm that the target group health check reaches the container through the correct port and path. The task definition should expose the application port, and the ECS service should register task IPs automatically with the target group.
Create the protected application in the Radware portal using the public DNS name and the ALB DNS name as the origin. Add the required listener ports, TLS settings, and forwarding behavior. If the application relies on the original client address, configure the trusted forwarded-header behavior and update the application or ALB logging pipeline to use the resulting value safely.
After the WAAP hostname is tested, change the Route 53 record to direct users through Radware. Test normal browser requests, authenticated sessions, uploads, API calls, redirects, and failure responses. Then verify that scaling the ECS service replaces tasks without requiring any change to the WAAP configuration.
Protect EKS ingress and services
EKS deployments require a clear decision about the public entry point. With the AWS Load Balancer Controller, an Ingress resource commonly creates an ALB. Radware can use that ALB as the origin while Kubernetes continues to manage routing rules, certificates, and backend services. An alternative is an NLB in front of a Service or ingress controller when TCP-level forwarding is required.
Avoid exposing individual pod addresses to the internet. Pods are ephemeral, and direct exposure bypasses Kubernetes ingress policy, centralized logging, and the WAAP inspection layer. Instead, publish one stable origin and let Kubernetes handle service discovery behind it.
When using multiple hostnames or namespaces, decide whether each application needs a separate WAAP policy or whether shared policy inheritance is appropriate. Kubernetes annotations, ingress classes, and service changes should be tracked alongside the WAAP configuration. A deployment pipeline can validate that a new hostname has both a working origin and an approved security policy before DNS is published.
Compare deployment patterns
| Area | ECS on Fargate | EKS with ALB ingress | EKS with NLB or ingress controller |
|---|---|---|---|
| Typical origin | ECS service behind an ALB | ALB created by AWS Load Balancer Controller | NLB or controller service |
| Scaling model | ECS task replacement and service scaling | Pod scaling and ingress reconciliation | Pod scaling behind a Kubernetes Service |
| WAAP integration point | Stable ALB DNS name | Ingress-associated ALB | Stable NLB or gateway endpoint |
| Main concern | Correct target health checks | Ingress and certificate synchronization | Preserving protocol and client metadata |
| Best fit | Managed container service with HTTP workloads | Kubernetes HTTP and API routing | TCP-aware or specialized ingress designs |
The common operational principle is to keep Radware pointed at a stable AWS endpoint. The container scheduler can replace tasks or pods freely as long as the load balancer continues to present the expected origin interface.
Tune policies without breaking APIs
Begin with monitoring or learning mode. Review blocked requests, triggered rules, false positives, response codes, and unusual request patterns before enabling aggressive enforcement. API clients often send content types, methods, headers, and payloads that differ from browser traffic, so generic web rules may require scoped exceptions.
Define protections around the application’s actual attack surface. Use rate limits for login, password reset, search, and expensive API operations. Apply bot controls to sensitive workflows, and use positive API validation where the application has a stable OpenAPI definition or predictable schema. Keep exceptions narrow by hostname, path, method, parameter, or trusted source.
The WAAP should complement AWS and Kubernetes controls rather than replace them. Use IAM for administrative access, Secrets Manager or another secure store for credentials, Kubernetes RBAC for cluster operations, and security groups for network boundaries. CloudWatch, ALB access logs, container logs, and Radware security events should share a common request identifier when possible.
Validate failover and ongoing operations
Test the protected service from outside the AWS network and confirm that direct origin access is denied or tightly restricted. Check DNS caching, certificate chains, redirects, large requests, WebSockets, CORS behavior, and timeout handling. A successful homepage test is not enough for a production API.
Exercise container scaling, rolling deployments, pod disruption, and an unhealthy target. Confirm that Radware continues forwarding to healthy capacity and that deployment changes do not alter the public security posture. Monitor latency added by the inspection path and establish alert thresholds for origin errors, blocked traffic, and unusual request volume.
Use infrastructure-as-code where practical for Route 53 records, ALB or ingress resources, security groups, and application configuration. Keep WAAP policy changes under the same review process as code changes, with documented owners and rollback steps.
Recommended deployment practices
- Use a stable ALB, NLB, or ingress endpoint as the WAAP origin rather than task or pod IP addresses.
- Enforce TLS from the client to WAAP and from WAAP to the AWS origin.
- Restrict direct origin access so attackers cannot bypass application-layer inspection.
- Start new WAF rules in detection mode and review real API traffic before enforcement.
- Correlate Radware events with AWS load balancer, Kubernetes, and application logs.
A carefully placed Cloud WAAP layer gives Fargate and EKS workloads a consistent public security boundary while preserving the elasticity of containers. Map the request path, configure the origin securely, test real workloads, and then automate policy and DNS changes as part of the deployment process. Begin with one representative service, validate the complete traffic flow, and expand the pattern across the rest of the AWS environment.