This small release introduces custom stages, stage-level configuration overrides, instant rollbacks and a few other refinements for Up the serverless deployment tool.

Over the years “DevOps” has become quite the buzzword. It’s been used to describe culture changes, automation, change management, continuous delivery… essentially, a culture where dev and ops collaborate to build a faster, more reliable release pipeline.

In our previous posts, I showed you how to copy your DB and Aurora snapshots to ensure they are preserved beyond the lifetime of your RDS instance. However, those copies were simply second copies in the same region as the original. In this post, I’ll show you how to copy your RDS snapshots to a second region for extra protection. Please note that I will restrict this post to unencrypted snapshots. Copying encrypted snapshots is more involved, so I’ll show that in a separate post.

RDS snapshots can be unencrypted or they can be encrypted at rest. Today, best practice is to use encryption-at-rest on your RDS instances and clusters, and to encrypt your RDS snapshots. When you create an RDS snapshot from an RDS instance or cluster, the resulting snapshot will be encrypted if the source instance or cluster is encrypted. But if the source is not encrypted, then your RDS snapshot is not encrypted. When you create an RDS snapshot, you are not given the option to encrypt it.

RDS DB snapshots are snapshots created from Amazon RDS DB instances. Those being MySQL, PostgreSQL, MariaDB, Oracle, and Microsoft SQL Server. Amazon Aurora also has snapshots, however, those are considered “cluster snapshots” and are handled differently.