Everything a production scale group needs
The Scaler service watches your policy and manages the node pool — you keep building.
Elastic policies
Scale on CPU by default, or on memory, network and disk I/O metrics. Set add/remove thresholds, watch period and cooldown — the Scaler even auto-creates the matching scale-down rule for your scale-up threshold.
Scheduled policies
Know your peak hours? Cron-based upscale and downscale recurrences pre-warm capacity before traffic arrives and release it after — and you can combine scheduled with elastic in one group.
Custom metrics
Publish any attribute — queue depth, requests per second, inference backlog — via the OneGate endpoint. The Scaler averages it across the group and scales when your threshold is crossed.
Load balancer native
Attach the group as an Auto Scale Group backend on an E2E Application Load Balancer. New nodes are listed and terminated nodes de-listed automatically.
Encrypted at rest
Optional LUKS full-disk encryption (aes-xts-plain64, 512-bit key) applied automatically to every node the Scaler launches.
Full observability
CPU, memory and disk graphs per group, audit logs of every Scaler state transition, and an activity timeline of every resize, policy update and attach/detach — with who did it and whether it succeeded.
How it works
From saved image to self-managing fleet in four steps.
Bake a saved image
Save an image of a node configured to start your application at boot. Every node the Scaler launches boots from it, ready to serve.
Pick a plan & limits
Choose a compute plan (independent of the image's original plan) and set minimum, maximum and desired node counts.
Define the policy
Elastic thresholds, a cron schedule, or both. Add VPC, static public IP, encryption and security groups at creation time.
Attach your LB
Front the group with a load balancer as the stable entry point, then watch the monitoring tab as the Scaler does the rest.
Scaling policy options
Three policy types cover reactive, predictable, and hybrid workloads.
| Policy type | Trigger | Best for | Key parameters |
|---|---|---|---|
| Elastic — Default | CPU utilization crosses your add/remove thresholds | Web apps and APIs with variable traffic | Thresholds & operators, watch period (default 3), period duration (default 10), cooldown (default 150s) |
| Elastic — Custom | Any metric you publish (MEMORY, NETTX, NETRX, disk IOPS, or your own attribute) | Queue workers, batch inference, I/O-bound services | Policy parameter name, node utilization thresholds, scaling period policy |
| Scheduled | Cron recurrence at fixed times | Predictable peaks — business hours, weekend sales, nightly batch jobs | Upscale/downscale recurrence and node cardinality |
| Elastic + Scheduled | Both of the above together | Predictable baseline with unpredictable spikes on top | All parameters of both policies in one scale group |
Portal defaults: minimum 2 nodes, maximum 5, hard cap 50 per scale group. Group nodes are billed hourly from launch to termination.
Built for spiky, bursty, real-world workloads
If your load chart looks like a heartbeat, stop paying for the peaks 24/7.
Traffic spikes
Flash sales, campaign launches, exam-result days. Elastic CPU policies add nodes within your watch period and shed them in cooldown — behind one stable load balancer IP.
Batch inference
Publish queue depth as a custom metric and let the group grow with the backlog. Pair with GPU nodes or TIR endpoints for model serving that scales itself.
Predictable cycles
Scheduled cron policies pre-warm capacity before 9am and wind it down at midnight — no metric lag, no cold starts, no idle burn.
Frequently Asked Questions
Everything you need to know about Auto Scaling.
Auto Scaling
A scale group is a pool of identical compute nodes managed by E2E's Scaler service. You define the saved image nodes boot from, the plan they run on, minimum/maximum/desired counts, and the policy that decides when nodes are added or removed.
CPU is the default. Without any scripting, the platform also reports MEMORY, NETTX, NETRX, DISKWRIOPS, DISKRDIOPS and DISKWRBYTES. For anything else — request rate, queue depth, GPU backlog — publish a custom attribute via the OneGate endpoint and reference it in a custom policy.
From the load balancer side: add the scale group as an Auto Scale Group backend on an Application Load Balancer. The LB then tracks the pool automatically as the Scaler adds and removes nodes.
Stop sets the desired count to zero, removes the nodes and pauses billing, while your image, plan and policy settings are retained. Start returns the group to Running with desired = minimum. Resize lets you set the active count anywhere between min and max.
Yes — enable encryption at creation time and every node the Scaler launches gets LUKS full-disk encryption (aes-xts-plain64, 512-bit key). Note it can only be enabled when the group is created.
Stop capacity-planning by hand
Launch a scale group in minutes.