How AWS VPC peering can help in blue/green deployment

You have resources you can throw away (stateless) and resources you can’t throw away (state-full).

Donald Knuth said it beautifully: there is nothing you can’t solve without an extra indirection.

To achieve blue/green deployment on AWS, you put all your resources that can die and revive (think auto scaling groups, malicious terminations, but also whole VPCs) in one VPC: let’s call it VPC A (UAT/CI/TEST-> to be promoted to PROD).  In the meantime you build VPC  B (to be UAT/CI/TEST).   VPC C contains the statefull stuff.

Bootstrap VPC A with ad-hoc databases and use internal DNS (active directory service) as a first UAT, promote it to PROD by changing state full service DNS to a peered VPC that contains the real databases/and other state-full services.  After promoting a TEST/UAT environment to PROD, you change external DNS entries from uat-, to <blank> and internal DNS entries to the peering VPC by changing internal AD DNS entries to the peering VPC.  Once in PROD, you can continue dev/ci in VPC B and continue development, until you are satisfied and change DNS again…  Like this you can achieve a continuous delivery of new features (even when using legacy setups using simple servers  – which of course will be EC2s).  Deliver, build same environment (using cloudformation/terraform), test, confident => swap DNS (external/internal), etc…

The VPC that contains the state full stuff needs upgrading sometimes also, for this you build replica VPCs (VPC C’ and remove asap because expensive) where you can test your changes.  Once confident you apply your changes on the one and only state full VPC (databases, queues, …).  Features like MS SQL always on can help here to avoid downtime, but in the end, you always have a window of maintenance, but you can keep it very small following above strategy.

I recently implemented above strategy with VPC peering…

Leave a Reply

Your email address will not be published. Required fields are marked *