EC2 instances
Stopped during the nap and started on wake; they stay registered in their target group.
Early access · AWS
Dormeto stops the workloads behind your Application Load Balancer when nobody uses them, and starts them again just in time when a real request arrives. Once awake, traffic goes straight to your application: Dormeto stays out of the request path.
Ask for early access How it works
The router watches the request count of each workload on your load balancer. After an idle window (15 minutes by default), the workload is due for a nap.
The listener rule switches to a small Lambda function, the waker, and the backends stop. A request during the switch cancels the nap, so nobody is caught half-way.
The first real request starts the backends. The visitor is held while they start and redirected as soon as the application answers, or sees a page that reloads by itself. The rule then switches back to your app.
Resources tagged dormeto:workload behind the load balancer rule of a workload.
Stopped during the nap and started on wake; they stay registered in their target group.
Scaled to zero with their scaling processes suspended, then restored to their size. With a warm pool in Stopped state, a wake restarts instances instead of launching new ones.
Fargate or EC2: desired count to zero with Application Auto Scaling suspended, restored on wake.
Databases nap with their application: stopped after it, started and awaited before it. A database that AWS restarts after seven days is stopped again.
On a public hostname, scanners show up within minutes of a new certificate. Waking for them would cancel the savings.
HEAD requests, bots, crawlers, monitors and internet scanners get the waiting page, never a
wake, and neither do well-known scanner paths such as /.env or /wp-login.php.
Ignore source addresses and ranges, URL paths, user agents or request headers, for every workload or for one.
Only the waiting page's own script wakes the workload: scanners that do not run JavaScript never do. API clients wake it with a header or a wake rule.
Public lists of scanner networks and cloud ranges, refreshed daily. Listed sources wake through the waiting page only.
An admin page per workload shows its state, the ignored requests per reason and the wakes per trigger. The same counts are available as CloudWatch metrics.
Time from the first request to the first answer of the application, on our test
workloads in eu-west-1, with our end-to-end test tool.
| Workload | Wake time |
|---|---|
| ECS service on Fargate (0.25 vCPU) | 29 to 52 s |
| EC2 instance (t4g.nano) | 35 to 42 s |
| Auto Scaling group with a stopped warm pool | 35 s |
| Fargate service and PostgreSQL (db.t4g.micro) | 6 to 14 min |
Your application's boot time adds to these figures. Visitors wait on a page that reloads by itself; for long wakes such as databases, that page is what they see.
Only while a workload is asleep or waking. Awake, the load balancer rule forwards every request to your application and the waker is not invoked at all.
Their request is held for up to a minute, then redirected to the same URL as soon as the application answers. If the wake takes longer, they get a waiting page that reloads by itself. API clients get a JSON answer with a retry delay.
Compute stops. The load balancer, storage (EBS volumes, database storage, warm pool volumes) and a few Lambda invocations keep running.
AWS, with Application Load Balancers. Other clouds are not supported today.
Dormeto is in early access: the router runs on AWS today and a console to connect your accounts is being built. Write to contact@dormeto.com.