To prevent deployment of the potentially sensitive resources or infrastructure into the AWS account that might not meet current organizational security standard we can use AWS CloudFormation custom resource to perform quick security audit (or kind of sanity check) of the cloud account before processing with deployment.
Why we need this if we can scan/audit account as a part of the CI/CD pipeline? For the cases when deployments are performed manually or to have CI/CD independent "portable" CloudFormation template that has all security checks built-in and not bolt-on.
How it will look like:
- To you normal CloudFormation template you will add a custom resource.
- This custom resource it technically speaking a Lambda function that created and called during CloudFormation stack deployment.
- This Lambda function will perform quick (to meet CloudFormation deployment timeouts restrictions) security audit of the account where template going to be deployed
- As result of this audit Lambda will return status that will be interpreted by CloudFormation as a resource creation outcome.
- If AWS environment pass security check - deployment of other resources in you stack continue as usual
- If AWS environment fail security check - stack deployment will interrupted and rolled back as a result of the custom resource failure.