Planificateur d'instances

Pourquoi l'utiliser

Les serveurs de développement, de test et de préparation sont souvent utilisés uniquement pendant les heures de travail, mais ils fonctionnent (et sont facturés) toutes les 168 heures de la semaine. Un serveur qui fonctionne du lundi au vendredi, de 8h00 à 19h00, exécute 55 de ces heures, donc environ les deux tiers de son coût de calcul sont évitables. La page montre les économies pour vos propres serveurs et ne s'appuie pas sur une réclamation générale.

La seule autorisation d'écriture et comment la désactiver

Créer un planning

A schedule is a named set of hours, such as “Weekdays 08:00-19:00”. You make it once and apply it to any number of servers, directly or through a tag policy. Changing the schedule changes everything that follows it.

Switch a schedule off on its card to pause every server that follows it, and switch it on to resume. Servers are left running while it is paused. To stop scheduling one server, open it and choose Remove schedule; the server is left in whatever state it is in.

Que se passe-t-il ensuite

Un travail s'exécute every 30 minutes. Pour chaque planification activée, il détermine, en utilisant le fuseau horaire, si le serveur doit être en cours d'exécution ou arrêté en ce moment, le compare à l'état réel et le démarre ou l'arrête s'ils diffèrent. Because it checks the desired state every 30 minutes rather than firing at an exact minute, a missed run corrects itself on the next one. The practical effect: a start or stop happens within 30 minutes after the time you set.

Différents types de cibles

Comment lire la page

Schedule by tag

A tag policy says “everything tagged env=dev follows Weekdays 08:00-19:00”. Open the Tag policies tab and choose New tag policy: name it, pick the tag key and whether the value must equal or start with your text (leave the value empty to match any value), choose the schedule and the clouds. The preview lists exactly what it would schedule and what it would skip, with the reason. Saving creates ordinary schedules for the matching resources, so they appear in the list marked with the policy name and behave like any other schedule.

• Order matters. Policies are numbered; if several match a resource, the first one wins. Use the arrows to move a policy up or down.
• Tag keys and values are not case sensitive. A bad value (a date that is not a date, an unknown timezone, only one of the two date tags) is ignored and flagged on the page, so a typo never schedules the wrong thing.
• New and re-tagged resources are picked up on the next check after discovery. A resource that loses its tag is released, and started again first if the scheduler had stopped it.
• A schedule you made by hand on a resource always wins; a policy never changes it (a tag stop window is still added to it).
• Pausing a schedule pauses the policies that use it, and the policy shows Schedule paused. A schedule that a policy or server uses cannot be deleted.
• Resources that cannot be scheduled (group members, Kubernetes nodes, databases the provider cannot stop, connections without the scheduler permission) are skipped, and the preview says why.
• Exclude from policy on a resource stops the policy managing it. Deleting a policy removes its schedules and starts anything it had stopped.
• Saving a policy changes nothing in your cloud by itself. The next scheduler check does, and it stops anything outside the window at that moment.

Stop dates and public holidays

Besides its weekly schedule, a VM, scaling group or database can have any number of stop dates: whole days it stays stopped, such as a year-end shutdown or the public holidays of the office’s country. Open the resource, then Open calendarunder the schedule. Click the first and last day, add an optional label, and Add dates; Save stop dates stores them.

• The days are in the schedule’s timezone, first and last day included. On those days the target is stopped whatever the weekly schedule says; on every other day the weekly schedule applies.
• A target with no weekly schedule can have stop dates only: it runs outside them and is stopped inside them.
• The calendar suggests the public holidays of the country the timezone belongs to (for example Europe/London → United Kingdom, England). Change the country or region, tick the holidays you want, or add all the upcoming ones. A holiday that falls on a day the weekly schedule is already off changes nothing.
• Dates that come from cg-stop-from / cg-stop-to tags show as “from tags” and cannot be edited in the calendar; change the tag instead.
• Stop dates that have passed are removed automatically. Holiday data comes from an open-source holiday library and can differ from your company’s own calendar, so check the list before saving.
• Stop dates stop the target at the first scheduler check on the first day (which may be a few minutes after midnight) and start it again at the check after the last day ends, if the weekly schedule says it should be running.

Resources that look like production

A resource whose name contains the word prod, prd, production ou live (as a word, so “web-prd-01” counts but “product-catalog” does not), or whose env / environnement / stage tag says so, is marked PROD? in red in the list. Before you create or change a schedule or add stop dates for one, a red notice names it and you must tick a box accepting responsibility; the save is refused without it, and the audit log records that you accepted.

• A tag policy that would cover such resources shows the same notice with their names in the preview. Once you accept it, the policy includes production-looking resources; until then it skips them and says why.
• Pausing a policy or removing stop dates needs no acceptance.
• This is a name and tag check, not a guarantee. A production resource with an unrelated name is not flagged, so you stay responsible for what you schedule. Resources scheduled by cg-stop-from / cg-stop-to tags are not checked, because setting the tag in your cloud is the explicit action.

Shutdown warnings and delay links

The scheduler can warn you before it stops something. Under Shutdown warnings (the bell at the top of the Instance Scheduler page), switch warnings on, add one or more email, Slack or Microsoft Teams channels, and choose how far ahead to warn. Each warning names the resource, the stop time in its own timezone, the rule behind it and who created it, with buttons to delay the shutdown by 1 hour, 2 hours, 3 hours or for the rest of the day.

• A button opens a confirmation page and changes nothing until you press confirm there (mail scanners and chat apps open links automatically, so a click alone never applies a delay).
• A delay counts from the planned stop time; “for the day” runs to midnight in the schedule’s timezone. The normal schedule resumes afterwards, and you get another warning before the new stop.
• Warnings are checked each time the scheduler runs (every 30 minutes), so one arrives up to 30 minutes or more ahead, never later than the stop. Choose a longer lead time to be warned earlier.
• The person who created each schedule can also be emailed. For tag policies that is the person who created the policy.
• If many resources stop at once, the first ten get their own warning with delay links; the rest are listed in one summary that links to the page, where you can delay each of them.
• A delay is refused if the target has already stopped. Starting it again is done from the page after signing in.
• Links are signed and expire two hours after the stop time. Anyone who receives a warning can use its links, so every delay is recorded in the audit log as made through a notification link, with the new end time, rather than under a person’s name.

Who created a schedule (audit trail)

Every change is written to the audit log under Settings → Audit log with the person who made it: schedules created, changed, removed or excluded from a policy, stop dates added or removed, manual starts and stops, and tag policies created, edited, paused or deleted. Changes CostGlass makes by itself are recorded with the source System and say why (the tag policy, or the tags on the resource).

• The schedule editor shows how the schedule was set up, who created it and who last changed it.
• Each start or stop in the activity feed ends with the rule that caused it and who or what set that rule up, so a target that was stopped by mistake can be traced to a person, a policy or a tag.
• For schedules that come from cg- tags CostGlass cannot see who set the tag in your cloud. Check your cloud’s own audit log (CloudTrail, Azure Activity Log, Cloud Audit Logs).

Risques et bonnes pratiques

• Databases: a stop ends the compute charge only, connections are dropped, and an application that cannot reconnect after the morning start will fail. Test on one non-critical database first.
• Vérifiez ce qui démarre au démarrage. Un serveur qui nécessite des étapes manuelles après un redémarrage sera en panne le matin.
• Les adresses IP publiques peuvent changer lorsqu'une instance EC2 est arrêtée et démarrée, sauf si vous utilisez une adresse IP Elastic.
• Dites-le à l’équipe. Ajoutez la planification à votre runbook pour que personne ne se demande pourquoi un serveur est éteint.
• Laissez les serveurs de production non planifiés, sauf si vous avez une raison délibérée.
• Préférez les planifications sur les groupes Auto Scaling pour les flottes, afin que la propre mise à l’échelle du groupe ne soit pas perturbée.
• La capacité réservée et les Savings Plans sont payés, que le serveur fonctionne ou non. L'arrêt d'un serveur couvert ne permet pas d'économiser de l'argent sur la partie couverte (voir Engagements d'économies).

Questions fréquemment posées

Guides associés