Configure Alteon for real server auto-scaling with custom scripts

Radware Alteon can sit in front of an EC2 Auto Scaling Group, but the ASG and ADC manage different state. AWS replaces capacity; Alteon needs to know which instances may receive application traffic. Custom scripts bridge those control planes by reconciling a tagged instance set with an Alteon real server group.

This guide uses private EC2 addresses, an Alteon virtual server and service, and Alteon’s supported management interface. It applies to layer 4 and layer 7 pools. Exact REST payloads vary by licensed release, so the script logic is portable while the API adapter must match the device configuration guide.

Model the Alteon and AWS relationship

An Alteon virtual server forwards to a service, the service selects a real server group, and that group contains the EC2 backends. A sound real server auto-scaling design compares desired membership with current membership on every run. It adds missing instances, removes departed instances, and treats both operations as idempotent state changes.

Run reconciliation after scale-out events and on a schedule. Events reduce delay, while scheduled runs recover from a missed webhook, a failed Lambda invocation, or an Alteon restart. For a dedicated pool, use an instance ID as the real server name; for a shared pool, tag ownership so the script never removes a manually managed backend.

Prepare the AWS fleet and Alteon pool

On AWS, attach AlteonGroup and ManagedBy tags through the launch template, then verify that both appear on running instances. Give the script read access to instances and scaling groups, plus only the Alteon permissions needed to change the selected group. Store Alteon credentials in Secrets Manager when the script runs in Lambda.

Create a dedicated Alteon real server group and point the service towards it. Match the backend protocol and port, configure a monitor, and decide whether cookie affinity or another session-persistence method is required. A health endpoint should identify the instance itself instead of returning a generic load-balancer response.

Choose the AWS region around users and data residency. Sydney is ap-southeast-2 and Melbourne is ap-southeast-1; Brisbane and Perth use ap-southeast-4 and ap-southeast-3. Adelaide has no commercial AWS region, so many local workloads anchor in Melbourne. Private instances behind Alteon also avoid Australian public IPv4 address charges and unnecessary internet egress.

Build an idempotent discovery script

Start with an AWS CLI discovery script:

#!/usr/bin/env bash
set -euo pipefail

group="${ALTEON_GROUP:?set ALTEON_GROUP}"
aws ec2 describe-instances \
  --region "${AWS_REGION:-ap-southeast-2}" \
  --filters "Name=tag:AlteonGroup,Values=${group}" \
            "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[].[InstanceId,PrivateIpAddress]' \
  --output tsv

Treat each TSV row as an identity and address. Query Alteon for current members, calculate to_add = desired - current and to_remove = current - desired, then call the Alteon API adapter. Name each added member asg-<instance-id> and set its private IP and backend port. The adapter should apply one change at a time and verify each result.

Wrap the script in Lambda for EventBridge scale events and add a scheduled invocation every five minutes. Use the Lambda execution role for AWS access rather than embedded credentials. The Alteon adapter should support dry-run output, bounded retries, exponential backoff and structured logs.

Change the real server group safely

During scale-out, create the real server, add it to the dedicated group and wait for the Alteon monitor to report it healthy. If the service references the whole group, Alteon’s health state governs whether it receives traffic. For sticky sessions, retain existing affinity until the new instance has warmed its caches.

During scale-in, place the backend into the release’s maintenance or drain state, stop new connections, honour the session and deregistration delays, and then remove it. An EC2 Auto Scaling terminating lifecycle hook can hold instance termination for 300–600 seconds while this sequence completes. Alert on lifecycle hooks that remain incomplete beyond their timeout.

Design health checks for graceful failure

Use TCP monitoring for straightforward layer 4 services. For layer 7, call a lightweight local HTTP endpoint that confirms the application process and its critical local resources. Avoid health checks that depend on a shared database or external API, since one downstream incident could mark every backend unhealthy.

The reconciliation script must fail safe. An authentication error, API timeout, malformed response or unexpectedly empty AWS result should abort removals, retain the previous membership and raise an alert. Alteon can exclude an unreachable backend from traffic without deleting its configuration, separating immediate traffic protection from later membership cleanup.

Deployment and rollback checks

Run the first reconciliation as a controlled change and retain the previous Alteon configuration.

Before deployment

• Confirm launch-template tags reach every running instance.
• Test discovery using read-only IAM permissions and the intended AWS region.
• Verify the health endpoint, backend port and session-affinity behaviour.
• Export the current real server group for comparison.

Pause the integration before restoring the previous configuration during an incident.

During rollback

• Disable EventBridge and scheduled reconciliation triggers.
• Restore the captured real server group through the supported interface.
• Keep the ASG in place while static members regain healthy status.
• Watch 5xx responses, active connections and backend saturation.

Document rollback ownership and approval requirements before the change window. The script should remain paused until the old membership has been confirmed, preventing both controllers from modifying the pool simultaneously.

Observe drift and keep the runbook current

Send script version, desired and current counts, calculated differences, instance IDs and API responses to CloudWatch Logs. Alert on reconciliation age, unhealthy real servers, unexpected membership changes, ASG capacity differences, 5xx rates, connection saturation and lifecycle-hook timeouts. Schedule drift detection even when no scale event appears to have occurred.

Australian operations teams commonly call the change a “cut-over” and refer to “flicking traffic” during a handover; define those terms precisely in the runbook. Record timestamps in UTC because Perth has no daylight-saving changes while Sydney, Melbourne and Canberra do. Local Radware support is often purchased through an Australian reseller or distributor, so confirm whether the contract provides 24x7 engineering coverage, local business-hours coverage and the required AUD-denominated response terms.