After posting the previous post on this topic (Copying RDS snapshot to another region for cross-region recovery), I noticed a lot of people being interested in using the code I provided as an example. Many were not sure how to make use of it, and after a couple of pull requests it became obvious that a complete, fully-working code and CloudFormation template would be a good idea. So, yesterday, I pushed an update to aws-maintenance repository with a fully working code, which you can easily customize via CloudFormation parameters to match your needs.
Each Amazon Machine Image (AMI) holds information of the volumes and snapshots of those volumes that should be attached to instances created from that AMI. To protect the data on those snapshots, you can choose to encrypt them using KMS. Encrypting your data at rest is generally a good idea, though many companies choose to avoid encrypting their snapshots, because sharing such snapshots between different AWS accounts (for example, Test and Production accounts) can be difficult. That’s why I’m sharing details on how to make this as easy as possible (and automated!).
Enabling logging in API Gateway for your stage is fairly easy. You go into the Console, setup a role for API Gateway to use for logging, find the stage and enable logs. It will enable logging for all methods within that stage. Doing the same configuration using CloudFormation is not completely obvious though, as the stage object’s
MethodSettings property seems to allow you to only do that for a specific resource and method.
When deploying infrastructure with CloudFormation, at some point you will reach a moment when your CloudFormation JSON or YAML file is just too big. It will be too long to get a good overview of what’s in it, manage parameters and all dependencies between resources within the template. Nested stacks may be a solution, but if sometimes you can’t/won’t/don’t use them for whatever reason (for example, it will get to complicated to manage tested stacks or their contents are not reusable between other stacks).
Even if you’re using troposphere to generate your templates, you’ll face the same issue – a very long Python file. Luckily, if you are using troposphere, you’re inherently using Python – which means you can take advantage of it.
Interested in getting a bit more hands-on with AWS? My first video course prepared with Packt Publishing, exploring server-based (more “classic”) AWS components, like EC2 instances, VPC, RDS, ElasticCache, S3 and even ECS and ECR for running docker containers has been published!
The course is meant for people who have used AWS before and have basic familiarly with their services and would like to get their knowledge onto “the next level” (maybe a more practical one!). I tried to include bits of know-how, various tips and tricks and gotchas that I found during my experience with AWS so far.
If you’re interested, check out the course on Packt Publishing website!