<p>got this answer from aws support</p>

<blockquote>
  <p>Hello, </p>
  
  <p>Andrew from AWS Support here.</p>
  
  <p>I understand that you would like to know if there is a way to speed up
  Code Deploy as currently it takes 7 minutes to complete. Please
  correct me if needed.</p>
  
  <p>After examining the link and the Code Deploy environment I can see
  that the step which involves rerouting traffic from the old instance
  to the new instance can potentially be tuned to try and decrease the
  overall deployment time. In addition, using a different deployment
  configuration may also help to decrease the deployment time.</p>
  
  <p>To try and reduce the time taken to perform a blue/green deployment
  edit the health check on the Elastic Load Balancer (ELB). Reduce the
  health check interval from 30 seconds to 5 seconds and reduce the
  response timeout from 20 seconds to the default of 5 seconds [1]. This
  should decrease the time it takes the ELB to check whether an instance
  is healthy and ready to receive traffic. </p>
  
  <p>Another setting that may also help decrease the time it takes to
  deploy is the deployment configuration, set the deployment
  configuration from the currently used "one at a time" to "all at
  once". CodeDeploy "all at once" will at once attempt to deploy to as
  many instances as possible, the application status will be shown as
  succeeded if the application is deployed successfully to one or more
  of the instances. This configuration will also reroute all the traffic
  in the placement group to all instances at once and will succeed if
  the traffic is successfully routed to at least once instance [2]. </p>
  
  <p>To reduce this deployment from 7 to 1 minute will be high unlikely as
  EC2 launches are managed by CodeDeploy, there may be ways to improve
  to EC2 launch times manually but this is not the case when using
  CodeDeploy.   </p>
  
  <p>I hope you find this information useful, if you have any other
  questions or need clarification on anything above please let me know,
  I'd be happy to help</p>
  
  <p>Take care,</p>
  
  <p>References:  [1] Configure Health Checks for Your Classic Load
  Balancer - Health Check Configuration -
  <a href="https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html#health-check-configuration" rel="nofollow noreferrer">https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html#health-check-configuration</a></p>
  
  <p>[2] Working with Deployment Configurations in AWS CodeDeploy  -
  Predefined Deployment Configurations for an EC2/On-Premises Compute
  Platform  -
  <a href="https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html#deployment-configurations-predefined" rel="nofollow noreferrer">https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html#deployment-configurations-predefined</a></p>
  
  <p>Best regards,</p>
  
  <p>Andrew v. Amazon Web Services</p>
</blockquote>

CC BY-SA 4.0
2018-08-06T14:06:45.837Z
2018-08-06T14:06:45.837Z
abbood
<blockquote>
  <p>bitbucket deploy: 45 seconds</p>
</blockquote>

<p>This seems correct. Not sure of your repo size, but if it is hosted outside of your region, that's not out of the ordinary.</p>

<blockquote>
  <p>bitbucket deploy: 45 seconds</p>
</blockquote>

<p>Again, seems correct. Not much room for optimization here. </p>

<blockquote>
  <p>provisioning a new ec2 instance: 3:40 minutes </p>
</blockquote>

<p>What size of instance are you provisioning? Are you provisioning one or more instances? The obvious solution would be to use in place deployment vs blue-green, but I think the extra time is well worth it. If this is for production/staging, I think you are fine. If this is in a testing environment, and you are aiming for quick feed back, you could consider provisioning new instances after a successful blue-green so that, if there is no AMI change, they are ready to go for installation immediately. </p>

<blockquote>
  <p>installing application on replacement instance: 40 seconds</p>
</blockquote>

<p>Nothing to optimize here </p>

<blockquote>
  <p>2 minutes rerouting traffic from old instance to new one *this one is extremely long, if it were done manually it would literally take 10 seconds)</p>
</blockquote>

<p>My guess is that step is performing extra steps that you do not perform when you manually reroute traffic. It's possible that CodeDeploy is performing extra checks to make sure that connections are draining, new connections are established before old ones are closed, and other test/checks. This is probably your best area to optimize, but not at the sacrifice of checks and balances. </p>

<blockquote>
  <p>17 seconds terminating second instance</p>
</blockquote>

<p>Nothing to optimize here.</p>

<p><strong>Summary:</strong>
I don't think it is feasible or worthwhile to attempt to optimize your deployment further. The amount of effort it would take and sacrifices you would need to make in your test and checks far out ways the potential minute or two you would save in my opinion. I also don't think it is possible to achieve a &lt;1 minute deployment. That would average ~15-20 seconds a step, which would require a lot of sacrifices in your deployment strategy.</p>

<p>If your goal is for quick iterations for QA, code testing, integration testing, etc., and you absolutely want sub 1 minute deployments, I recommend creating a Cloud Formation stack with your exact deployment except skipping the blue/green deployment model for an in place deployment model. This way, you can quickly see the results of your code. You should then later run your full suite blue/green deployment after your testing in either another testing environment or your staging environment. </p>

CC BY-SA 4.0
2018-08-02T22:07:54.183Z
2018-08-02T22:07:54.183Z
Preston Martin
<p>Depending on the value of a faster deployment in your situation, some options are:</p>

<ul>
<li><p>Maintain spare capacity in your ECS cluster (either larger instance types, or more smaller ones) to allow for side-by-side deployment of new versions of the service along with the old, so that new <em>tasks</em> can be started without having to provision new <em>instances</em>. This obviously has a dollar cost, but again, depending on the value of rapid deployments to your organization, and the amount of deployments you expect to do per day, it might be worthwhile.</p></li>
<li><p>Use <a href="https://aws.amazon.com/blogs/compute/bluegreen-deployments-with-amazon-ecs/" rel="nofollow noreferrer">multiple sets of target groups for optimal Blue-Green deployments</a>. This still requires extra cluster capacity, and extra work in your pipeline, but you can ensure that once tested, the replacement set of tasks all go live at once (and are fully tested).</p></li>
</ul>

CC BY-SA 4.0
2018-08-11T09:04:58.677Z
2018-08-11T09:04:58.677Z
Dan1701
<p>I got the following setup with AWS code deploy:</p>

<p><a href="https://i.sstatic.net/v5r31.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/v5r31.png" alt="enter image description here"></a></p>

<p>However it takes about 7 minutes from the moment I push a git branch remotely to the moment the deploy is completed. The time is broken down like so:</p>

<ul>
<li>bitbucket deploy: 45 seconds</li>
</ul>

<p><a href="https://i.sstatic.net/HzWfa.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/HzWfa.png" alt="enter image description here"></a></p>

<ul>
<li>provisioning a new EC2 instance: 3:40 minutes</li>
</ul>

<p><a href="https://i.sstatic.net/tzBgQ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/tzBgQ.png" alt="enter image description here"></a></p>

<ul>
<li>installing application on replacement instance: 40 seconds</li>
</ul>

<p><a href="https://i.sstatic.net/ijLab.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ijLab.png" alt="enter image description here"></a></p>

<ul>
<li><p>2 minutes rerouting traffic from old instance to new one *this one is extremely long, if it were done manually it would literally take 10 seconds)</p></li>
<li><p>17 seconds terminating second instance</p></li>
</ul>

<p><a href="https://i.sstatic.net/egJl0.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/egJl0.png" alt="enter image description here"></a></p>

<p>All together it's around 7 minutes.</p>

<p>How can I optimize this? I'm looking to shrink it to below 1 minute.</p>

<aws-codedeploy>
How to optimize blue/green AWS deployments?
abbood
# How to optimize blue/green AWS deployments?

(Asked by: username_0 on 2018-08-02)

I got the following setup with AWS code deploy:

[![enter image description here](https://i.sstatic.net/v5r31.png)](https://i.sstatic.net/v5r31.png)

However it takes about 7 minutes from the moment I push a git branch remotely to the moment the deploy is completed. The time is broken down like so:

* bitbucket deploy: 45 seconds

[![enter image description here](https://i.sstatic.net/HzWfa.png)](https://i.sstatic.net/HzWfa.png)

* provisioning a new EC2 instance: 3:40 minutes

[![enter image description here](https://i.sstatic.net/tzBgQ.png)](https://i.sstatic.net/tzBgQ.png)

* installing application on replacement instance: 40 seconds

[![enter image description here](https://i.sstatic.net/ijLab.png)](https://i.sstatic.net/ijLab.png)

* 2 minutes rerouting traffic from old instance to new one \*this one is extremely long, if it were done manually it would literally take 10 seconds)
* 17 seconds terminating second instance

[![enter image description here](https://i.sstatic.net/egJl0.png)](https://i.sstatic.net/egJl0.png)

All together it's around 7 minutes.

How can I optimize this? I'm looking to shrink it to below 1 minute.

**Tags:** aws-codedeploy


---

## 3 answers

### Answer by username_0 on 2018-08-06. Score: 2 | Accepted answer

got this answer from aws support

> Hello,
>
> Andrew from AWS Support here.
>
> I understand that you would like to know if there is a way to speed up
> Code Deploy as currently it takes 7 minutes to complete. Please
> correct me if needed.
>
> After examining the link and the Code Deploy environment I can see
> that the step which involves rerouting traffic from the old instance
> to the new instance can potentially be tuned to try and decrease the
> overall deployment time. In addition, using a different deployment
> configuration may also help to decrease the deployment time.
>
> To try and reduce the time taken to perform a blue/green deployment
> edit the health check on the Elastic Load Balancer (ELB). Reduce the
> health check interval from 30 seconds to 5 seconds and reduce the
> response timeout from 20 seconds to the default of 5 seconds [1]. This
> should decrease the time it takes the ELB to check whether an instance
> is healthy and ready to receive traffic.
>
> Another setting that may also help decrease the time it takes to
> deploy is the deployment configuration, set the deployment
> configuration from the currently used "one at a time" to "all at
> once". CodeDeploy "all at once" will at once attempt to deploy to as
> many instances as possible, the application status will be shown as
> succeeded if the application is deployed successfully to one or more
> of the instances. This configuration will also reroute all the traffic
> in the placement group to all instances at once and will succeed if
> the traffic is successfully routed to at least once instance [2].
>
> To reduce this deployment from 7 to 1 minute will be high unlikely as
> EC2 launches are managed by CodeDeploy, there may be ways to improve
> to EC2 launch times manually but this is not the case when using
> CodeDeploy.
>
> I hope you find this information useful, if you have any other
> questions or need clarification on anything above please let me know,
> I'd be happy to help
>
> Take care,
>
> References: [1] Configure Health Checks for Your Classic Load
> Balancer - Health Check Configuration -
> <https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html#health-check-configuration>
>
> [2] Working with Deployment Configurations in AWS CodeDeploy -
> Predefined Deployment Configurations for an EC2/On-Premises Compute
> Platform -
> <https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html#deployment-configurations-predefined>
>
> Best regards,
>
> Andrew v. Amazon Web Services


---

### Answer by username_1 on 2018-08-02. Score: 2

> bitbucket deploy: 45 seconds

This seems correct. Not sure of your repo size, but if it is hosted outside of your region, that's not out of the ordinary.

> bitbucket deploy: 45 seconds

Again, seems correct. Not much room for optimization here.

> provisioning a new ec2 instance: 3:40 minutes

What size of instance are you provisioning? Are you provisioning one or more instances? The obvious solution would be to use in place deployment vs blue-green, but I think the extra time is well worth it. If this is for production/staging, I think you are fine. If this is in a testing environment, and you are aiming for quick feed back, you could consider provisioning new instances after a successful blue-green so that, if there is no AMI change, they are ready to go for installation immediately.

> installing application on replacement instance: 40 seconds

Nothing to optimize here

> 2 minutes rerouting traffic from old instance to new one \*this one is extremely long, if it were done manually it would literally take 10 seconds)

My guess is that step is performing extra steps that you do not perform when you manually reroute traffic. It's possible that CodeDeploy is performing extra checks to make sure that connections are draining, new connections are established before old ones are closed, and other test/checks. This is probably your best area to optimize, but not at the sacrifice of checks and balances.

> 17 seconds terminating second instance

Nothing to optimize here.

**Summary:**
I don't think it is feasible or worthwhile to attempt to optimize your deployment further. The amount of effort it would take and sacrifices you would need to make in your test and checks far out ways the potential minute or two you would save in my opinion. I also don't think it is possible to achieve a <1 minute deployment. That would average ~15-20 seconds a step, which would require a lot of sacrifices in your deployment strategy.

If your goal is for quick iterations for QA, code testing, integration testing, etc., and you absolutely want sub 1 minute deployments, I recommend creating a Cloud Formation stack with your exact deployment except skipping the blue/green deployment model for an in place deployment model. This way, you can quickly see the results of your code. You should then later run your full suite blue/green deployment after your testing in either another testing environment or your staging environment.


---

### Answer by username_2 on 2018-08-11. Score: 0

Depending on the value of a faster deployment in your situation, some options are:

* Maintain spare capacity in your ECS cluster (either larger instance types, or more smaller ones) to allow for side-by-side deployment of new versions of the service along with the old, so that new *tasks* can be started without having to provision new *instances*. This obviously has a dollar cost, but again, depending on the value of rapid deployments to your organization, and the amount of deployments you expect to do per day, it might be worthwhile.
* Use [multiple sets of target groups for optimal Blue-Green deployments](https://aws.amazon.com/blogs/compute/bluegreen-deployments-with-amazon-ecs/). This still requires extra cluster capacity, and extra work in your pipeline, but you can ensure that once tested, the replacement set of tasks all go live at once (and are fully tested).


---

