This article explains why revert-to-preferred and revert-to-reserved processes do not apply to stateful Elastigroup configurations. Knowing this helps you plan how instance replacement works when you use persistent storage.

Why revert to preferred does not apply to stateful groups

Stateful groups use persistent root or data volumes. Reverting instances to preferred or reserved options requires a recycle action. Recycling causes downtime because the instance must be terminated and relaunched. For this reason, Elastigroup does not apply revert-to-preferred or revert-to-reserved logic to stateful groups.

How revert to preferred works for non-stateful groups

When a group is not stateful, Elastigroup can replace instances that are running in non-preferred markets with instances from preferred markets. This happens when preferred markets become available again.

Preferred markets are based on spot market scoring. Spot market scoring evaluates availability and predictability by examining real-time and historical supply-and-demand signals. Elastigroup uses this scoring to identify when replacing an instance improves stability and cost efficiency.

Maintenance window considerations

If your group falls back to on-demand instances because spot markets are unavailable, you can use a maintenance window to control when Elastigroup replaces on-demand instances with spot instances. Maintenance window options include:

• Once available
  Elastigroup replaces on-demand instances with spot instances as soon as a selected spot market becomes available.

• Never
  Elastigroup does not replace on-demand instances. A group may continue running entirely on on-demand instances with this option.

• Custom
  Elastigroup replaces on-demand instances only within the time ranges you specify. You can define multiple time windows across different days.

These settings apply only to non-stateful groups because the replacement process requires recycling.