EC2 power leasing across 13 AWS accounts

An oil and gas company needed to align non-production EC2 running time with the hours its teams actually needed those machines. A fixed shutdown schedule could reduce idle time, but it also had to accommodate changing work patterns, temporary extensions and maintenance windows.

The organisation already had scheduling logic. Over late 2024 to early 2025, we modernised that inherited logic and integrated it with ServiceNow, a central lease store and deployment across AWS accounts. The work turned existing scheduling capability into a service with a common request path and repeatable account deployment.

By August 2026, automated stops accounted for 57,922 confirmed off-hours. A subset with matching billing rates represented about US$18,000 in on-demand-equivalent compute avoided.

Give teams a way to request running time

The practical problem was balancing availability with idle compute. Development and test machines needed to run when people were using them, while maintenance could require a machine to start outside its normal working hours. An exception also needed an end date, so a temporary requirement would not quietly become permanent.

A “power lease” made those requirements explicit. ServiceNow provided the request interface; AWS held the lease and applied the corresponding power decisions. Lease settings included an expiry, operating hours, a time zone and weekend behaviour. Configured patch windows could override the normal schedule for the relevant environment.

This gave the modernisation a clear purpose: preserve useful scheduling behaviour while connecting it to the organisation’s service workflow and multiple AWS accounts. The engineering work lay in those integrations, the shared data model and the controls around execution.

Central decisions, execution in each account

The delivered architecture put lease information in a central DynamoDB table encrypted with AWS KMS. ServiceNow connected through a private API Gateway API, with Lambda functions handling lease updates and returning instance and lease information.

Each participating account received its own discovery and automation functions. Discovery added eligible instances to the central inventory. The automation ran every five minutes, read the relevant lease information and evaluated the machine’s current state against its schedule and applicable patch window before issuing a start or stop.

That separation gave ServiceNow one integration point while keeping EC2 power actions in the account containing the machine. Cross-account table and key policies supported access to the central store, using organisation conditions and role patterns to define the permitted relationships.

Self-managed CloudFormation StackSets deployed the account resources. A shared deployment definition made it possible to distribute the discovery and enforcement components consistently, alongside the central API and table. Adding an account still required the appropriate deployment permissions and configuration; the architecture provided a repeatable way to do that work.

Controls with a defined scope

The private API restricted the network path into the service, with an API resource policy limiting the permitted source. The central table’s cross-account policy used AWS organisation membership as a boundary, with additional role conditions for writes. KMS protected the table’s data at rest.

For EC2 actions, the automation’s conditional start/stop allow excluded instances tagged Environment=Production. That condition applied to this permission grant. Its effectiveness still depended on accurate tags and the account’s wider permissions; it was not a blanket prohibition on every identity starting or stopping a production machine.

A configurable dry-run mode suppressed EC2 power actions and logged the intended decisions. Lease housekeeping could still write to DynamoDB. That distinction mattered during testing and rollout: a run could leave machines untouched while changing shared lease records.

Teams define operating hours and lease expiry, maintain patch-window exceptions and control which accounts the service can reach.

Scale across a changing fleet

As of 30 September 2026, the central table holds 250 inventoried instance records across 13 accounts. That describes the current inventory, rather than every machine the service has ever managed.

Within the current 13-account scope, the CloudTrail archive records successful automated power actions on 262 distinct EC2 instances in 11 accounts across April–September 2026. There were 19,730 successful actions on individual instances: 12,206 stops and 7,524 starts.

The inventory and activity figures answer different questions. One is a snapshot; the other follows a changing fleet over six months. Monthly instance counts can overlap and should not be added together to infer the number of unique machines.

Zoom outZoom inReset100%Close

The chart counts distinct instances each month; a machine can appear in several months.

What August’s stopped time was worth

In August 2026, the archive contains 3,278 confirmed transitions from running to stopping across 193 instances. Pairing those stops with the next successful start or termination, and capping each interval at month end, yields 57,922 confirmed off-hours.

Of those 193 instances, 156 matched billed running-hour records in AWS Cost and Usage Reports (CUR). Their 50,030 stopped hours correspond to about US$18,000 at their observed public on-demand rates. Those 50,030 hours are the basis of the dollar calculation.

This is on-demand-equivalent compute avoided, not a measured net invoice reduction. Savings Plans cover many of these instances. The other 37 stopped instances had no August running-hour rate and were excluded from the dollar calculation.

The result gives the organisation a concrete measure of stopped compute time, with a financial reference grounded in the machines that actually ran during the month.

An operating capability that still needs ownership

The five-minute automation cycle suits planned availability windows. Teams still need to allow for machine startup and application readiness before work begins. Scheduling also depends on keeping time zones, environment tags and maintenance exceptions aligned with how workloads are used.

The outcome is a service that connects a request for running time to repeatable AWS action across accounts. It builds on an inherited scheduler, gives temporary requirements a defined expiry and produces a measurable record of the compute time affected. Continued value depends on maintaining those operating rules as the fleet changes.

For the architecture and implementation detail, read the technical companion on power leasing across AWS accounts.