De-risking Deployments in AWS

Answer - A.

After you have your stacks and resources set up, you can reuse your templates to replicate your infrastructure in multiple environments.

For example, you can create environments for development, testing, and production so that you can test changes before implementing them into production.

To make templates reusable, use the parameters, mappings, and conditions sections so that you can customize your stacks when you create them.

For example, for your development environments, you can specify a lower-cost instance type compared to your production environment, but all other configurations and settings remain the same.

For more information on Cloudformation best practices, please refer to the below link:

The question is asking how to de-risk deployments at a company by addressing accidental inconsistencies between Staging and Production environments in AWS, beyond using Docker to ensure consistency of the application environment on EC2 instances.

Option A suggests developing models of the entire cloud system in CloudFormation and using this model in both Staging and Production to achieve greater parity. CloudFormation is a service that enables the user to model and provision AWS resources as code, and provides a way to automate the creation and management of resources across different environments. By using CloudFormation to create a template that defines the infrastructure and configuration of resources, it is possible to provision identical resources in Staging and Production environments. This would help to ensure consistency and reduce the risk of issues due to differences between the two environments.

Option B suggests using AWS Config to force the Staging and Production stacks to have configuration parity. AWS Config is a service that enables the user to assess, audit, and evaluate the configuration of AWS resources. By using AWS Config to monitor the configuration of resources in both Staging and Production, any differences between the two environments can be detected, enabling the user to address them before they cause issues in Production. This approach can help to reduce the risk of issues arising from configuration differences between Staging and Production.

Option C suggests using AMIs to ensure the whole machine, including the kernel of the virtual machines, is consistent since Docker uses Linux Container (LXC) technology. An AMI (Amazon Machine Image) is a pre-configured virtual machine image used to create an EC2 instance. By using AMIs, it is possible to ensure that the entire machine, including the kernel, is consistent between Staging and Production environments. This approach can help to reduce the risk of issues caused by differences in the underlying machine environment.

Option D suggests using AWS ECS (Elastic Container Service) and Docker clustering to ensure that the AMIs and machine sizes are the same across both environments. AWS ECS is a fully-managed container orchestration service that enables the user to run Docker containers on a cluster of EC2 instances. By using AWS ECS and Docker clustering, it is possible to ensure that the same AMIs and machine sizes are used in both Staging and Production environments. This approach can help to reduce the risk of issues caused by differences in the container environment.

In summary, there are multiple ways to further de-risk the execution environment beyond using Docker to ensure consistency of the application environment on EC2 instances. These include using CloudFormation to create identical resources in Staging and Production environments, using AWS Config to monitor and evaluate the configuration of resources in both environments, using AMIs to ensure consistency of the entire machine environment, and using AWS ECS and Docker clustering to ensure consistency of container environments.