Abstract: With the infrastructure platform growing, the number of secrets in the AWS Secrets Manager increases. This article provides the solution to effectively backing up and restoring them.
Introduction This article continues the work regarding providing the possibility for bulk backing up and restoring SSM parameters and secrets. It has the same motivation and design considerations as in the case of parameters. Here we will mention this information in brief, and in case if you would like to read about it more - you can find more information here.
Abstract: With the growth of the infrastructure platform number of SSM parameters increases. This article provides the solution to effectively backing up and restoring them.
Introduction After the creation of infrastructure in the DR scenario or during regular DR tests, developers spend a sizeable amount of time copy-pasting SSM parameters from existing environments. For example, some applications can have 50 SSM parameters to fill (!). Partial or full automation of this step allows developers to save time and effort, opening the possibility to work on other DR-related activities or to simply finish DR tests earlier.
Abstract: Working with an established infrastructure platform includes performing complex deployments requiring careful planning and execution. Static documents, in this case, are unsuitable and can easily result in production incidents. This challenge can be solved by using a custom interactive runbook solution.
Introduction After the initial creation of the infrastructure in the production environments, all subsequent work is devoted to supporting the platform evolution by performing iterative changes. The requirement to do it with minimum downtime can lead to complex multistep deployment procedures, which require thorough planning to avoid production incidents and unexpected platform downtime.
Abstract: A natural evolution of the growing platform is splitting it into almost isolated pieces of the infrastructure deployed from separate TF repositories. These TF repositories contain a lot of similar code, and having a template makes their creation easy and fast, as well as provides additional benefits.
Introduction Having infrastructure monorepo for the whole platform works well in its early life stage but usually creates challenges during its growth.
Abstract: Global infrastructure platform, which uses shared modules, is demanding Terraform to provide a global cache solution for saving disk space and developers’ time, which directly translates to cost savings. Due to the absence of an out-of-the-box solution baked into Terraform, the custom global cache has been developed. It significantly saves time to perform TF init process and dramatically reduces TF cache size by making it shareable across all TF repositories and environments.
Abstract: This article proposes a simple CD pipeline solution for your applications, which run in AWS Fargate, and uses AWS Developer Tools and ECS. Pipeline design considerations and their architecture are discussed. Necessary changes to the application resources provisioning code are proposed. Source code is provided.
Introduction Note: This article assumes that you have solid experience in AWS Developer Tools, AWS Fargate, Terraform and bash scripting.
In my previous articles I described solutions for: