Amazon RDS Posts

Stack policies are among the most helpful features of AWS CloudFormation for protecting your stacks from unintended updates. Let’s say that you have an Amazon RDS instance that you manage with AWS CloudFormation. After a while, you change one of its attributes and update your stack. Guess what! The update you considered innocent was not so after all. It replaces your database instance with all the data inside. It’s a nightmare, isn’t it? So, you wish there were a CloudFormation feature preventing this from happening.

Luckily, CloudFormation has stack policies to help you in situations like this. In this post, I will talk about stack policies and how to use them as a supplementary protection mechanism in your stack updates. Read more at AWS CloudFormation Stack Policy Conditions: Don't Replace or Delete My DB Instances on Stack Updates post.

Where do you keep your DB credentials in your AWS Lambda functions that you use to access your Amazon RDS databases? Hardcoded? No! Environment variables? Well, you might be using AWS Secrets Manager, right? It would be great! But did you know that you can also use the IAM role of your AWS Lambda function and its temporary credentials to do this?

Yes, there are different ways to manage your database credentials in your AWS Lambda functions. In this post, I will talk about one of the most secure methods, using IAM authentication of Amazon RDS, with an example of an AWS Lambda function developed in Python. I will use an Amazon RDS - MySQL DB instance, but IAM authentication is also supported on PostgreSQL DB instances as well. Read more at AWS Lambda IAM Authentication for Amazon RDS With Python: Secure, But Limited post.

Amazon RDS is the managed relational database solution of AWS. You leave the setup and maintenance of your database to AWS and focus on building applications using it. You can launch and maintain community edition MySQL, PostgreSQL databases as well as commercial Oracle and SQL Server databases on Amazon RDS. However, a few years ago, AWS developed its own cloud-native, enterprise-level database engine called Amazon Aurora, which provides MySQL and PostgreSQL compatibility. In this post, I will discuss some of Aurora’s unique features and why you should use it instead of an Amazon RDS DB instance with community edition MySQL or PostgreSQL databases.

Recently, AWS also launched the serverless and multi-master versions of Amazon Aurora, and any of these features can alone be the reason to choose it. However, in this post, we will focus on single-master Aurora deployment and its advantages over RDS. Read more at Why Choose Amazon Aurora Over Regular RDS? post.

Having a Ruby on Rails background, I got excited to try Ruby to code my AWS Lambda functions when its support for AWS Lambda was announced at Re:Invent 2018. Finally, to try Ruby on AWS Lambda, I developed a simple API using AWS Serverless Application Model (SAM) to access an Amazon RDS MySQL database. I wanted to compare it with my experiences of doing this with Python and Node.js.

Although it may seem simple, installing mysql2 gem as a dependency proved itself to be challenging than others, because it has native extensions and depends on the environment you use bundler. As always, Docker simplifies our job by providing a similar environment that our AWS Lambda function runs inside.

In this post, I will make an introduction to AWS SAM CLI and using Ruby for AWS Lambda functions. Let’s begin! Read more at Serverless APIs With Ruby, AWS Lambda & AWS SAM CLI: Accessing Amazon RDS post.

AWS CloudFormation provides a handful of pseudo parameters which you can use along with your template conditions and parameters to increase the reusability of your templates. One of them is the AWS::NoValue parameter which acts as the null value in programming languages.

In this post, I will talk about some examples of its use cases.