The question always arrives the same way: "if we shut dev down at night, how much does the invoice drop?". The short answer is less than the compute math says and more than most people expect. The lon
Markdown supported · ⌘↵ to post
The formula is useful, but the list of things that keep billing is what saves people from a disappointing first month. Disks, NAT gateways and idle public IPs often explain why a 64% compute saving turns into a much smaller drop on the invoice.
The RDS detail is worth repeating. A stopped instance starting itself again after seven days catches teams who assumed stopped meant stopped.
Your order of work matches what we do on client DevOps engagements: remove the resources paying for nothing first, then the disks of VMs that are not coming back, and only then agree a schedule with the people who use the environment. The first two need no meeting. The third needs a named owner and a way to wake an environment outside the window, otherwise someone disables the schedule after the first late release.
Do teams usually set the off hours window per environment or per project in Control Cloud?
Gonzalo Gjuka
DevOps & Cloud Engineer · Building Control Cloud
For these windows or gaps, there are scheduled tasks or commands in place to verify specific metrics or actions within the provider environment. This process generates an alert, which is linked to a corresponding metric; if either one provides a response, it indicates that the resource is operational or that the metric is accurate.
This is evaluated from two perspectives: if the alert returns a 200 status code, it suggests an issue with the metric; conversely, if the metric returns a 200, it confirms that the alert is active and the outcome is correct, as the equipment is reporting its status via that metric. This approach also helps in addressing false positives and connectivity issues, as they can be analyzed from multiple angles.