Amazon Route53 is a highly available and scalable DNS service. Route53 provides Domain Registrations and Transfers, DNS service to route traffic to the infrastructure (either within AWS or non-AWS), advanced routing policies like weighted and geo, and health check services that can be leveraged to perform traffic routing to different destination in the event of a failure. It provides more flexibility and seamless integration with AWS Services than any other DNS host can.
One of the most common scenarios is the need to send traffic from a site registered at non-Route53 providers to an ELB, which Route53 supports via an Alias Record.
In this post we will discuss moving the DNS - where requests to a domain hosted on a non-Route53 provider would resolve to Route53, and then point to an ELB which could be hosting a web property. However, the destination does not have to be an ELB, it can be any public IP. The other part is that of the Domain Registration itself, which can be transferred to Route53 if needed.
For beginners, Amazon Web Services has a Free Tier, which is very generous. However, as you start to stretch the free tier to it’s limits, it’s good to have billing alerts set up. Essentially you’ll get an email when your bill approaches a certain amount.
Setting up billing alerts uses CloudWatch, which is not really the first service the beginners run into. This post shows how to set up AWS Billing Alerts, with screenshots, so you do not have to be familiar with CloudWatch to set one up. I strongly recommend setting the Billing Alerts up, regardless of free tier - having heard and seen horror stories in the recent past.
In the world of MicroServices, immutable deployments is a highly recommended strategy. It demands that every release get a fresh environment, all the way down to the lowest level - or in case of AWS, the AMI.
An AMI can bundle the base operating system, application server/runtime, scripts, agents, etc. along with a versioned application artifact. In the spirit of Infrastructure as Code, the AMI itself can be versioned as a simple json file, as we will see in this post.
With respect to Automation, creation of the AMI can be triggered as a downstream Jenkins Job, after successful pre-release tests, and can then act as an upstream Job for the Infrastructure Build-out using CloudFormation, or Terraform. Once the infrastructure is built, it can be made live via blue/green, red/black or any other deployment plan.
In this post, we will build an AMI that can be used to launch 100% identical instances in the infrastructure. We will use Packer to build the AMI, and create Jenkins Jobs to simulate a simplified, real-world CI/CD pipeline.
In this final post of the series on Java-based Serverless Lambda API, we will invoke the Transactions API using the Amazon API Gateway.
As Lambda is evented, the HTTP endpoints exposed via the Amazon API Gateway will act as the event to trigger the function synchronously. If you have been following the earlier two posts, by the end of this post you will be comfortable building RESTful APIs using AWS Lambda, Java, DynamoDB (or any persistence layer), API Gateway - all put together using simple configuration in Serverless Framework.
We continue to build our Lambda functions beyond the Hello World that we saw in the previous post. Our end goal is to build an API, and make it available via Amazon API Gateway. We will build the foundation of our Lambda-API-Gateway set up in this tutorial. We will also set up DynamoDB. Feel free to replace DynamoDB with any persistance layer, or even a mock.