I prefer creating the base AMI using packer; RDS snapshot using a Jenkins job which get triggered whenever there is a change in the database schema in the SCM. In case of installers, binaries, etc. it would be best to store them in a single S3 bucket. In all the above mentioned scenarios I prefer to share those resources to a 3rd party AWS account and remove the share when not needed. Read more

It’s a general best practice to manage all DNS entries in Route53 in a centralized AWS account. In that case it is difficult to automate the DNS record creation/deletion based on resources created in another AWS account using CloudFormation. CloudFormation doesn’t yet have the capability to create resources in a different AWS account. Combining IAM role delegation, AWS Lambda & CFN Custom resources provides us a solution. I have extended the same solution by exposing the Lambda function through API gateway which provides a powerful mechanism. Read more

In most cases we create custom AMI’s for various reasons like OS hardening, installing and configuring additional software, etc. If you use single AWS account to create the AMI’s and share it with other AWS accounts and use that as part of CloudFormation template, it is required to pass the new AMI Id every time. AWS Lambda comes handy for easy and elegant solution to get the latest AMI Id based on the AMI name and owner. Read more