What Is Blue-green deployment in DevOps?
On This Page
Quick Definition
Blue-green deployment is a way to update software with almost no downtime. You have two separate environments, blue and green. Only one is live at a time. You deploy the new version to the idle environment, test it, then instantly switch traffic to it.
Commonly Confused With
Canary deployment gradually routes a small percentage of traffic to the new version while the majority continues to use the old version. Blue-green switches all traffic at once. Canary is safer for high-risk changes because it limits the blast radius, but it takes longer to fully roll out. Blue-green is faster but risks all users facing the new version at once.
If you release a new login page, a canary would show it to 5% of users first. Blue-green would show it to everyone instantly after the switch.
Rolling deployment updates instances one by one or in batches within the same environment. No second environment exists. It is cost-effective but slower and does not provide instant rollback. Blue-green gives instant rollback by reverting traffic to the unused environment. Rolling requires you to revert each instance if a problem is found.
If you have 10 servers, a rolling deployment would update server 1, then 2, then 3, and so on. Blue-green would have 10 servers in blue and 10 in green, and you switch all traffic at once.
A/B testing is primarily about comparing two versions of a feature to measure user behavior, often lasting for hours or days. Blue-green is about releasing a new version to all users with zero downtime. A/B testing can use blue-green infrastructure for traffic routing, but the goals are different. A/B testing is about experimentation; blue-green is about deployment.
A company might use blue-green to deploy a new checkout flow to all users (release). Separately, they could use A/B testing to compare two different button colors for a week to see which one converts better (experiment).
Immutable deployment means you never update a running server. Instead, you replace it entirely with a new server that has the new version. Blue-green is a specific form of immutable deployment, but not all immutable deployments have two idle environments. An immutable deployment could replace instances one at a time (like rolling) without a separate idle environment.
Blue-green keeps an entire idle environment. A simple immutable deployment might rebuild a new server for each instance in the same pool and then terminate the old one.
Gold image deployment uses a pre-baked server image (AMI or VM snapshot) to launch new instances. Blue-green often uses gold images to create the idle environment, but the two concepts are not the same. Gold image is about how you build the servers; blue-green is about how you route traffic.
You could use a gold image to create all instances in the green environment, but the deployment strategy is still blue-green because you have two environments and a traffic switch.
Must Know for Exams
Blue-green deployment is a topic that appears directly in several major certification exams, most notably the AWS Certified Developer - Associate (AWS DVA-C02) and the Microsoft Azure DevOps Solutions (AZ-400) exam. In the AWS Developer - Associate exam, blue-green deployment is covered under the domain of "Deployment" and is a key strategy for achieving zero-downtime deployments. The exam expects you to understand how to implement blue-green deployments using AWS services like Elastic Beanstalk, CodeDeploy (specifically with deployment groups and the ability to reroute traffic), and Route 53 with weighted routing policies. You may be asked to choose between blue-green, canary, and rolling deployments for a given scenario. Questions often present a scenario where a company needs to deploy a new version of an application with zero downtime and an instant rollback capability. The correct answer will point to blue-green deployment. You must understand the trade-offs, including cost (two environments) and database compatibility requirements.
For the Azure DevOps Solutions (AZ-400) exam, blue-green deployment is part of the "Implement a release strategy" domain. The exam covers deployment slots in Azure App Service, which is a direct implementation of blue-green deployment. Azure App Service supports swapping deployment slots (like staging and production slots). This allows you to deploy a new version to a staging slot, warm it up, then swap it with the production slot. The exam will test your knowledge of slot swapping, auto-swap, and how to handle configuration and connection strings when swapping slots. You also need to understand how to use Azure Traffic Manager or Azure Front Door to route traffic between deployments. The AZ-400 exam often includes scenario-based questions where you must decide the best deployment strategy for a given set of requirements, such as zero downtime, instant rollback, or gradual traffic shifting.
In both exams, you should also be aware of the limitations. A common exam point is that blue-green deployment requires the database or stateful layer to be backward-compatible. Both versions of the application must be able to use the same database schema, or you must use a database deployment pattern that supports zero-downtime schema changes. Another exam trap is that blue-green deployment can be expensive for large infrastructures. The examiner might present a scenario where cost is a concern, and a rolling deployment or canary deployment might be more appropriate.
the AWS Certified Solutions Architect exams (Associate and Professional) and the Azure Administrator (AZ-104) may also touch on this concept, though less frequently. The primary exam focus is on the developer and DevOps certifications. Understanding the exact implementation differences between AWS and Azure is crucial. In AWS, you often use CodeDeploy with a blue/green deployment configuration or Elastic Beanstalk environment swaps. In Azure, you rely on App Service deployment slots. You should be ready to answer questions about the steps, the tools used, and the conditions that make blue-green deployment the right choice.
Simple Meaning
Imagine you have two identical rooms in a building, each set up exactly the same with desks, computers, and phones. One room is the active office where everyone is working right now. This is your live production environment. The other room is a backup, kept in perfect condition but empty for now. This is your idle environment. When you need to make a big change, like updating all the software or rearranging the desks, you do it in the empty room. You can take your time, test everything, and make sure all the new equipment works perfectly. No one is rushing you because the real work continues in the other room. Once you are completely satisfied with the new setup, you simply ask everyone to walk into the other room. The transition is instant. The old room becomes empty, ready to be updated for the next change. This is exactly how blue-green deployment works in IT. You have two identical production environments, commonly called blue and green. The live environment handles all user traffic. The other environment is kept in sync with the live environment regarding data, but it is not serving users. When you have a new software version ready, you deploy it to the idle environment, run tests, and validate it. Then you switch the router or load balancer so that all incoming traffic goes to the updated environment. The old environment becomes idle and can be used for the next deployment or kept as a quick rollback option. The key benefit is that the switch is instantaneous and completely reversible. If the new version has a problem, you can switch back to the old environment in seconds. Users experience no downtime and no interruption. This method is a core DevOps practice because it reduces risk, speeds up releases, and enables continuous delivery.
In simpler terms, blue-green deployment is like having a spare car ready. You drive your main car every day. When the main car needs a big repair, you prepare the spare car ahead of time, make sure everything is perfect, and then just start driving the spare instead. Your commute never stops because you always have a ready vehicle.
This approach is very different from a traditional update where you update the live system directly, which often requires taking the system offline, performing the update, testing quickly, and restarting. During that time, users cannot access the service. Blue-green deployment eliminates that downtime entirely. It also provides a built-in rollback mechanism. If the new version fails, you simply switch traffic back to the old environment. There is no need to undo complicated update steps. This makes deployments much safer and faster.
The term "blue-green" is arbitrary. It simply refers to two distinct environments. Some teams use other names, like "red-black" or "A/B", but the concept is the same. This technique is supported by major cloud providers like AWS, Azure, and Google Cloud, and it is a key topic for DevOps and developer certification exams.
Full Technical Definition
Blue-green deployment is a software release management strategy that maintains two separate, but functionally identical, production environments. These environments are often referred to as blue and green. At any given time, only one of these environments actively serves production traffic, while the other remains idle. The active environment is called the live environment, and the idle one is called the staging or inactive environment. The core mechanism relies on a router, load balancer, or traffic manager that controls the routing of incoming requests. This traffic manager has the capability to instantly redirect all traffic from one environment to the other, typically by updating DNS records, changing load balancer target groups, or modifying network routing rules.
In practice, a blue-green deployment workflow proceeds as follows. Initially, the blue environment is live and serves all production traffic. The green environment is kept in a ready state, with the same infrastructure configuration, same database schema, and same application version as the live environment. When a new application version is ready for release, the team deploys it to the green environment. This deployment can be done through automated CI/CD pipelines, often using tools like AWS CodeDeploy, Azure Pipelines, Jenkins, or GitLab CI. After the deployment, the team runs a comprehensive set of tests directly against the green environment. These tests can include smoke tests, integration tests, canary tests, and performance tests. If any test fails, the deployment is halted, and the green environment is fixed or rolled back without any impact on the live environment.
Once the green environment is fully validated, the team initiates the traffic switch. This is the critical moment. The router or load balancer updates its routing table to send all incoming traffic to the green environment instead of the blue environment. This switch can be performed in several ways. In cloud environments, it is common to update the target group of a load balancer, change the DNS record with a low TTL (time to live, often 60 seconds or less), or use a feature like AWS Route 53 weighted routing. The switch is designed to be atomic and transparent to the end user. Ideally, there is zero downtime, although some requests in flight during the transition might see a brief interruption. This is often mitigated using connection draining or graceful shutdown of existing connections.
After the switch, the green environment becomes the new live environment, and the blue environment becomes idle. The blue environment is not immediately discarded. It is kept as a hot standby for a period, often until the next deployment cycle. This allows for an instant rollback. If a critical bug is discovered in the new version, the traffic manager can simply switch back to the blue environment, restoring the previous version in seconds. Once the team is confident in the new release, the blue environment can be updated with the next version, and the cycle repeats.
Important considerations include state management and databases. While the application code and configuration can be deployed to the idle environment, the database is often a shared resource. Both environments must point to the same database, or the switch must account for database schema changes. This is a common challenge. Schema changes must be backward-compatible so that both the old and new application versions can work with the same database. Techniques like expand-and-migrate or rolling database updates are used to handle this. Another consideration is the cost, as maintaining two identical production environments doubles the infrastructure cost. However, the benefits of reduced downtime, instant rollback, and safer releases often justify this cost for critical applications.
Blue-green deployment is closely related to canary deployments and rolling deployments. It is considered a more aggressive zero-downtime strategy because the switch is all at once, whereas canary deployments gradually shift traffic to the new version. Both are supported by major cloud platforms and are essential concepts in DevOps practices, particularly for continuous delivery and high-availability systems.
Real-Life Example
Think about a busy airport with multiple runways. The airport operates flight after flight, and air traffic control manages the arrivals and departures constantly. Now imagine the airport decides to repave one of its main runways. The airport cannot simply close the runway for an entire day because that would cancel hundreds of flights and cause chaos. Instead, the airport operators prepare a backup runway that is identical in length, lighting, and markings. They schedule the repaving work at night when traffic is lighter. But even during the day, they have a plan. They designate one runway as the active runway, say runway A, and keep runway B as a reserve. When runway A needs maintenance, the airport first ensures runway B is fully ready. They check the lights, the surface, and the approach paths. Then, when maintenance on runway A is about to start, the air traffic controller simply switches all approaching flights to runway B. The transition happens in seconds. Pilots are instructed to use runway B instead. The flights continue without delay. Runway A is now empty. Workers can repave it, fix the lights, and do whatever is needed without any disruption to flight schedules. Once runway A is ready again, the airport might switch traffic back to it, or keep it as a backup. This is exactly how blue-green deployment works.
The active runway is your live production environment. The reserve runway is your idle environment. The air traffic controller is the load balancer or router that directs traffic. The maintenance work is the new software release. The key point is that the switch is instantaneous and completely reversible. If runway B has an unexpected issue, the controller can quickly send planes back to the original runway A. Users (the passengers) never notice any interruption. They just land or take off as usual. The airport can perform maintenance in a controlled, safe, and fast way. This same principle allows IT teams to launch new features, fix bugs, or update backend systems without making users wait or experience errors. It turns a risky, high-downtime operation into a routine, low-risk procedure.
Why This Term Matters
In the world of modern IT, downtime is extremely expensive and damaging. For e-commerce sites, every minute of unavailability can mean thousands of dollars in lost sales and a damaged reputation. For SaaS applications, downtime can break service level agreements (SLAs) and lead to contract penalties. Blue-green deployment addresses this directly by virtually eliminating deployment-related downtime. It allows IT teams to release new features, security patches, and bug fixes at any time, even during peak business hours, without asking users to wait or suffer interruptions. This enables a faster release cadence, which is a core goal of DevOps and continuous delivery.
Blue-green deployment also drastically reduces risk. Traditional deployment methods, where you update the live system directly, carry a high risk of failure. If the new version has a bug, you might need to revert changes, which can be complex, time-consuming, and risks data corruption. With blue-green deployment, the rollback is as simple as switching traffic back to the old environment. This safety net encourages teams to deploy more frequently, which leads to smaller, safer changes. Smaller deployments are easier to test and debug. This reduces the chance of major outages caused by complex, large-scale updates.
blue-green deployment enables thorough testing in a production-like environment before any user traffic is sent. You can run automated tests, performance tests, and even manual validation on the idle environment that is an exact clone of production. This is much more accurate than testing in a separate staging environment that might have different configuration or data. The result is higher quality software and fewer issues reaching end users.
Finally, this practice aligns with infrastructure as code (IaC) concepts. The two environments can be provisioned and managed using tools like Terraform, AWS CloudFormation, or Azure Resource Manager templates. This makes the entire process repeatable, auditable, and automated. For IT professionals, understanding blue-green deployment is essential not just for passing certification exams, but for building resilient, high-availability systems that meet today's business demands. It is a hallmark of a mature DevOps culture and a fundamental pattern in cloud architecture.
How It Appears in Exam Questions
Exam questions about blue-green deployment typically appear in scenario-based formats, configuration analysis questions, and troubleshooting scenarios. The most common pattern is a deployment scenario where the question describes a company's requirements for a new application release. For example, a question might state: "A company is deploying a new version of its web application. They require zero downtime and the ability to quickly revert to the previous version if a critical issue is found. What deployment strategy should they use?" The correct answer will be blue-green deployment. You might also see a variant where the question asks about the downside, such as: "What is a disadvantage of using a blue-green deployment strategy?" The answer is higher infrastructure cost, as you are running two production environments concurrently.
Another common question type involves configuration. On the AWS side, a question might describe a developer configuring a deployment pipeline. They might ask: "A developer wants to use AWS CodeDeploy to perform a blue-green deployment. Which components must be configured?" The answer will include setting up two deployment groups (one for blue, one for green), configuring a load balancer, and specifying the traffic rerouting behavior. You might also see a question about manually switching traffic: "When performing a blue-green deployment with AWS Elastic Beanstalk, how can a developer swap the environments?" The answer is to use the Swap Environment URLs feature.
On the Azure side, you might see a question like: "You are using Azure App Service. You want to deploy a new version of your application to a staging slot and then move it to production with zero downtime. Which feature should you use?" The answer is to use the Swap deployment slots feature. A more advanced question might ask: "During a slot swap operation, which settings are considered sticky and remain with the source slot?" Here you must remember that connection strings, configuration settings, and other slot-specific settings can be marked as "sticky" and not swap with the slot. This is a common exam trap.
Troubleshooting scenarios also appear. For example: "After performing a blue-green deployment, users report that their sessions are lost. What is the most likely cause?" The answer is that session data was stored in the application memory of the original environment and was not carried over to the new environment. This tests your understanding of state management. The solution would be to use a shared external session store like Redis or a database. Another troubleshooting question might be: "A developer performs a blue-green deployment, but the new environment is not receiving traffic. What should they check?" The answer could be the load balancer target group or DNS TTL settings that might be caching the old routing information.
Finally, comparative questions are common. You might be asked to differentiate between blue-green, canary, and rolling deployments. The distinguishing factor is that blue-green deploys an entire new environment and switches all traffic at once, while canary gradually shifts traffic, and rolling updates instances in batches. Understanding these differences is critical for exam success.
Practise Blue-green deployment Questions
Test your understanding with exam-style practice questions.
Example Scenario
A company called "ShopFast" runs an online store that receives thousands of orders every hour. They have a critical new feature ready: a one-click checkout that they believe will increase sales. The team needs to deploy this feature to production. However, the store cannot afford any downtime. Even a few seconds of unavailability could cost thousands of dollars in lost sales and frustrate customers. The development team decides to use a blue-green deployment strategy.
First, the team ensures they have two identical production environments. They call them blue and green. Currently, the blue environment is live and serving all customer traffic. The green environment is idle but has the same configuration, database, and load balancer setup. The team deploys the new one-click checkout feature to the green environment. They deploy the updated code, update configuration files, and run automation scripts that set up the necessary services. Once the deployment is complete, the team runs a battery of automated tests directly against the green environment. These tests include checking that the checkout flow works, that payment processing is correct, and that the website loads quickly. They also perform integration tests with the inventory system. All tests pass. As an extra precaution, a few team members manually test the new feature on the green environment using internal browsers.
Now, the team is ready to cut over. They open the AWS Console and navigate to their Elastic Load Balancer. They update the target group to point to the green environment instances. The switch happens instantly. All new user requests are now routed to the green environment. The team monitors the application for a few minutes. They see that traffic is flowing correctly and that the new checkout feature is working. The old blue environment remains idle. The team keeps it running for two hours as a safety net. If any critical bug is discovered, they can switch back to blue in seconds. After two hours with no issues, the team proceeds to shut down the blue environment, saving costs. They can now use the blue environment for the next deployment. This scenario shows how blue-green deployment allows ShopFast to release a major feature with zero downtime and a safe, instant rollback capability.
Common Mistakes
Believing that blue-green deployment requires only one active environment at all times.
Blue-green deployment requires maintaining two fully functional production environments simultaneously for the switch to be instantaneous. If you only have one environment, you cannot perform a true blue-green deployment. You would need to build a second environment before the deployment, which increases cost and complexity.
Always remember that blue-green deployment means two identical environments exist concurrently. The idle one is just as complete as the active one.
Assuming that database schema changes can be deployed at the same time as the application code without any special handling.
Database is often a shared resource. If you deploy a new database schema to the idle environment, the old environment still running the old code might not work with the new schema. This can cause data corruption or downtime. Blue-green deployment requires backward-compatible database changes or separate database handling strategies.
Treat database changes as separate from application changes. Use expand-and-migrate pattern or ensure the old application version can still read the new schema.
Thinking that blue-green deployment eliminates all deployment risk because there is an instant rollback.
While the rollback is fast, it is not risk-free. If the new environment has altered the shared database in a way that is incompatible with the old environment (e.g., adding a non-null column), the rollback could fail or cause data inconsistency. Also, if the new environment started processing transactions that are not undoable (like sending emails), switching back will not undo those actions.
Design your deployment so that the old environment can still handle new traffic after a rollback. Avoid irreversible state changes in the new environment during test time.
Confusing blue-green deployment with canary deployment or A/B testing.
Blue-green switches all traffic at once to one new environment. Canary deployment gradually shifts a small percentage of traffic to the new version, monitoring for issues, then shifting more. A/B testing often routes different user groups to different versions for longer periods to test user behavior. They are different in purpose and execution.
Learn the specific definitions. Blue-green is for zero-downtime releases. Canary is for gradual rollout with risk mitigation. A/B testing is for feature comparison with users.
Assuming that the switch between environments is always instantaneous and causes zero user disruption.
In some implementations, the switch may involve DNS propagation delays or in-flight requests being sent to the old environment. Without connection draining or graceful session handling, some users might experience brief errors or session timeouts. Cloud providers have features to mitigate this, but it is not automatically perfect.
Configure connection draining on the old load balancer and set low TTL values for DNS records. Also, ensure your application can handle brief connection drops gracefully.
Ignoring the cost implication and recommending blue-green deployment for every scenario.
Blue-green deployment doubles infrastructure costs because you maintain two production-scale environments. For small projects or for non-critical applications, a rolling deployment or a simpler update strategy may be more cost-effective. Cert exams often test whether you consider cost.
Always weigh the benefits of zero downtime against the cost. Use blue-green for critical, high-traffic applications that justify the expense. For less critical services, consider other deployment strategies.
Exam Trap — Don't Get Fooled
{"trap":"The exam question describes a scenario where a team needs to deploy a new version of a web app with zero downtime and instant rollback. The team has a single production environment, but they plan to clone it just before deployment. They call this blue-green deployment.
The question asks if this is correct.","why_learners_choose_it":"Learners think that creating a clone just in time and then switching traffic satisfies the definition. They ignore the requirement that the idle environment must be ready and validated before the switch.
The concept of 'two simultaneous environments' is often misunderstood as 'two environments at the time of switch,' but the idle environment should exist ahead of time and be kept in sync with the live data state.","how_to_avoid_it":"Remember that true blue-green deployment requires both environments to be maintained and ready at all times. The idle environment is not created on the fly.
It is a permanent infrastructure that mirrors the live environment. In a real exam scenario, if a team creates a new environment just for deployment and then tears it down after, it is not a proper blue-green deployment. It is more like a cloned deployment.
The key is the constant readiness of the second environment."
Step-by-Step Breakdown
Prepare two identical production environments
Set up two separate but functionally identical infrastructure stacks. This includes compute instances, load balancers, network configurations, and any dependent services. Ensure both environments are isolated from each other but share the same underlying database or state store if needed. This step is foundational. Without two identical environments, you cannot perform the traffic switch.
Keep the idle environment synchronized
While one environment (e.g., blue) is live, keep the other (green) as up-to-date as possible regarding the application version and configuration. This minimizes drift. In some implementations, the idle environment might be running the same version as the live one, or it might be a version behind. The key is consistency. Automated pipelines should regularly deploy updates to the idle environment to ensure it reflects the live state.
Deploy the new version to the idle environment
When ready, deploy the new application code, configuration changes, and any infrastructure updates to the idle environment. Use CI/CD pipelines to automate this. Validate that the deployment is successful by checking that all services are running and healthy. This step does not affect any users, as no traffic is directed to the idle environment.
Run validation and tests on the idle environment
Execute a comprehensive suite of tests directly against the idle environment. Include smoke tests, integration tests, performance tests, and security scans. You can also conduct manual verification. The goal is to ensure the new version is ready for production traffic. If tests fail, you can fix the issue without any impact on users and then re-deploy.
Switch production traffic to the new environment
Update the router, load balancer, or DNS settings to redirect all incoming traffic from the old environment to the validated idle environment. This switch should be atomic and as instantaneous as possible. In cloud environments, you might update the target group of a load balancer, swap deployment slots, or change DNS records with a low TTL. Ideally, there is zero downtime.
Monitor the new production environment
After the switch, closely monitor the new environment for errors, latency, and any abnormal behavior. Use logging, metrics, and alerting. Keep the old environment running as a hot standby. If a critical issue is detected, you can quickly switch traffic back to the old environment with minimal impact.
Clean up the old environment
Once you are confident that the new environment is stable and the old environment is no longer needed, you can decommission it. This frees up resources and reduces costs. The old environment can then be re-provisioned and used as the idle environment for the next deployment cycle. This step completes the loop.
Practical Mini-Lesson
In practice, implementing a blue-green deployment requires careful coordination across multiple teams and tooling. As a DevOps professional, you will need to design the infrastructure so that both production environments are identical in terms of compute, networking, and storage. This often means using infrastructure as code (IaC) tools like Terraform, CloudFormation, or Azure ARM templates to define the blue and green stacks as repeatable modules. Each environment should have its own load balancer, but the entry point for users is a single, shared DNS name (like www.example.com) that is mapped to the active load balancer. When you need to switch, you update the DNS record or the traffic manager to point to the other load balancer.
One of the most challenging aspects is handling stateful data. If your application stores session data in memory on the servers, that data will be lost when you switch environments. The solution is to use a centralized, external session store such as Redis, Memcached, or a database. All instances in both environments must point to the same session store. Similarly, databases and message queues are usually shared. When deploying schema changes, you must ensure forward and backward compatibility. A common technique is the expand phase: add new columns or tables that the old application can ignore. Then deploy the new application. Then perform the migrate and contract phases later. This is known as the expand-and-migrate pattern.
Another practical consideration is the cost. Running two full production environments can double your infrastructure bill. Some organizations mitigate this by using smaller instances for the idle environment (since it does not need to handle traffic during validation), but they must be scaled up before the switch to handle the full production load. Alternatively, you can use auto-scaling to dynamically resize the idle environment just before the switch. This reduces cost but adds complexity.
For CI/CD integration, you can use tools like AWS CodeDeploy, which natively supports blue-green deployments through deployment groups. In Azure DevOps, you can use Azure App Service deployment slots. Jenkins can orchestrate the process using scripts that call cloud provider APIs. The pipeline should be automated end-to-end, from building the new version to running validation tests to performing the traffic switch. Human intervention should be minimal, but you should include a manual approval gate if required by your organization.
What can go wrong? The most common failure is the traffic switch itself. If your DNS record has a long TTL, users may see the old site for minutes after the switch. Always use low TTL values (like 60 seconds) for the DNS entry. Another common issue is configuration drift between the two environments. If you manually changed something in the live environment without updating the IaC templates, the idle environment might not be identical, leading to unexpected behavior after the switch. Using automation and immutable infrastructure reduces this risk. Also, if the new environment has a critical bug that only surfaces under full production load, and you have already destroyed the old environment, you have no quick rollback. Always keep the old environment running at least for a monitoring period.
Professionals should also consider security implications. Both environments must be equally hardened, as the idle environment is a potential attack surface. Apply patches and security updates to both. Also, restrict access to the idle environment so that only deployment pipelines and testing tools can reach it. Finally, practice disaster recovery. Test the blue-green switch regularly, even when you are not deploying a new version. This ensures that the procedure works and that the team is familiar with the process.
Memory Tip
Remember B-G: Blue is Go, Green is Idle. Then you flip: Green becomes Go, Blue becomes Idle.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
A/B testing is a controlled experiment that compares two versions of a single variable to determine which one performs better against a predefined metric.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
An AAAA record is a DNS record that maps a domain name to an IPv6 address, allowing devices to find each other over the internet using the newer IP addressing system.
Frequently Asked Questions
Is blue-green deployment the same as having a staging environment?
No. A staging environment is a separate environment used for testing before going to production, but it is not necessarily identical to production and does not automatically participate in traffic switching. Blue-green environments are both production-grade and the switch is automatic and instant.
How do I handle database migrations during a blue-green deployment?
Database changes must be backward-compatible. Use the expand-and-migrate pattern: first add new columns or tables in a way that the old application can still work. Then deploy the new application. After that, you can migrate data and remove old columns in a subsequent release.
What is the main disadvantage of blue-green deployment?
The main disadvantage is cost, because you must maintain two fully scaled production environments simultaneously. This doubles infrastructure expenses for the duration of the deployment cycle.
Can I use blue-green deployment for mobile app backends?
Yes. The principle is the same. The mobile app's API requests go through a load balancer. You can switch the load balancer to point to the new backend environment. However, you must ensure API version compatibility so that the mobile app does not break after the switch.
Does blue-green deployment work with microservices?
Yes, but it is more complex. Each microservice would need its own blue-green setup, or you can do a blue-green deployment of the entire system as a whole. The latter is simpler but requires more resources. Many teams use canary deployments for individual microservices instead.
How long should I keep the old blue (or green) environment running after the switch?
It depends on your confidence and risk tolerance. Many teams keep it running for a few hours to a few days. The longer you keep it, the easier the rollback, but the higher the cost. A common practice is to keep it for a monitoring window (e.g., 24 hours) and then decommission it.
Will users lose their sessions during the switch?
If session data is stored in-memory on the old servers, sessions will be lost. To avoid this, store session data in a centralized, external store like Redis or a database that both environments can access. This ensures session continuity during the switch.
Is blue-green deployment supported by all cloud providers?
Major cloud providers like AWS, Azure, and Google Cloud offer built-in features to support blue-green deployments. AWS has CodeDeploy blue/green, Elastic Beanstalk swaps, and Route 53. Azure has App Service deployment slots. Google Cloud has Traffic Director and Cloud Load Balancing. Smaller providers may require manual setup.