v1.9.2-b

This release of the configuration files has been tested with v1.9.2 of the Landing Zone Accelerator on AWS

Added

• feat(docs): Updated architecture documentation and diagrams

Changed

• feat(network): This change will cause a disruption to ingress and egress traffic and therefore must be carefully planned to minimize disruption to workloads. We have made the decision to move the network firewall north of the Perimeter-NAT subnets to enable two outcomes for customers: 1. Allow customers to deploy internet facing appliances in the Perimeter-NAT subnets directly, without the need for ALB/NLB, whilst still being protected by a boundary device. This requirement supports products that are expected to sit at the edge and have multiple inbound ports open to support their application, which is currently not support by ALB/NLB's; 2. Allow the edge boundary device to see the public address ranges of the connections being established to the perimeter account. In the previous pattern the network firewalls sat south of the ALB/NLBs causing them to see the private addresses of connections and requiring administrators to work with X-Forwarded-For headers to see the public IP addresses. With this change customers will see the public IP addresses and can directly use their own IP threat lists to control traffic into the perimeter. To implement this optional change customers will need to make the changes in two phases. Detailed instructions to make the changes can be found here. Note: the time of the disruption will based on performing two full pipeline runs, please factor this in when scheduling the change.
  • This optional network config change to use VPC Ingress Routing may affect firewall rules that depend on workload source IP because the source IP will now show the NAT Gateway's IP. An example use case impacted by this would be if a firewall rule blocks egress traffic for dev IPs, but not prod IPs.