AWS CodeDeploy RESTART Reuses a Revision, but Your Fleet Still Needs a Drain Plan

Restarting a service is operationally simple until a fleet script keeps going after the first batch fails. AWS CodeDeploy’s RESTART mode gives EC2 and on-premises operators a deployment record and health controls for reapplying the last successful revision. The useful distinction is that it manages a restart through the deployment system; it does not make restarting a live process impact-free.

A restart becomes a deployment operation

Before this mode, teams could redeploy the current revision to trigger lifecycle scripts or run their own restart logic outside CodeDeploy. RESTART lets a caller set deploymentMode to RESTART and omit the revision. CodeDeploy resolves the deployment group’s last successful revision, creates a normal deployment record and runs the AppSpec lifecycle. The deployment configuration still controls the batch size; service hooks, configured CloudWatch alarms and automatic rollback behavior still apply. ^{[1] [2]}

The agent determines whether the revision can be reused locally. Version 2.1.0 and later can use the archive from the previous successful deployment; if that copy is unavailable or invalid, the agent falls back to downloading the same revision. The process remains a workflow through ApplicationStop, DownloadBundle, BeforeInstall, Install, AfterInstall, ApplicationStart and ValidateService. That means RESTART is useful for reapplying managed files and restarting services, not merely sending a process signal. ^{[1] [3]}

AWS reported a 6.14x peak speedup in its feature tests, using m5.large instances, a 1 GB revision and fleets of 10, 50 or 100 hosts. The blog reports seven runs per scenario, discarding the fastest and slowest and reporting the median of five. It also says results combined local archive reuse with traffic-control steps omitted, and are not predictive of other applications. For teams considering the feature, the real lesson is that removing transfer and repeated traffic-control work can cut time; the measured gain depends on revision size, load-balancer setup, fleet size, agent version, hooks and batch policy. ^[1]

The traffic caveat changes the runbook

In RESTART mode, CodeDeploy does not execute the load-balancer BlockTraffic and AllowTraffic steps. A host stays registered while its application stops and starts. AWS explicitly recommends making ApplicationStop stop accepting new work and drain in-flight work before the process exits. For request-serving services, decide how much capacity can disappear in each wave; for queue workers, make sure shutdown safely completes or releases active jobs. ^[1]

ValidateService still runs before CodeDeploy considers the host healthy, and the deployment stops when the deployment breaches the minimum-healthy-host requirement, a lifecycle hook fails, or a monitored alarm enters ALARM. That gives operators a bounded restart path, but it relies on checks that represent the service’s real readiness. A process that starts while its queue consumer is stuck can pass a weak check and still fail its job contract. ^{[1] [4]}

Be especially careful with incident-time alarm overrides. AWS notes that an already-ALARM state does not prevent the deployment request from being created; CodeDeploy stops when it observes the alarm. A documented override can disable the deployment-group alarms for that run, but it requires additional permission and an alternate health signal approved by the incident process. That override is a deliberate safety tradeoff, not a routine way to get past a red dashboard. ^[1]

Check eligibility before wiring automation

RESTART applies only to EC2 and on-premises in-place deployment groups. It is not available for ECS or Lambda deployments. The group must have a successful revision to reapply. Do not send a revision, s3Location, gitHubLocation or deploymentRevisions field, and do not combine it with updateOutdatedInstancesOnly; the API rejects these combinations. Older agents can still restart but may download the revision rather than reuse the local copy. ^{[2] [3]}

Before connecting a CloudWatch alarm to EventBridge and Lambda for automated restarts, verify that the alarm indicates a condition this action can safely address. Memory growth might justify recycling a stateless JVM worker; a latency spike caused by a dependency outage probably does not. Add deduplication or cooldown so repeated alarm events do not create overlapping restart deployments. Make the automation observable by recording the deployment ID and monitoring its lifecycle state. AWS proposes this alarm-to-EventBridge-to-Lambda pattern, while the cooldown and action-selection guidance here are operational safeguards to apply around it. ^[1]

Related reading: how to deploy multi-request functions on AWS Lambda and how to compare storage paths for Vercel applications.

Use RESTART when it restores a known revision

The best fit is a controlled reapplication: a runtime configuration change needs the managed service to restart, a process must be recycled, or operators need to bring drifted files back to the last successful revision. It is not a substitute for a new software release, a load-balancer drain plan or a diagnostic runbook. Use a small batch first, verify that ValidateService observes the properties users need, and keep an eye on the host’s traffic and application logs while each wave proceeds. CodeDeploy adds discipline around a common task; teams still own the safety of the task they initiate.