Event Readiness Playbook: Pre-Scaling for Known Spikes

Event readiness is the work of making sure infrastructure can absorb a traffic spike whose date you already know: a sale, a product launch, a ticket release, a marketing campaign, a load test. Its central technique is pre-scaling, which means raising capacity ahead of the event with a scheduled action and lowering it again afterwards, instead of relying on reactive autoscaling to catch up once the load has arrived.

Reactive policies respond after a metric moves, and new instances then need time to boot and warm up. Forecast-based predictive scaling does not help either: Google Cloud states that its predictive autoscaler does not predict one-time events, and the AWS and Azure forecasters learn from daily and weekly patterns in recent history. A one-off event needs an explicit instruction.

Step 1: size the event

Start from evidence. If a similar event happened before, use its peak relative to a normal day as a multiplier. If not, a load test that measures requests per instance at acceptable latency gives you a per-instance ceiling, and expected peak requests divided by that ceiling gives an instance count. Add headroom for instance failure and for traffic that arrives before the forecast.

Step 2: pre-scale with the provider’s scheduler

Each cloud has a native way to set capacity at a time, which removes the need for a person or a cron box to be awake at the right moment:

• AWS Auto Scaling groups: a scheduled action sets desired, minimum, and maximum capacity at a start time, one-off or recurring with a cron expression and time zone. Names must be unique per group, two actions cannot share the same start time, and a group can hold up to 125 scheduled actions.
• Amazon ECS services: Application Auto Scaling supports scheduled actions that change a service’s capacity at a set time.
• Google Cloud MIGs: a scaling schedule sets a minimum VM count for a start time and duration (minimum 5 minutes), once or recurring, with a time zone. A MIG can have up to 128 schedules; when several overlap, the autoscaler uses the greatest required count.
• Azure VMSS: a fixed date and time autoscale profile applies its own capacity limits and rules for a specific window; the default profile applies when no other profile matches.

Raise the minimum, not just the desired count, so reactive scale-in cannot undo the pre-scale while traffic is still low before the event starts. Keep the maximum high enough for reactive policies to add more if the forecast was wrong.

Step 3: check what does not autoscale

Stateless compute scales out; databases usually do not. Connection limits, instance class, and read replicas need a separate plan, and changing them is typically a change-managed operation owned by the database team. Work out whether the scaled-out fleet’s connection pools fit within the database’s limits before the day, not during it.

Step 4: roll back deliberately

Capture the original minimum, maximum, and desired values before changing anything, and schedule the return. A pre-scale with no scheduled end is how a one-day sale becomes a week of oversized capacity.

How ZopNight runs this

ZopNight’s Event Readiness feature is a wizard for exactly this flow. You size an event by a multiplier over baseline or by expected requests, and it computes scaled min, max, and desired per target, which an admin can override. Supported scaling targets are AWS ASGs, AWS ECS services, GCP MIGs, and Azure VMSS, and it writes the providers’ own scheduled actions: PutScheduledUpdateGroupAction, ECS PutScheduledAction, GCP scalingSchedules, and Azure fixed date profiles. Databases can be attached as monitor-only targets that get sizing guidance such as connection-pool math, and ZopNight never modifies them. The original capacity is snapshotted when the event is scheduled and restored on completion or cancel, and a readiness score combines current capacity, autoscaler policy posture, and recent activity-log signal. For the underlying policy choices see autoscaling fundamentals and capacity planning.