Pre-Scale GCP MIGs and Azure VMSS for a Product Launch

For a launch, the question is not only when to add capacity but how long to hold it. Google Cloud scaling schedules and Azure fixed-date autoscale profiles both take a start and an end, so the extra floor disappears on its own. This guide sets up a three-day window starting at 07:00 Pacific on Tuesday 13 October 2026, two hours before an announcement at 09:00.

Google Cloud: a scaling schedule on the MIG

Prerequisites. The MIG must already have an autoscaler. Adding a schedule to it needs compute.autoscalers.update on the project (creating a new autoscaler with a schedule needs compute.autoscalers.create plus compute.instanceGroupManagers.use on the MIG).

Check the ceiling first. The autoscaler never creates more VMs than the MIG’s configured maximum, however large the schedule’s minimum. Raise --max-num-replicas in the same command if needed.

gcloud compute instance-groups managed update-autoscaling launch-api-mig \
  --region=us-west1 \
  --max-num-replicas=60 \
  --set-schedule=launch-oct26 \
  --schedule-cron="0 7 13 10 * 2026" \
  --schedule-duration-sec=259200 \
  --schedule-time-zone="America/Los_Angeles" \
  --schedule-min-required-replicas=24 \
  --schedule-description="Launch window, 3 days"

The sixth cron field is the year, which makes this a one-time schedule. Duration is in seconds (259,200 is 72 hours), and the minimum allowed duration is 5 minutes. While the schedule is active the autoscaler keeps at least 24 VMs; demand-based scaling can still go higher, up to the maximum. Starting two hours early covers VM start and application initialisation, which is the case Google recommends scaling schedules for.

A MIG can hold up to 128 scaling schedules. After the window, this one shows as OBSOLETE; Google suggests deleting obsolete schedules you will not run again.

Verify with gcloud compute instance-groups managed describe launch-api-mig --region=us-west1, which lists each scaling schedule and its status.

Postpone or call it off by disabling the schedule:

gcloud compute instance-groups managed update-autoscaling launch-api-mig \
  --region=us-west1 --disable-schedule=launch-oct26

Azure: a fixed-date profile on the VMSS autoscale setting

Prerequisites. The scale set needs an autoscale setting (az monitor autoscale create if it has none), and you need Microsoft.Insights/AutoscaleSettings/Write on it.

Find the setting’s name, then add a fixed-date profile that copies the default profile’s rules but raises the instance limits:

az monitor autoscale list -g rg-launch --query "[].name" -o tsv

az monitor autoscale profile create -g rg-launch \
  --autoscale-name launch-vmss-autoscale \
  --name launch-oct26 \
  --copy-rules default \
  --min-count 12 --count 12 --max-count 40 \
  --start "2026-10-13 07:00:00" --end "2026-10-16 07:00:00" \
  --timezone "Pacific Standard Time"

Azure time zones here are Windows names; az monitor autoscale profile list-timezones shows the accepted values. Azure evaluates fixed-date profiles first, then recurring profiles, then the default, and uses only the first that matches, so the launch profile overrides everything for its three days and the default profile takes over again once it ends. The default profile cannot be deleted.

Verify with az monitor autoscale profile list -g rg-launch --autoscale-name launch-vmss-autoscale. Remove it early with az monitor autoscale profile delete -g rg-launch --autoscale-name launch-vmss-autoscale --name launch-oct26.

What neither cloud does for you

Neither mechanism touches databases, caches or third-party quotas. Scale those separately and before the window opens.

Launch windows in ZopNight

ZopNight’s Event Readiness creates the same native objects, GCP scalingSchedules and an Azure fixed-date autoscale profile, along with AWS ASG and ECS scheduled actions, from one event definition with a capacity multiplier or an expected request count. It records the original capacity and restores it on completion or cancellation, and shows an estimated cost and a database impact preview first; databases stay monitor-only. See pre-scaling for the concept and VMSS scheduling for the scale set specifics. For a fixed-date retail peak on AWS, see pre-scaling for Black Friday.