Amazon RDS Proxy is a service from Amazon Web Services (AWS). It's a fully managed, highly available database proxy for Amazon Relational Database Service (RDS) that makes applications more scalable, more resilient to database failures, and more secure.  What I like most about RDS Proxy is its ability to speed up recovery from RDS failovers, from as much as 10 minutes down to 15 seconds or less. I'm sure all you SREs and TPOs will appreciate this too.

That sounds great, right?  Well, the truth is RDS Proxy is not easy to set up, and getting the configuration right takes extensive searches of the internet including both AWS documentation and third-party sources, and you STILL may need to contact AWS Technical Support.

I'm going to show you how to set up RDS Proxies via ClickOps, both for a new environment and for adding a new service. Future articles will cover CLI and TerraForm approaches.

Overview

As a member of the DevOps/SRE team at Bitovi, I was asked by one of our Bitovi clients to investigate POC RDS Proxy for use in a large-scale microservices system.  After trial and error and time spent on a call with AWS support to better understand a cryptic error message or two, I was able to get things working well.  From that experience, I built a procedure to set up an RDS Proxy between your services and RDS/Aurora clusters with a minimum of time and headaches.  I am sharing that procedure with my fellow infrastructure engineers here.

Below are the steps needed to successfully set up RDS Proxy, as well as some helpful debugging information. First set up your AWS account and your RDS instances if you have not already done so.  To get started on the RDS Proxy-specific steps, you will create Secrets in AWS Secrets Manager in the format required by RDS Proxy.  Next, you will create an AWS IAM Policy and IAM Role.  Then you will be ready to create the RDS Proxy.  Finally, I'll show you some testing ideas so you can be sure everything is working correctly.

This post is a continuation from Part 1, where we set up a test project with NgRx and ngrx-forms in our Angular application. For part 2, we will validate our form.

If your Angular application already uses NgRx, you know the value of writing good reducers and using one-way data flow. However, that knowledge may not be enough to keep the biggest form in your app from being a rat’s nest of FormGroups and related logic. Forget keeping components under 50 lines of code - your form logic alone blows past that.

Last time, we had refactored our basic one-line install of StackStorm and our custom pack into an Ansible playbook. The Ansible playbook works well enough on its own but still requires us to already have a server setup for Ansible to execute the playbook on. What if we didn't need that pre-existing server and were able to on-the-fly provision one for our playbook? This arena is where Infrastructure-as-Code (IAC) initiatives really shine and where I would now like to introduce BitOps.