CloudFormation Stack failures
The two most common CloudFormation stack failures customers see are a result of either bad parameters specified within the CloudFormation template or deploying in a non-supported region.
Last updated
The two most common CloudFormation stack failures customers see are a result of either bad parameters specified within the CloudFormation template or deploying in a non-supported region.
Last updated
As the section describes, there are 5 parameters you need to make sure you get right.
Virtual Private Cloud (VPC) ID
Subnet A ID
Subnet B ID
Console Security Group CIDR Block
Ensure that the subnets you select for Subnet A and Subnet B are unique (to each other) and both are a part of the VPC you selected.
Ensure the CIDR range is a value that you can access. Specify a network range that represents the specific network you will be accessing from (i.e,. your work network) or open it up to everyone with a value of 0.0.0.0/0.
Using 0.0.0.0/0 will make it accessible to the outside world. SSL based authentication is in place, but you still may want to consider whether "wide open" is the strategy you want to take.
Antivirus for Amazon S3 uses many native AWS services. Not all AWS services are supported in all AWS regions. Cognito is a service leveraged for authentication and user management, but it is not supported in all regions. Markeplace is not supported in all regions either to use ECS fargate.
Below, you will find a list of supported regions. Please deploy the console to one of these regions.
We've noticed instances of upgrading from v6 to v7 through the console where the upgrade will fail. This is usually because the console doesn't have the proper permissions. The error should look similar to the below failure:
This will cause the outbound rules of your console/load balancer security group to be removed. You'll need to add back outbound rules to the security group and then run the upgrade manually through CloudFormation using the latest v7 CloudFormation template.
In some instances, we have seen CloudFormation lose the order of the events that need to execute in order to stand the console up successfully. One instance where this happens is with the UserPoolUserAdminGroupAttachment creation.
If you encounter an error similar to the one below you'll want to retry your deployment through a new Stack again.
There are some cases where, after failing to update, for example, from versions lower than v6.06, the update fails because you are bypassing major versions and skipping some in-between required resources and permissions added on those major versions. What we have usually seen is:
Versions lower than 6.06: Previous Security groups inbound/outbound rules deletion, check your security group for the ConsoleService: ECS -> Css Cluster, ConsoleService, Configuration and networking, Security group:
Inbound rules should be 443 and 80 for 0.0.0.0/0 if it's public and restricted for your VPN/Proxy/IP range if it's private.
Outbound rules should be all traffic for 0.0.0.0/0. Once this is checked, you can go back to CloudFormation > Stack Actions > Continue Update Rollback. Advanced troubleshooting:
If it fails, click on View Root Cause. If that shows you UserPool failed, click on Continue update rollback again in stack actions and check only the UserPool checkbox.
If you are still having issues after ensuring these two criteria are met, please .
If you are upgrading from v6 to v7, make sure you are on the .
If the rollback completes: Good, you can try updating the stack again with .
This should be the last step, and everything should go back to normal. You can then update to the same way and then go to the through the CloudStorageSecurity Console or through CloudFormation once again.
