VPC and subnet CIDR block parameters should not be required if vpc-id and subnet-id parameters are specified

[julian-price]

We have a requirement to install the DLT in a separate separate VPC with an elastic IP, because all IP traffic needs to be whitelisted on the target application that is being tested.

When deploying the DLT in an existing VPC and subnets, which is achieved by supplying the vpc-id and subnet-ids as parameters, all the other VPC and subnet CIDR parameters must be entered, even though they are subsequently ignored in the CloudFormation template.

This behaviour is confusing as the CloudFormation template makes it sound like the parameters will be used and must be valid values, but in reality they are not.

A better behaviour would be to only require the CIDR parameters if the vpc-id and subnet-ids are not supplied, or at least to note in the parameter descriptions that the CIDR blocks are only used if no vpc-id and subnet-id parameters are supplied.

Note also that there is a typo in the parameter defaults - both subnet A and B parameters have the same description, but the second should say "Subnet B CIDR Block":

      SubnetACidrBlock:
        default: AWS Fargate Subnet A CIDR Block
      SubnetBCidrBlock:
        default: AWS Fargate Subnet A CIDR Block

[kamyarz-aws]

I added this to our backlog and will resolve it in the next release.