To DR or Not To DR

Most organizations these days look at strategies and ways of implementing a "working" DR solution. Often a DR plan of action is a manual process based on multiple approvals at each level from Incident Management Teams to Product Ownership teams. What if there was a way to keep an active DR running where failure of a primary site would seamlessly transfer the traffic to the secondary site. In fact if the DR is active or warm then the only manual bit would be disabling the primary site via DNS. A few tips and tricks that would help in a simple implementation of a warm DR for an application hosted on AWS. AMI  Make sure that the AMIs are built across both the primary and secondary region.  The fastest way to build multi-region AMIs would be to use different builds for each region using the same configuration management code altering the "REGION" parameter each time. This would make the AMIs consistent and available in each region. PACKAGE REPOSITORY

Enterprise Architecture - Strikingly Similar to Motherhood

Being a new mother has taught me the real meaning of phrases we often learnt in primary school like "Patience is virtue". After spending a couple of months getting used to the sleep deprivation and the exhaustion that motherhood gets blessed with (along with, of course, the toothless little angel in your arms), I had an epiphany.  Motherhood, really, is about following the principles of enterprise architecture in your day to day life! (Well not all of it but a part of it anyway). And I can say from my experiences that a lot of it now makes more sense to me than ever. There are four primary attributes of an enterprise architecture - High Availability, Robustness, Disaster Recovery and of-course Scalability. Lets tackle these one-by-one. HIGH AVAILABILITY : Any enterprise level setup needs to be highly-available. Come rain, hail, snow, an application needs to be ready and serving customer requests at all times. Quite like a breastfeeding mom, who must feed a h

High Availability NAT for AWS VPC with Multiple Private Subnets.

VPCs have become the de-facto architectural choice when deploying enterprise applications. They are highly secure, keep your infrastructure logically separated which when combined with the power that AWS has to offer become highly available and robust. The one thing, however, that still feels like a point of failure are the NAT instances that need to be created for all private subnet outbound connectivity to the internet or any service that is external to the VPC. This brings us to create a sort of NAT failover mechanism. High Availability for Amazon VPC NAT Instances by Jinesh Varia offers a solution for a simple VPC that has active NATs per private subnet and each keeps pinging the other till one of them loses connectivity. The active NAT, at that moment, "takes over" the route for the failed NAT. An edge case to this solution is when you have private subnets per AZ and there is a loss of connectivity between AZs. We were faced with the same issue, which brought the t