Architecture overview - Multi-Region Infrastructure Deployment

Architecture overview

Deploying this solution builds the following environment in the AWS Cloud.

The solution’s AWS CloudFormation template deploys a continuous integration/continuous delivery (CI/CD) pipeline in the primary Region using AWS CodePipeline.

AWS CodePipeline automatically detects changes in the GitHub repository and pulls the current source code from GitHub, encrypts and stores the code in the Amazon Simple Storage Service (Amazon S3) artifact bucket, and pushes it through a series of validation steps and deployment stages.

When you deploy the AWS CloudFormation template, you have the option to either retain or delete the stage AWS CloudFormation stack. The following sections detail both deployment options.

Option 1: Delete the stage CloudFormation stack


        Multi-Region Aynschronous Object Replication Solution architecture diagram when the stage stack is deleted

Figure 1: Multi-Region Infrastructure Deployment architecture when the stage stack is deleted

The stage stack can be used in two ways: either as a temporary environment to support change validation or as a permanent environment to reflect the production codebase. The following workflow occurs when you choose to delete the stage stack after manual approval.

When a change is pushed to the GitHub repository, an AWS Lambda function checks the AWS Systems Manager parameter to determine if there is an existing AWS CodePipeline artifact for the stage AWS CloudFormation stack. If the artifact exists, the stage AWS CloudFormation stack uses the artifact to launch the initial stage AWS CloudFormation stack. If the artifact does not exist, the stage AWS CloudFormation stack uses the current source code to launch the initial stage AWS CloudFormation stack. Then, an AWS CloudFormation change set is created and an AWS Lambda function is invoked to check if the changes will result in a change to your production infrastructure. When initially deployed, there is no change, so the AWS Lambda function is skipped. The AWS CloudFormation template from your GitHub repository is then validated with security and style checks using cfn-nag and cfn-lint. Once validated, the stage AWS CloudFormation stack updates to the latest AWS CloudFormation template and an AWS Lambda function detects drifts on the primary and secondary stacks. Then, the template must be manually approved in the AWS CodePipeline console. Once approved, the stage AWS CloudFormation stack terminates and the primary AWS CloudFormation stack in the primary Region and the secondary AWS CloudFormation stack in the secondary Region deploy.

If the AWS CloudFormation template is rejected, an Amazon CloudWatch event triggers and an AWS Lambda function terminates the stage AWS CloudFormation stack.

Option 2: Retain the stage CloudFormation stack


          Multi-Region Aynschronous Object Replication Solution architecture diagram when the stage stack is retained

Figure 2: Multi-Region Infrastructure Deployment architecture when the stage stack is retained

The following workflow occurs when you choose to retain the stage AWS CloudFormation stack after manual approval.

When a change is pushed to the GitHub repository, an AWS CloudFormation change set is created and an AWS Lambda function checks if the changes will result in a change to the infrastructure. The AWS CloudFormation template from your GitHub repository is then validated with security and style checks using cfn-nag and cfn-lint. Once validated, the template deploys to a stage AWS CloudFormation stack in the primary Region, and an AWS Lambda function detects drifts to the primary and the secondary AWS CloudFormation stacks. The template must be manually approved in the AWS CodePipeline console. Once approved, the the primary AWS CloudFormation stack in the primary Region and the secondary AWS CloudFormation stack in the secondary Region deploy.

If the AWS CloudFormation template is rejected, an Amazon CloudWatch event triggers, and an AWS Lambda function reverts the stage AWS CloudFormation stack to the previous infrastructure. If there is no stage artifact information in the AWS Systems Manager parameters, the stage AWS CloudFormation stack terminates, since there are no primary nor secondary AWS CloudFormation stacks.