I would like to use Octopus Deploy for Blue/Green Deployment for AWS ALB

Hi there,
I would like to use Blue/Green deployment strategy for my deployment to AWS.

  1. I got two ALBs, lets say ALB1 and ALB2(Green Env), they both are listening to active active load from Route53 with 50% load distributed each. There is ASG behind the ALB with static scaling serving .Net web applications.
  2. I would like to setup Blue/Green deployment where ABL4 and ALB5 would be introduced and accessible only internally for internal user verification.
  3. Once the new ALBs are tested, I would like to and slowly drain ALB1 and ALB2 (Blue Env) and route traffic to ALB4 and ALB5
  4. that means Route53 would now send 50%-50% load to ALB3 and ALB4
  5. In case of any issues in coming days, we can revert to prev version i.e. ALB1 and ALB2.
  6. So at a time I would have 4 ALBs running, which is costly but I think resilient and no impact to user traffic/performance.

All this is just theory but I am quite confused on where to start for implementing this pipeline in Octopus. Can someone guide me on this?

Hey @harsh_tech,

Thanks for reaching out to us!

Just one quick question regarding point 4, do you mean 50%-50% of the traffic would be pointed at ALB4 & ALB5?


@adam.close yes sorry typo. 50%-50% traffic to ALB4 and ALB5

@adam.close / @mark.harrison any help in this regard would be much appreciated. Let me know if you need more details on the usecase.

Hey @harsh_tech,

Thanks for the reply and ALB4 and ALB 5 make sense!

Sorry for the delay I’ve just created a little setup to match your scenario and I’m just creating a recommendation for you now.


Thanks @adam.close

Hey @harsh_tech,

I’ve had some time to think on this, and although having four ALBs makes your scenario slightly different from what I’ve done before, the configuration is pretty much the same.

I’m assuming that you have the life cycle in Octopus as development, test, staging, and production.

Firstly in Octopus, you will need to create another production environment in your lifecycle and call it production-blue rename the current production environment or create a new environment called production-green. Your Octopus lifecycle will look like development, test, staging, production-blue, and production green. The lifecycle in Octopus should allow you to deploy to either blue or green after staging.


You can check this out here in our samples.

I imagine the machines running in ALB1 & 2 are currently registered with Octopus to one environment, production? This will need to change, so those machines are registered to production-blue. Machines registered in ALB 4 & 5 need to be registered against production-green.

At this point, you have a bunch of machines running production workload under one environment, and machines running under the other production environment sat idol.

During deployment in Octopus, you can choose to deploy your new release to the environment that is sat idol with no traffic from users on it, knowing the new version won’t affect your current live service.

The next decision is how to move your user traffic from ALB 1 & 2 to ALB 4 & 5 when you have finished testing the new release.

You will need a script that instructs route 53 to point traffic to different load balances (and back for any problem and future deployments). This script can be included in an Octopus runbook and run manually, or it could be run at the end of every deployment process. At the end of the deployment to the empty environment, you could have a manual intervention step that pauses the deployment, and once approved, run the script swap route 53 to point traffic to the new environment.

You can check out a runbook we have here that changes AWS target groups to point to different EC2 instances.

Hopefully, this gives you a start but please ask any questions to help further!


1 Like

Great, this is amazing. Thanks @adam.close

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.