Blue-green deployment on AWS for web apps

Australian web applications rarely operate in isolation from the people and networks around them. A release that works from a fixed office connection can still fail for customers in Sydney, Melbourne or Brisbane when DNS, TLS certificates, mobile sessions or an external dependency changes. Teams therefore need a rollout method that makes failures visible and reversibility routine.

A blue-green deployment maintains two equivalent application environments. The blue environment serves normal traffic, while the green environment receives the candidate release for testing. After validation, an Application Load Balancer or DNS routing changes sends users to green; blue remains available as the rollback path until confidence is established.

The main benefit is control. Rather than replacing instances incrementally, operators can validate an immutable release at full scale, compare its health with the live version and switch traffic at a deliberate moment. The approach also supports staged traffic percentages when a small canary is safer than an immediate cutover for a high-value transaction service.

For Australian operators, the technical choice sits alongside legal duties. Under the Privacy Act 1988 (Cth), many services must handle personal information according to the Australian Privacy Principles and assess suspected breaches under the Notifiable Data Breaches scheme. Release records, access controls and rollback procedures become part of governance, not simply operational housekeeping.

Why blue-green deployment suits web workloads

The pattern works well for HTTP APIs, web portals and internally used applications that can run in parallel. Both environments can sit in private subnets behind the same load balancer, use matching autoscaling settings and connect to the same cache, queue and database services. A rule change then replaces a target group reference rather than asking clients to understand infrastructure hosts.

It is especially useful when a deployment changes a dependency, such as an authentication library, JavaScript bundle or database driver. Teams can run contract, smoke and load tests against green without disturbing blue. If error rates rise above or latency exceeds a defined threshold, the listener rule can point back to the old target group in seconds.

The model has limits. Long-lived WebSockets, background workers and stateful sessions need their own transition rules, while keeping two environments warm consumes budget. Some serverless workloads can achieve a similar result with versioned aliases and Lambda function versions, but a conventional service still benefits from having two complete, observable stacks.

A practical AWS reference architecture

A common design uses an Application Load Balancer with blue and green target groups, each backed by EC2 Auto Scaling groups or ECS services. Route 53 provides health-checked DNS, Amazon ECR stores immutable images, and AWS Secrets Manager supplies runtime credentials. An Amazon RDS database and ElastiCache Redis cluster remain shared where safe; separate worker queues prevent both environments from processing the same jobs.

Australian workloads can use the Sydney region, ap-southeast-2, or the Melbourne region, ap-southeast-4, to reduce latency and support local resilience expectations. A multi-Availability Zone deployment is still the first layer of availability, while a second region adds disaster recovery. Confirm the residency of backups, logs and support metadata rather than assuming every AWS service keeps data in the selected region.

The release pipeline deploys green with the exact artifact and infrastructure definitions used by blue. Private test routes, weighted listener rules or a dedicated test hostname let engineers verify real behaviour without making the candidate generally reachable. For estates that depend on Microsoft 365, the SharePoint performance notes at SharePointViews are a useful complement to application-level health checks, especially where identity and document permissions form part of the user journey.

Handling releases and database changes

Use AWS CodePipeline and CodeDeploy to coordinate build, test and traffic-shift stages, then apply expand-and-contract schema evolution. Add a new column or table in a backward-compatible release, deploy application code that can read both shapes, and remove the old structure only after green has served stable traffic. This makes rollback possible because blue can still operate against the expanded schema. Additive changes also reduce lock duration in a busy Australian customer database.

AWS RDS Blue/Green deployments can help with major database engine upgrades, but they do not remove the need for application compatibility tests. Check replica lag, transaction behaviour and the rollback procedure before switching production traffic. If the application stores session state in a local disk, replace it with signed cookies or a shared cache so instances in either colour can serve any request.

Synthetic tests should cover more than the home page. Include authentication, checkout, form submission, background jobs and campaign URLs with realistic metadata and redirects. For example, marketing may need to validate the casino tournament landing page as a critical deep link before a release reaches customers. Run the same test against blue and green, then compare results so a pre-existing failure is not mistaken for a regression.

Operational readiness before traffic moves

Use this checklist before declaring green ready. The checks should produce evidence that can be reviewed with the release owner rather than a verbal assurance that “it looks fine”.

Deployment checks

• Pin the exact container image digest or EC2 AMI and record it with the release.
• Review infrastructure-as-code differences for security groups, IAM policies and public exposure.
• Require healthy target-group status and successful dependency checks before testing.
• Exercise sign-in, payment, email, queue and third-party API paths in the candidate environment.
• Apply least-privilege roles, encrypted secrets and the ACSC Essential Eight controls relevant to the service.
• Confirm CloudWatch dashboards and alarms distinguish blue, green and shared dependencies.

Between deployment and cutover, compare the two colours rather than relying on a single dashboard. A green environment can pass basic uptime checks while producing slower database queries or omitting an audit event.

Cutover checks

• Name the person authorised to switch traffic and the person authorised to roll it back.
• Confirm blue retains enough healthy capacity for the expected immediate return path.
• Change the load-balancer target group or weighted DNS record and watch the agreed error metrics.
• Drain old connections and stop duplicate workers before declaring the release complete.
• Set objective rollback triggers for error rate, latency, queue growth and customer-support alerts.

Keep the previous release artefacts and configuration available for a defined period. Deleting blue immediately after a successful switch turns a sensible safety net into an expensive rollback exercise.

Make the cutover safe in Australia

Plan the operational handover around Australian business hours and on-call realities. Support and engineering teams may be spread across Brisbane, Sydney and Melbourne; Brisbane does not observe daylight saving, while southern states do. Put the release window and escalation path in Australian Eastern Time, notify affected stakeholders before the change, and avoid a cutover that lands at the start of a local workday.

Connectivity assumptions need testing too. A customer may be using NBN broadband at home, a mobile 5G connection in transit or a business link with different DNS behaviour. Route 53 health checks, application-level synthetic probes and a rehearsed failover matter more than a successful ping from an office network. If an outage occurs, the same runbook should distinguish a regional AWS fault, a bad release and a local provider incident.

Compliance and finance teams also need a clear record of the service footprint, release evidence and cost allocation. For organisations that need help designing the environment, my background in independent IT consulting offers a practical route from architecture decisions to an operational runbook.

Choose one low-risk service, build blue and green behind a test target group, and rehearse the switch and rollback in a non-production account. Record the health thresholds, owners and Australian time-zone window before touching production, then use that first controlled release to refine the process for critical systems.