Deployment Phases

All commands run from the source demo repository root. Complete Pre-flight checks before each apply.

Phase 1 — All VPCs

Why this phase runs first

The network account’s cross-account-auth module creates a VPCAssociationAuthorizationVPCAssociationAuthorization
CreateVPCAssociationAuthorization — network account permits a specific VPC (id + region) in another account to associate with the PHZ. for each workload VPC. That requires the target VPC to already exist with a real vpc_id. Workload VPCs must exist before network can authorize them in Phase 2a.

Deployment flags

Every stack in Phase 1 deploys VPC only:

Stack	Flags
network	enable_phz=false, enable_cross_account_auth=false, enable_test_ec2=false
network-apse6, all workload stacks	enable_zone_association=false, enable_test_ec2=false

Apply order

Apply workload stacks first (any order), then network-apse6, then network. Example — dev-apse2:

export AWS_PROFILE=r53demo-dev
aws sts get-caller-identity

terraform -chdir=terraform/accounts/dev-apse2 init
terraform -chdir=terraform/accounts/dev-apse2 validate
terraform -chdir=terraform/accounts/dev-apse2 apply \
  -var="enable_zone_association=false" \
  -var="enable_test_ec2=false"

terraform -chdir=terraform/accounts/dev-apse2 output vpc_id

Repeat for: dev-apse6, sandbox-apse2, sandbox-apse6, network-apse6, and network (with network-specific flags above).

Expected Phase 1 signal: vpc_id populated; test_ec2_instance_id empty; zone_id empty on network.

Capture outputs

Save all four workload VPC IDs for Phase 2a in terraform/accounts/network/terraform.tfvars:

dev_apse2_vpc_id     = "vpc-xxxxxxxx"
dev_apse6_vpc_id     = "vpc-xxxxxxxx"
sandbox_apse2_vpc_id = "vpc-xxxxxxxx"
sandbox_apse6_vpc_id = "vpc-xxxxxxxx"

Authorization specificity

Authorization_SpecificityAuthorization_Specificity
Each authorization binds to exact `vpc_id` and `vpc_region` — recreated VPCs need re-authorization in Phase 2a.

applies: if a workload VPC is destroyed and recreated later (new vpc_id), update network/terraform.tfvars and re-apply Phase 2a before Phase 3.

---

Phase 2a — Network PHZ and authorizations

Why this phase runs second

Route 53 requires the Platform_ZonePlatform_Zone
Shared private hosted zone `platform.demo.local` in the Network_Account — the only place `api` and `db` records are defined. to exist and (for cross-account VPCs) a matching VPC_Association_AuthorizationVPC_Association_Authorization
CreateVPCAssociationAuthorization — network account permits a specific VPC (id + region) in another account to associate with the PHZ. per exact vpc_id and vpc_region. See Association Scenarios.

Phase 2a creates:

• The PHZPHZ
  Private Hosted Zone — resolves DNS only from associated VPCs. This demo uses one authoritative PHZ in the network account. and A records (api, db)
• Same-account secondary VPC association (no authorization)
• Four cross-account authorizations
• Two Test EC2Test EC2
  One minimal EC2 per stack (seven total) for in-VPC DNS checks via SSM Session Manager and `dig`. instances in ap-southeast-2

Apply network stack

export AWS_PROFILE=r53demo-network
aws sts get-caller-identity

terraform -chdir=terraform/accounts/network init
terraform -chdir=terraform/accounts/network validate
terraform -chdir=terraform/accounts/network apply \
  -var-file=terraform/accounts/network/terraform.tfvars

terraform -chdir=terraform/accounts/network output zone_id

Expected Phase 2a signal: zone_id populated (copy from terraform output zone_id); test_ec2_instance_id_primary and _secondary populated.

Capture zone_id

Set zone_id in terraform.tfvars for network-apse6 and all four workload stacks:

zone_id = "Z0xxxxxxxxxxxx"

---

Phase 2b — Network ap-southeast-6

Why this is separate

Same-account cross-regioncross-region
VPCs in ap-southeast-6 associate with a PHZ in ap-southeast-2 — Route 53 resolves shared records across regions from one zone. association does not require VPCAssociationAuthorization — only zone_id.

export AWS_PROFILE=r53demo-network
aws sts get-caller-identity

terraform -chdir=terraform/accounts/network-apse6 init
terraform -chdir=terraform/accounts/network-apse6 validate
terraform -chdir=terraform/accounts/network-apse6 apply \
  -var-file=terraform/accounts/network-apse6/terraform.tfvars

terraform -chdir=terraform/accounts/network-apse6 output

Expected signal: test_ec2_instance_id populated; association active for ap-southeast-6 VPC.

---

Phase 3 — Workload associations and Test EC2

Why this phase runs third

Cross-account associations require Phase 2a authorizations. AssociateVPCWithHostedZoneAssociateVPCWithHostedZone
AssociateVPCWithHostedZone — workload account links its VPC to an authorized private hosted zone so the VPC resolver can query shared records. without a matching authorization returns AccessDenied.

Flag	Value
enable_zone_association	true
enable_test_ec2	true

Run Phase 3 pre-flight before applying.

Apply each workload stack

Example — dev-apse2:

export AWS_PROFILE=r53demo-dev
aws sts get-caller-identity

terraform -chdir=terraform/accounts/dev-apse2 init
terraform -chdir=terraform/accounts/dev-apse2 validate
terraform -chdir=terraform/accounts/dev-apse2 apply \
  -var-file=terraform/accounts/dev-apse2/terraform.tfvars

terraform -chdir=terraform/accounts/dev-apse2 output

Repeat for dev-apse6, sandbox-apse2, and sandbox-apse6 with the matching profile (r53demo-dev or r53demo-sandbox).

Phase 3 complete

After Phase 3, seven Test EC2Test EC2
One minimal EC2 per stack (seven total) for in-VPC DNS checks via SSM Session Manager and `dig`. instances exist across all association scenariosassociation scenarios
One of four demo paths: cross-account same-region, cross-account cross-region, same-account cross-region, or same-account same-region.. Proceed to Verification.

Next step

Verification — seven DNS tests with expected dig output.