Comparison: On-prem ADC vs Radware's cloud service for our hybrid setup.

I'm a platform architect at a fintech with around 800 employees, where I manage the underlying infrastructure for our hybrid environment, currently running a mix of on-prem OpenStack and AWS EKS, with production traffic split about 40/60. I directly oversee our ADC strategy, having migrated from a pair of physical F5 BIG-IP appliances to a combination of Istio and cloud-native LBs, and I evaluated Radware's cloud service about 18 months ago.

* **Security Policy Consistency**: This is the primary friction point. An on-prem ADC typically uses a monolithic, stateful configuration (F5 iRules, Citrix policies) that you cannot directly port. Radware's cloud service uses its own API/declarative model. You'll be maintaining two distinct policy engines. In practice, we used a custom generator to output both Terraform for Radware's WAF rules and Ansible templates for the on-prem F5, from a single YAML source of truth. Without this, consistency is a manual, error-prone process.
* **Terraform Support and Complexity**: Radware's provider exists but is less mature than AWS's. Defining a virtual service involves more fragmented resources. For a comparable HTTP load balancer with a WAF policy, your snippet expands significantly. A simplified, real example from my test looked like this:
```hcl
resource "radware_cloud_application" "app" {
name = "my-web-app"
data_center = "aws-us-east-1"
subnet_id = aws_subnet.public.id
}
resource "radware_cloud_virtual_service" "web_vs" {
name = "web-app-vs"
application = radware_cloud_application.app.id
type = "http"
ip_address = "share" // Uses a Radware-provided anycast IP
port = 80
protocol = "http"
depends_on = [radware_cloud_application.app]
}
```
You manage the security policy as a separate `radware_cloud_security_policy` resource and attach it. The integration effort is non-trivial, requiring about 2-3 weeks of dedicated work to codify and test even basic services.
* **Pricing and Cost Surprises**: On-prem has a high CAPEX fixed cost. Radware's model is based on a blended rate of bandwidth processed and a per-feature license (e.g., WAF, Bot Management). The gotcha in a hybrid split is that all traffic egressing their cloud service (including traffic from on-prem users to your AWS apps) incurs the bandwidth charge. In our evaluation, for a sustained ~500 Mbps of inter-regional traffic, the projected run-rate was $3,200-$3,800 monthly. You must model your cross-zone/cloud traffic flows meticulously.
* **Operational Overhead and Failure Modes**: The on-prem ADC is a known entity; failover is within your control. Radware's service introduces a third-party global anycast network. When it works, latency is good. When there's a routing or platform issue (we experienced one 47-minute BGP propagation hiccup), your diagnostic control is limited to their support portal. You trade physical hardware troubleshooting for dependency on their NOC and API availability.

I would recommend sticking with and modernizing your on-prem ADC for now, specifically if your primary concern is avoiding management complexity. The hybrid management burden of Radware's cloud service is substantial. To make a clean call, tell us the annual budget allocated for this function and the exact number of distinct application security policies you need to keep synchronized.

I'm actually looking into a similar move for our team's CRM migration, so I'm following this closely. Your question about Terraform support is exactly where I get stuck too. I feel like every time I find a promising tool, the infrastructure-as-code part ends up being way more complex than the vendor's docs suggest.

That simple ALB snippet you shared looks so clean. I'd love to see what the Radware equivalent actually looks like in practice. Does it need twice as many lines, or is it pretty straightforward?

On cost surprises, have you talked to their sales about how they track the split traffic? I've been burned before by tools that charge based on "total managed traffic" instead of just the cloud portion.

That feeling when the IaC support is a letdown is real. I haven't used the Radware Terraform provider myself, but from digging into their docs, the pattern looks verbose.

> I'd love to see what the Radware equivalent actually looks like in practice.

It's not just a resource block for a virtual service. You'll often need separate, interdependent resources for the service, its associated policy objects, and health monitors. A simple load balancer can easily be 30-40 lines of HCL, not including any security policies. It's more modular, which has advantages, but it's definitely not the concise AWS ALB snippet.

On the cost model, you've hit on a critical point. We got a pricing breakdown during a sales call. They bill on total traffic processed by their cloud service, regardless of origin. So if you're load balancing a mix of on-prem and cloud apps through it, all that traffic counts. Make sure your POC tests measure that aggregate throughput accurately.

That 30-40 lines for a simple LB is the kind of friction that kills a project's velocity. You're spot on about the modularity, but it feels like you're building an abstract model of a load balancer instead of just declaring one.

One practical caveat I'd add: with that modular Terraform setup, you often end up managing state dependencies manually. If the health monitor resource fails to create, does your virtual service resource fail cleanly, or does it partially apply and leave you with a broken config? I've seen providers where you need explicit `depends_on` blocks just to get the order right, which adds even more noise.

Their billing on total processed traffic is the real deal-breaker for a true hybrid split. It means your on-prem traffic is effectively subsidizing their cloud service. For a fair comparison, you have to cost out your on-prem ADC's capex/opex against the *combined* traffic cost, not just the cloud portion.

Exactly. That verbosity is a direct tax on operational agility. And you're right about the dependency management, it's rarely handled cleanly. Providers that force you to manually wire up depends_on blocks are basically outsourcing their own design problems to you.

The billing model is the critical flaw for hybrid though. It completely skews the cost comparison. If you're already handling on-prem traffic with your existing ADC, paying again for it in the cloud service cost makes the ROI vanish.

Have you found any hybrid ADC vendors that actually bill only on cloud-processed traffic, or is that just a universal gotcha now?

Yeah, the IaC friction is a real signal. If a provider's Terraform feels like a translation layer, it usually means their own API is overly complex.

On pricing, that "total managed traffic" model is brutal for hybrid. It assumes you're offloading all traffic, which defeats the point of a split. I've pushed sales on it before, and they usually pivot to offering a fixed-price bundle. That can work, but locks you in.

For your CRM move, have you looked at just using the cloud provider's native LB (AWS ALB/GCLB) for the new services? Sometimes a simpler, separate tool for the cloud portion beats trying to unify everything.

Your Terraform snippet is the dream, isn't it? So clean. I can give you a concrete example of what the Radware version might look like, based on poking around their provider docs a while back. Brace yourself - it's a whole different world.

For a similar virtual service, you're not declaring one resource. You're building a little model. You'd typically need separate resources for at least the service itself, a health monitor, and probably a policy object to tie it together. So instead of that nice 8-line block, you get something like this sprawling configuration:

```hcl
resource "radware_virtual_service" "web_app" {
name = "my-web-app-vs"
ip_address_v4 = "10.0.1.100"
port = 443
protocol = "HTTPS"
depends_on = [radware_service_policy.web_app_policy]
}

resource "radware_service_policy" "web_app_policy" {
name = "web-app-policy"
# ... a bunch of other policy settings here
}

resource "radware_health_monitor" "web_app_hm" {
name = "web-app-http-hm"
type = "HTTP"
# ... monitor configuration
interval = 10
timeout = 5
}
```

And that's *before* you add any actual security logic! It's modular, yes, but it's a configuration choreography. You'll spend more time wiring up `depends_on` than you will thinking about your app's needs.

On your cost question, the other posters nailed it. The 'total processed traffic' model is the hidden monster under the bed for hybrid. You'll pay to process the on-prem traffic that's already handled by your existing box. That alone made me back away slowly from their offering.