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.

An oil and gas company modernised its inherited EC2 scheduling service. Activity expanded from one account to multiple accounts in February 2025, with broader rollout in March 2025 and continued fleet growth. During 1 March 2025–30 September 2026, cumulative on-demand-equivalent compute value reached about US$699,000, with about US$360,000 projected annually.

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.

Financial value

Measure	Period or value
Multi-account operation	From February 2025
Broader rollout	March 2025
Savings window	1 March 2025–30 September 2026 (19 months)
Cumulative compute value	Approximately US$699,000
Full-August compute value	Approximately US$29,000
Annual projection	Approximately US$360,000

The fleet continued growing; today’s footprint is 13 accounts. Cumulative value covers only the savings window, excluding the earlier operating period. Of 1,652,420 total reconstructed stopped hours, 1,404,364 have matching monthly on-demand rates; unmatched hours receive no dollar value. These amounts represent on-demand-equivalent compute value, not measured net invoice reduction.

The annual projection equals the July–September 2026 average monthly value × 12, assuming a similar fleet and operating pattern. Actual bill savings are affected by Savings Plans utilisation.

A stable core

From the end of delivery in March 2025 through 28 September 2026, the rules for evaluating leases and starting or stopping EC2 instances remained unchanged. Instance discovery, cross-account access and encryption policies, CloudFormation templates, StackSets and the deployment pipeline also stayed as delivered.

Later changes were limited to patch-window configuration, six explicit instance exclusions, and exposing start and stop times in API responses. These adjustments let operations adapt within the existing design, while the service’s core logic and architecture remained intact.

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.