add lab-dmz.md

aws/documentation/transit-gateway/lab-dmz.md

@@ -0,0 +1,166 @@
+# Lab DMZ Networking
+
+# Links
+
+* [DMZ Tunnel Tracker](dmz-vpn-tunnel-tracker.csv)
+* [Lab](lab.md)
+
+## Concepts and Capabilities
+
+* needed environment segments
+  * common/services/shared
+  * test
+* create new VRFs for lab-dmz-X above
+* establish network addressing blocks for the TGW connections
+* determine where to place the Lab DMZ networking (existing TGW, new TGW and peering)
+  * we have decided a separate account and new TGW
+* network addressing for subnets used in Lab DMZ, both regions
+* creating VPN configurations for at least 2 vpn connections (4 tunnels, 2Gbps aggregate) per env per site per region
+  * these come from templated code built from VPCs attached to TGW
+* understand connectivity requirements. This will be something per application
+  * from on prem
+  * from current aws (now called "lab-internal")
+  * from internet (while not available, it is important to know)
+  * to on prem
+  * to current aws
+  * to internet
+* establish and document general security pattern for apps in Lab DMZ consistent with on-prem
+  * extremely limited to no inbound access (inbound to internal on prem or cloud)
+  * ok with on-prem dmz
+  * prefer/recommend outbound (from on prem or internal aws) to dmz
+  * all components reside in the DMZ (multi-tier, middle, DB)
+  * no direct access to internal on prem or aws DBs
+* all these "to" will be limited as we treat this as an actual Lab DMZ vs Lab AWS current as an extension of the network
+* these connections to current aws stuff will be quite a challenge as we cannot just route from one env to a dmz env without some sort of FW
+* how will dns work within this new isolated configuration
+  * sharing of route53 inbound endpoints
+  * outbound endpoints
+  * view-like capability, where  zone in the dmz has diff data from a zone internal
+* new OU for DMZ, not sure at what level
+
+## Architecture
+
+The TGW architecture will be multi-region, and generally is configured as follows:
+
+1. New AWS account lab-gov-dmz-network-nonprod
+1. TGW in each region
+1. Share TGWs to Lab-GOV-DMZ OU
+1. TGWs peer to each other
+1. One VPC per environmment (enclave) per region, currently (lab by definition is not stage or prod, and no dev in DMZ):
+   * common, services, shared (dmz-common)
+   * test (dmz-test)
+1. A new VRF on-prem for each of the above environments (lab-dmz-services, lab-dmz-test)
+1. Each VPC has a small /23 IPv4 CIDR block.  No workloads will be permitted here, but we are allocating some address space for both connectiity and
+performance testing, as well as for some potential future use.  Each is comprised of:
+   * /28 tgw-attachment subnets, one per AZ (up to 8, using a /26 for this), where the attachment is the only thing on the subnet
+   * /28 endpoint subnets, one per AZ (up to 8, using a /26 for this), for a maximum of 12 endpoints (this should a small number of endpoints)
+   * /26 apps subnets, one per AZ (up to 8, using a /24 for this), for testing and performance related activities.
+1. (TBD) Each VPC will be assigned a /56 IPv6 CIDR block.  The same configuration applies as above, with the exception that each subnet is a /64
+   * tgw-attachments subnets (aggregated to /61, allowing 8 AZs)
+   * endpoint subnets (aggregated to /61, allowing 8 AZs)
+   * apps subnets (aggregated to /61, allowing 8 AZs)
+   * free space, next /61
+   * free space, remainder of blocks
+1. One VPC route table per VPC for tgw-attachments
+1. One VPC route table per VPC for everything else
+1. One TGW route table per VPC (environment/enclave)
+1. One TGW route table per environment/enclave
+1. One TGW route table per region for inter-region traffic (to reach other region(s))
+1. For IPv4, Two or more VPNs per site (BCC, HQ) per environment/enclave, through DirectConnect.  Initial proposal is (18):
+   * common 2
+   * test 2
+1. (TBD) For IPv6, repeat the setup as with IPv4.  VPN tunnels for IPv6 use only IPv4 endpoints, but carry IPv6 traffic.
+
+## Diagrams
+
+![Transit Gateway with Lab DMZ](images/tgw-networking-lab-dmz.png)
+
+## TGW Configurations
+
+* lab-dmz-network-nonprod  
+
+Because we need to establish the same network connectivity like we have for the Lab AWS "internal", we will create a TGW configuration in for the Lab DMZ
+
+## Network Allocation :: Lab DMZ GovCloud
+
+(UPDATE NEEDED)
+
+We need a 10.x/14 block (4 consecutive 10.x/16 blocks) for the DMZ, minimally.
+
+1. East 10.{x}/15
+2. West 10.{x+2}/15
+
+For each of these blocks, we will have this layout.  We can also consider using a completely different CIDR for the TGW attachment blocks, for
+which we will need another /16.  Ideally, it would be aggregatable to the "DMZ" set of networks.
+
+1. TGW attachment and supporting configurations as /23 blocks (usually), allows for 16 /23s or a mixture of that and larger, in us-gov-east-1 10.136.0.0/19 and us-gov-west-1 10.136.32.0/19
+   1. 0.0/23 dmz-tgw-common
+   1. 2.0/23 dmz-tgw-test
+   1. 8.0/22 dmz-tgw-endpoints
+   1. 12.0/22 (free)
+   1. 16.0/21 (free)
+1. Shared VPCs are in us-gov-east-1 10.132.0.0/15 and us-gov-west-1 10.134.0.0/15
+   1. 0.0/20 dmz-services
+   1. 16.0/20 dmz-common
+   1. 32.0/20 dmz-shared
+   1. 48.0/20 (free)
+   1. 64.0/19 dmz-test
+1. The next block 10.{x+1} is for expansion
+
+# Network Assignments :: Lab DMZ GovCLoud
+
+## Assignments
+
+## TGW Attachments
+
+## TGW Attachment VPCs
+
+* us-gov-east-1 
+
+* us-gov-west-1 
+
+## Shared VPCs
+
+* us-gov-east-1 
+
+* us-gov-west-1 
+
+## TGW Route Tables
+
+Just as in the AWS internal configuration, we will have a TGW route table for each environment, and another one for the the VPN per environment:
+
+1. dmz-tgw-common
+1. dmz-tgw-test
+1. vpn-dmz-tgw-common
+1. vpn-dmz-tgw-test
+
+VPN connectivity will be established to each of these.
+
+We will allocate new [tunnel collection numbers](tunnel-numbers.md#values-tunnel-collection) and new [environments](tunnel-numbers.md#values-environment) for the DMZ.
+These will be used for the new tunnel numbers.
+
+Each of the new VPNs will have a new ASR endpoint. We may wish to shut down some old tunnels to make way for new addresses.  We will need one ASR public IP
+per each environment per region per site.  So, 8 148.129.163.x for HQ tunnels (4 west, 4 east) and 8 148.129.78.x for BCC tunnels (4 west, 4 east).
+
+## Routing
+
+We will use managed prefix lists, shared to the DMZ accounts, for routing.  One list will be for VPN back to on-prem, which should contain the list of available
+CIDR blocks via VPN.  I do not know if connectivity to any Azure networks are required, though it is possible the common services may need so for
+various AD or ADFS communications.
+
+As with the AWS internal configuration, all DMZ environment are routable to the services/common networks, and then only to their own environment (stage to stage, etc.).
+
+Routing between DMZ and non-DMZ will require some research and design work.  It is likely to be an inspection-type VPC with AWS firewall and Gateway Load Balancers.
+Short term may use AWS PrivateLink to expose specific things within the internal AWS environment.
+
+We are likely to see blackhole routes used for this DMZ configuration to prevent traffic flowing where we don't want it.
+
+## TGW Peering
+
+This will create two sets of TGWs, one set in non-DMZ and one in DMZ.  We want connectivity among these to go through some security capability.  Early
+testing of this setup may involve using TGW peering among all 4 TGWs and specific routes on the TGW route tables to/from the systems (through prefix lists).
+
+# CHANGELOG
+
+* 1.0.0 -- 2025-01-30
+  - copy from dmz.md