 |
Whereas containers have revolutionized how improvement groups package deal and deploy purposes, these groups have needed to rigorously monitor releases and construct customized tooling to mitigate deployment dangers, which slows down delivery velocity. At scale, improvement groups spend helpful cycles constructing and sustaining undifferentiated deployment instruments as an alternative of innovating for his or her enterprise.
Beginning at present, you need to use the built-in blue/inexperienced deployment functionality in Amazon Elastic Container Service (Amazon ECS) to make your utility deployments safer and extra constant. This new functionality eliminates the necessity to construct customized deployment tooling whereas supplying you with the boldness to ship software program updates extra often with rollback functionality.
Right here’s how one can allow the built-in blue/inexperienced deployment functionality within the Amazon ECS console.
You create a brand new “inexperienced” utility surroundings whereas your current “blue” surroundings continues to serve stay visitors. After monitoring and testing the inexperienced surroundings totally, you route the stay visitors from blue to inexperienced. With this functionality, Amazon ECS now gives built-in performance that makes containerized utility deployments safer and extra dependable.
Under is a diagram illustrating how blue/inexperienced deployment works by shifting utility visitors from the blue surroundings to the inexperienced surroundings. You may study extra on the Amazon ECS blue/inexperienced service deployments workflow web page.
Amazon ECS orchestrates this complete workflow whereas offering occasion hooks to validate new variations utilizing artificial visitors earlier than routing manufacturing visitors. You may validate new software program variations in manufacturing environments earlier than exposing them to finish customers and roll again near-instantaneously if points come up. As a result of this performance is constructed immediately into Amazon ECS, you’ll be able to add these safeguards by merely updating your configuration with out constructing any customized tooling.
Getting began
Let me stroll you thru an illustration that showcases the way to configure and use blue/inexperienced deployments for an ECS service. Earlier than that, there are a number of setup steps that I want to finish, together with configuring AWS Identification and Entry Administration (IAM) roles, which yow will discover on the Required sources for Amazon ECS blue/inexperienced deployments Documentation web page.
For this demonstration, I need to deploy a brand new model of my utility utilizing the blue/inexperienced technique to attenuate threat. First, I must configure my ECS service to make use of blue/inexperienced deployments. I can do that by means of the ECS console, AWS Command Line Interface (AWS CLI), or utilizing infrastructure as code.
Utilizing the Amazon ECS console, I create a brand new service and configure it as normal:
Within the Deployment Choices part, I select ECS because the Deployment controller sort, then Blue/inexperienced because the Deployment technique. Bake time is the time after the manufacturing visitors has shifted to inexperienced, when instantaneous rollback to blue is obtainable. When the bake time expires, blue duties are eliminated.
We’re additionally introducing deployment lifecycle hooks. These are event-driven mechanisms you need to use to reinforce the deployment workflow. I can choose which AWS Lambda operate I’d like to make use of as a deployment lifecycle hook. The Lambda operate can carry out the required enterprise logic, however it should return a hook standing.
Amazon ECS helps the next lifecycle hooks throughout blue/inexperienced deployments. You may study extra about every stage on the Deployment lifecycle phases web page.
- Pre scale up
- Put up scale up
- Manufacturing visitors shift
- Check visitors shift
- Put up manufacturing visitors shift
- Put up take a look at visitors shift
For my utility, I need to take a look at when the take a look at visitors shift is full and the inexperienced service handles all the take a look at visitors. Since there’s no end-user visitors, a rollback at this stage can have no affect on customers. This makes Put up take a look at visitors shift appropriate for my use case as I can take a look at it first with my Lambda operate.
Switching context for a second, let’s deal with the Lambda operate that I exploit to validate the deployment earlier than permitting it to proceed. In my Lambda operate as a deployment lifecycle hook, I can carry out any enterprise logic, similar to artificial testing, calling one other API, or querying metrics.
Throughout the Lambda operate, I need to return a hookStatus. A hookStatus will be SUCCEEDED, which can transfer the method to the subsequent step. If the standing is FAILED, it rolls again to the blue deployment. If it’s IN_PROGRESS, then Amazon ECS retries the Lambda operate in 30 seconds.
Within the following instance, I arrange my validation with a Lambda operate that performs file add as a part of a take a look at suite for my utility.
import json import urllib3 import logging import base64 import os # Configure logging logger = logging.getLogger() logger.setLevel(logging.DEBUG) # Initialize HTTP shopper http = urllib3.PoolManager() def lambda_handler(occasion, context): """ Validation hook that checks the inexperienced surroundings with file add """ logger.data(f"Occasion: {json.dumps(occasion)}") logger.data(f"Context: {context}") strive: # In an actual situation, you'll assemble the take a look at endpoint URL test_endpoint = os.getenv("APP_URL") # Create a take a look at file for add test_file_content = "It is a take a look at file for deployment validation" test_file_data = test_file_content.encode('utf-8') # Put together multipart type information for file add fields = { 'file': ('take a look at.txt', test_file_data, 'textual content/plain'), 'description': 'Deployment validation take a look at file' } # Ship POST request with file add to /course of endpoint response = http.request( 'POST', test_endpoint, fields=fields, timeout=30 ) logger.data(f"POST /course of response standing: {response.standing}") # Verify if response has OK standing code (200-299 vary) if 200 When the deployment reaches the lifecycle stage that’s related to the hook, Amazon ECS mechanically invokes my Lambda operate with deployment context. My validation operate can run complete checks towards the inexperienced revision—checking utility well being, operating integration checks, or validating efficiency metrics. The operate then alerts again to ECS whether or not to proceed or abort the deployment.
As I selected the blue/inexperienced deployment technique, I additionally must configure the load balancers and/or Amazon ECS Service Join. Within the Load balancing part, I choose my Software Load Balancer.
Within the Listener part, I exploit an current listener on port 80 and choose two Goal teams.
Pleased with this configuration, I create the service and look forward to ECS to provision my new service.
Testing blue/inexperienced deployments
Now, it’s time to check my blue/inexperienced deployments. For this take a look at, Amazon ECS will set off my Lambda operate after the take a look at visitors shift is accomplished. My Lambda operate will return FAILED on this case because it performs file add to my utility, however my utility doesn’t have this functionality.
I replace my service and test Pressure new deployment, figuring out the blue/inexperienced deployment functionality will roll again if it detects a failure. I choose this selection as a result of I haven’t modified the duty definition however nonetheless must set off a brand new deployment.
At this stage, I’ve each blue and inexperienced environments operating, with the inexperienced revision dealing with all of the take a look at visitors. In the meantime, based mostly on Amazon CloudWatch Logs of my Lambda operate, I additionally see that the deployment lifecycle hooks work as anticipated and emit the next payload:
[INFO] 2025-07-10T13:15:39.018Z 67d9b03e-12da-4fab-920d-9887d264308e Occasion: { "executionDetails": { "testTrafficWeights": {}, "productionTrafficWeights": {}, "serviceArn": "arn:aws:ecs:us-west-2:123:service/EcsBlueGreenCluster/nginxBGservice", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123:service-revision/EcsBlueGreenCluster/nginxBGservice/9386398427419951854" }, "executionId": "a635edb5-a66b-4f44-bf3f-fcee4b3641a5", "lifecycleStage": "POST_TEST_TRAFFIC_SHIFT", "resourceArn": "arn:aws:ecs:us-west-2:123:service-deployment/EcsBlueGreenCluster/nginxBGservice/TFX5sH9q9XDboDTOv0rIt" }As anticipated, my AWS Lambda operate returns FAILED as hookStatus as a result of it did not carry out the take a look at.
[ERROR] 2025-07-10T13:18:43.392Z 67d9b03e-12da-4fab-920d-9887d264308e File add take a look at failed: HTTPConnectionPool(host="xyz.us-west-2.elb.amazonaws.com", port=80): Max retries exceeded with url: / (Attributable to ConnectTimeoutError(, 'Connection to xyz.us-west-2.elb.amazonaws.com timed out. (join timeout=30)')) As a result of the validation wasn’t accomplished efficiently, Amazon ECS tries to roll again to the blue model, which is the earlier working deployment model. I can monitor this course of by means of ECS occasions within the Occasions part, which gives detailed visibility into the deployment progress.
Amazon ECS efficiently rolls again the deployment to the earlier working model. The rollback occurs near-instantaneously as a result of the blue revision stays operating and able to obtain manufacturing visitors. There is no such thing as a end-user affect throughout this course of, as manufacturing visitors by no means shifted to the brand new utility model—ECS merely rolled again take a look at visitors to the unique secure model. This eliminates the standard deployment downtime related to conventional rolling deployments.
I can even see the rollback standing within the Final deployment part.
All through my testing, I noticed that the blue/inexperienced deployment technique gives constant and predictable conduct. Moreover, the deployment lifecycle hooks present extra flexibility to regulate the conduct of the deployment. Every service revision maintains immutable configuration together with activity definition, load balancer settings, and Service Join configuration. Which means rollbacks restore precisely the identical surroundings that was beforehand operating.
Extra issues to know
Listed here are a few issues to notice:
- Pricing – The blue/inexperienced deployment functionality is included with Amazon ECS at no extra cost. You pay just for the compute sources used in the course of the deployment course of.
- Availability – This functionality is obtainable in all business AWS Areas.
Get began with blue/inexperienced deployments by updating your Amazon ECS service configuration within the Amazon ECS console.
Comfortable deploying!
— Donnie
