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 Serviceartifact 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
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 Lambdastage 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 CloudWatchstage AWS CloudFormation stack.
Option 2: Retain the stage CloudFormation stack
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.
