Bram Verdonck

Yesterday we moved away from using CloudFlare towards Amazon Route 53 for a few reasons. Although CloudFlare is a great platform, once you reach almost a 100% AWS Service integration, it makes it hard to still use CloudFlare in the stack. Also being able to use Aliases for DNS makes it faster because instead of doing a CNAME and an A record lookup, you will be able to receive the A records from the end services directly. We always loved working with CloudFlare , especially for DNS as we already used Amazon CloudFront for CDN. But having everything within AWS makes it "cleaner" when deploying automatically using AWS CloudFormation. All that aside, the main reason for moving towards Amazon Route 53 for DNS is the ability to do geolocation and latency based DNS responses. Doing this outside the AWS console would increase the complexity.

Today we added AWS CodeDeploy to our stack. The easiest way to deploy our code towards a big Autoscaling group of Amazon EC2 instances. The only problem we found on our way was that when using AWS Elastic Load Balancing (ELB) and AWS CodeDeploy , you can only select one ELB Target Group when creating a deployment. While we actually use 5 towards each Amazon EC2 instance because one deployed Node.js code source actually has the data to server 5 vhosts. Luckily we can let the bash script used in AWS CodeDeploy tell the ELB to stop sending it traffic to all Target groups during the in-place update.

After looking for a way to monitor or at least get a better overview of our infrastructure, we found out that Grafana (which I previously only used in ELK stacks) has a plugin available to fully integrate with Amazon CloudWatch . Which makes it way better for our use-case than the offer of the different competitors (most of them are even paid). There is also a CloudFlare plugin available, the platform we use to serve our DNS requests. Although we are a big fan of https://smashing.github.io/ (previously dashing), for now we are starting with Grafana .