Radware vADC Deployment Guide for Azure VMware Solution

Running Radware vADC with Azure VMware Solution (AVS) gives hybrid infrastructure teams a consistent application delivery layer for VMware-hosted workloads. Radware Alteon virtual appliances can provide Layer 4 and Layer 7 load balancing, SSL offload, health monitoring, traffic steering, and application security at the edge of an AVS environment.

The design depends on where the appliance runs and how traffic enters the private cloud. An Azure-native virtual appliance is usually easier to connect to Azure networking services, while an appliance deployed as a workload in AVS can serve applications that require local east-west traffic management. Confirm the current Radware and Microsoft support matrices before selecting a production topology.

A reliable deployment starts with routing, address planning, and management access rather than the appliance wizard. AVS uses VMware vCenter and NSX-T concepts inside Azure, while native Azure resources use virtual networks, subnets, route tables, and network security groups. The integration must account for both networking domains.

Choose The Deployment Architecture

The first pattern places Radware vADC in an Azure VNet that is connected to the AVS private cloud through ExpressRoute. Client traffic reaches the appliance through an Azure public or private frontend, and the appliance forwards requests across the ExpressRoute connection to application servers on AVS segments. This model works well for internet-facing services and centralized ingress.

The second pattern places the virtual appliance inside AVS as a guest workload. It can load balance application servers on one or more NSX-T segments and handle internal traffic without sending every flow through an Azure-native subnet. External access still requires an appropriate Azure and NSX-T route design, and the appliance must be deployed using a Radware-supported VMware image and VM configuration.

A pair of appliances should be used for production availability. The exact HA method, interface count, licensing model, and failover requirements vary by Alteon VA release and platform. Avoid treating an active/standby pair as a substitute for redundant network paths; both instances need dependable management, client-side, and server-side connectivity.

Prepare Azure And AVS Networking

Create separate management, client-facing, and server-facing network segments where the design requires them. In Azure, apply NSGs carefully so that management protocols, health checks, application ports, and HA communication are allowed only from approved sources. In AVS, use dedicated NSX-T segments and gateway firewall rules rather than broad any-to-any access.

Advertise the AVS address ranges to the Azure VNet through the ExpressRoute connection. Azure route tables may need explicit routes for AVS application networks, while AVS and NSX-T must have return paths to client subnets and any Azure-native frontend. Asymmetric routing is a common cause of failed TCP sessions, especially when a firewall or load balancer sees only one direction of a flow.

Reserve static addresses before deployment. Record the appliance management IP, virtual service IPs, backend server addresses, default gateways, DNS resolvers, NTP sources, and HA peer addresses. Do not reuse the AVS management range for application virtual IPs.

Deploy And License The Virtual Appliance

For an Azure-native installation, locate the Radware Alteon VA offer in Azure Marketplace and select the supported image version, VM size, region, resource group, VNet, subnet, and authentication method. Use a dedicated resource group and tag the resources with environment, owner, service, and change identifiers. The selected VM size must meet Radware throughput and interface requirements rather than being chosen solely by CPU count.

For an AVS installation, upload or deploy the Radware-provided VMware package through the supported vCenter workflow. Configure the VM’s virtual hardware, port groups, disk layout, and network adapters according to the release documentation. Do not change NIC order after initial configuration unless the appliance documentation explicitly supports it; interface renumbering can make management access or routing fail.

After the first boot, connect to the management interface and complete the base configuration. Set the hostname, DNS, NTP, administrator credentials, and licensing details. Keep management access on a restricted administrative network. If a golden-image process is part of the operating model, the guidance on golden VM images can help standardize the surrounding VMware and AWS image workflow, but the Radware appliance itself should be distributed using Radware’s supported image process.

Configure Interfaces, Routes, And Services

Map each virtual NIC to its intended network and verify the mapping from the Alteon management interface. Configure VLANs, tagged interfaces, or routed interfaces according to the selected design. In a simple one-arm topology, the appliance and backend servers share a routing domain; in a two-arm topology, client and server traffic use separate interfaces or segments.

Create static routes for AVS application networks, Azure client networks, monitoring systems, and administrative sources. If Azure route tables direct traffic to a network virtual appliance, ensure the next hop and effective routes match the Radware design. In AVS, verify NSX-T gateway routing and distributed firewall rules with a test VM before exposing a service.

Define real servers and server groups, then create virtual services with the required protocol and port. Configure health checks that test application behavior rather than merely checking whether a TCP socket is open. For HTTPS services, import certificates and private keys through the supported secure method, select the intended TLS policy, and decide whether traffic is re-encrypted toward the backend.

Design Area	Azure-Native Appliance	AVS Guest Appliance
Primary placement	Azure VNet subnet	AVS workload segment
Best fit	Centralized ingress and Azure integration	Local AVS east-west load balancing
Main dependency	ExpressRoute reachability to AVS	NSX-T routing and supported VM deployment
Public exposure	Azure frontend or public IP design	Usually requires Azure ingress integration
Key validation	Effective routes and NSGs	Port groups, gateway firewall, and vCenter support
Scaling focus	Azure VM size and NIC limits	AVS VM sizing and cluster capacity

Validate Failover And Application Flow

Test each direction separately: client to virtual IP, virtual IP to backend, backend return traffic, and management access. Use Radware connection statistics alongside Azure Network Watcher, NSX-T traceflow, and packet captures from approved points. A successful ping does not prove that TLS negotiation, persistence, or application headers are functioning.

Validate persistence behavior for applications that maintain sessions. Confirm whether source-IP, cookie, or SSL-session persistence is appropriate, and test the result when a backend is removed. Health checks should mark an unhealthy server out of rotation within the expected interval and restore it only after the application has recovered.

For HA, shut down or isolate the active appliance during a controlled maintenance window. Confirm virtual IP ownership, ARP or neighbor updates, existing connection behavior, DNS implications, and monitoring alerts. Repeat the test from both Azure-native clients and AVS workloads if the service supports both paths.

Operate The Hybrid Load Balancer

Monitor CPU, memory, throughput, concurrent connections, SSL transactions, interface errors, health-check status, and license consumption. Send appliance logs and alerts to the organization’s central monitoring or SIEM platform. Time synchronization is essential for correlating Radware events with Azure, NSX-T, and application logs.

Document every virtual service, backend pool, certificate, route, firewall dependency, and ownership boundary. Store configuration backups securely and test restoration on a scheduled basis. Keep the appliance software, VMware tools where applicable, certificates, and Azure dependencies within approved lifecycle and maintenance windows.

Use these deployment checks before accepting the service:

• Confirm Radware and Microsoft support for the selected image, VM size, and AVS architecture.
• Verify symmetric routing from clients through the virtual service and back to the clients.
• Restrict management access and validate DNS, NTP, licensing, and certificate functions.
• Test backend health checks, persistence, TLS policies, logging, and HA failover.
• Record effective Azure and NSX-T routes, firewall rules, and rollback procedures.

A Radware vADC deployment becomes predictable when the Azure VNet, ExpressRoute connection, AVS segments, and NSX-T policies are designed as one traffic path. Build the environment in a nonproduction subscription or private cloud first, test failure scenarios deliberately, and promote the documented configuration only after application owners verify real transaction flows.