Create the portable sandbox network, DNS, edge, and TLS foundation

[alexeygrigorev]

Parent epic: #9

Normative spec: 08 — AWS sandbox and Terraform
Resolved topology decision: #25

Scope

In DataTalksClub/aws-infra, create an independent sandbox/website Terraform root and reusable/portable Django website module for the first scaffold deployment at web.dtcdev.click.

• Re-inventory the sandbox account before planning.
• Reference delegated Route 53 hosted zone ID Z05963572WVWFHDQZH5NE explicitly.
• Create only the web.dtcdev.click alias and certificate-validation records owned by this workload.
• Add ACM/TLS, CloudFront, a protected ALB origin, and the routing/header hooks needed by the scaffold.
• Create a dedicated two-AZ VPC using the accepted cost-aware sandbox topology: public ALB subnets, tightly restricted public-IP ECS task subnets without NAT, and isolated private RDS subnets.
• Allow task ingress only from the ALB security group and PostgreSQL only from the task security group. Prevent a useful direct-origin bypass.
• Add workload tagging, constrained Terraform/provider versions, variables/outputs, examples, backend documentation, and production-account inputs.
• Use the sandbox bootstrap's encrypted/locked remote state with an independent key such as sandbox/website/terraform.tfstate.

Non-goals

• No ECR, ECS services, RDS instance, application deployment, SES, S3 content assets, or feature-specific alarms; those belong to Provision the minimum HTTPS-origin scaffold runtime on ECS and RDS #68 or later domain issues.
• No hosted-zone creation, registrar/delegation change, name-only zone lookup, default-VPC reuse, committed state/plan/backend credentials/real tfvars/secrets, or sandbox-state promotion to production.
• No NAT gateway in the accepted sandbox profile; production inputs must still support private tasks plus NAT or VPC endpoints.

Acceptance criteria

• A fresh AWS inventory is recorded before plan review and confirms every reused identifier.
• Terraform uses hosted zone ID Z05963572WVWFHDQZH5NE exactly and owns only web.dtcdev.click plus required certificate-validation records.
• The plan creates no hosted zone, delegation change, default-VPC dependency, or unrelated shared-resource mutation.
• The independent encrypted/locked backend and state key are documented without credentials or state in Git.
• Two availability zones, public ALB, ALB-only task ingress, isolated DB subnets, task-only PostgreSQL ingress, and origin protection match resolved Decision: Approve the cost-aware sandbox network topology #25.
• TLS/CloudFront/ALB routing and application/edge header hooks support web.dtcdev.click without weakening the scaffold's noindex/no-store behavior.
• Module/root inputs contain no fixed account, network, hostname, size, or retention assumptions and a production fixture can plan without sandbox state dependency.
• terraform fmt, validate, lint/static policy checks, and reviewed sandbox plan pass; policy rejects zone creation, public database, open task ports, unencrypted state/resources, wildcard deployment permissions, and committed secrets.

Test scenarios

1. Plan the sandbox root and review every created/changed resource against workload ownership and the exact hosted-zone ID.
2. Negative fixtures for name-only zone lookup, a third same-name zone, open task ingress, public database subnet intent, origin bypass, unencrypted state/resource, and wildcard IAM fail policy.
3. Plan a production-root fixture using a different account, zone, domain, subnet mode, and backend without referencing sandbox resources/state.
4. Verify network reachability contracts: internet→CloudFront/ALB only, ALB→tasks only, tasks→RDS only, and no public task/RDS ingress.

No Playwright surface is created in this issue; deployed TLS/routing/browser verification belongs to #70.

Dependencies

• Depends on scaffold contract Bootstrap the runnable Django/uv foundation and engineering workflow #1 for application port, health paths, and hostname/header behavior.
• Topology decision Decision: Approve the cost-aware sandbox network topology #25 is resolved and no longer blocks implementation.
• Blocks Provision the minimum HTTPS-origin scaffold runtime on ECS and RDS #68, Deploy scaffold images through GitHub OIDC and immutable ECS releases #69, and Deploy and validate the scaffold at web.dtcdev.click #70.

[alexeygrigorev]

Re-groomed for first-scaffold deployment

This issue is now the smallest portable network/DNS/TLS prerequisite for deploying the scaffold now. Feature infrastructure—SES, content assets, outbox/content alarms, and broader operational controls—has been removed and remains in its owning later issues. Dependencies are limited to the scaffold contract in #1 and the resolved sandbox topology in #25.

[alexeygrigorev]

Software Engineer Report

Implemented

• Added reusable modules/django-website and an independent sandbox/website root in a fresh origin/main-based aws-infra worktree. The module has no account, hostname, hosted-zone, CIDR/AZ, port/health, sizing, retention, or environment setting embedded in workload resources.
• Added a dedicated two-AZ VPC with separate public ALB subnets, public-IP sandbox task subnets, and isolated database subnets. The sandbox has no NAT; private tasks with single, one_per_az, or caller-owned endpoint routing remain explicit production inputs.
• Enforced CloudFront-prefix-list-only ALB ingress, ALB-SG-only application ingress, and task-SG-only PostgreSQL ingress. Database route tables have no default route and task SG egress is limited to HTTPS, VPC DNS, and the database SG.
• Added the public ALB/empty target group and /health/live liveness contract. The ALB listener defaults to 403 and forwards only when both web.dtcdev.click and a generated 48-character CloudFront origin header match, preventing a useful direct-origin bypass.
• Added us-east-1 ACM DNS validation, CloudFront TLS 1.2, zero-TTL dynamic behavior forwarding headers/cookies/query strings, edge security headers including X-Robots-Tag: noindex, nofollow, and only the certificate validation plus A/AAAA records in explicitly supplied zone Z05963572WVWFHDQZH5NE. Application Cache-Control/no-store remains authoritative.
• Documented the independent AES256/versioned/native-lock S3 backend key sandbox/website/terraform.tfstate, state/record ownership, operational review commands, and the fresh read-only account inventory.
• Added a different-account/region/domain/zone/network production fixture using private tasks plus NAT and a completely separate backend, with a mock-provider plan proving there is no sandbox resource/state dependency.
• Added dependency-free static policy plus 10 negative fixtures covering zone creation, name-only lookup, a third same-name zone, internet-open task ingress, public database subnet intent, origin bypass, unencrypted backend/resource, wildcard deployment IAM, and a committed secret.

Fresh inventory and plan review

• Read-only inventory on 2026-08-07 confirmed account 817685572750, exact delegated zone Z05963572WVWFHDQZH5NE, regional CloudFront origin prefix list pl-4fa04526, and the bootstrap state bucket controls. A second same-name zone exists, making explicit zone ID use essential.
• No existing web.dtcdev.click record, website state object, ALB, ECS cluster, RDS resource, NAT gateway, matching ACM certificate, CloudFront alias, or WAF ACL existed. The planned 10.83.0.0/20 VPC does not overlap the inventoried default or relay VPCs.
• The reviewed live-account sandbox plan used the configured remote backend with -refresh=false -lock=false, no -out, and made no AWS changes: 48 add, 0 change, 0 destroy. All resources are workload-owned. There are exactly three Route 53 record instances, and each shows zone ID Z05963572WVWFHDQZH5NE; there is no hosted zone, delegation, NAT gateway, default-VPC lookup, compute service, or database instance in the plan.
• A post-plan read confirmed the website state prefix and live web.dtcdev.click record set remain empty.

Verification

• terraform fmt -recursive -check -diff — passed.
• Sandbox terraform init, terraform validate, and reviewed plan — passed with Terraform 1.15.4, AWS provider 5.100.0, and random provider 3.9.0.
• Production fixture terraform validate && terraform test — passed; 1/1 mocked private-task/NAT production plan.
• python3 -m unittest discover -s tests/policy -p 'test_*.py' — passed; 10/10 unsafe fixtures rejected by their expected rule.
• python3 tests/policy/check_terraform_policy.py . and Python bytecode compilation — passed.
• tflint is not installed in the environment; Terraform validation and the repository-specific static policy supplied the lint/policy gate.
• No apply, resource creation, import, state write/copy, saved plan, backend credential, real tfvars, secret input, commit, or push was performed.

Files

• Module: modules/django-website/{network,edge,variables,outputs,versions}.tf and README.
• Sandbox root: sandbox/website/ source, provider lock, example inputs/backend, outputs, README, and INVENTORY.md.
• Portability/policy: tests/fixtures/website-production/ and tests/policy/.

Intentional non-goals

• ECR/ECS services, RDS instance, application secrets, storage, SES, deployment IAM, alarms, and WAF creation remain with Provision the minimum HTTPS-origin scaffold runtime on ECS and RDS #68 or later owning issues.
• No resources were deployed. Deployed TLS/routing/browser verification remains with Deploy and validate the scaffold at web.dtcdev.click #70 as specified.

Changes are left uncommitted and unpushed in /home/alexey/git/dtc-website/.tmp/aws-infra-website-67 for independent tester review.

[alexeygrigorev]

QA Review — PASS

Independently verified the complete uncommitted DataTalksClub/aws-infra worktree at baseline dab40b3 against issue #67, spec 08, resolved topology #25, the website lifecycle, and existing aws-infra root/backend conventions. I made no source edit, apply, import, state operation, commit, push, or pull request.

Candidate and static design audit

• The candidate consists of 34 untracked source files: 6 reusable-module files, 9 sandbox-root files, 6 production-fixture files, and 13 policy/test files. The tracked tree is otherwise unchanged.
• Provider constraints are Terraform >= 1.6.0, AWS ~> 5.0, and random ~> 3.6; both roots lock AWS 5.100.0 and random 3.9.0.
• The module has no fixed account, region, zone, hostname, CIDR/AZ, port, health, sizing, retention, or environment value. The sandbox root supplies explicit environment inputs; the production fixture supplies a different account, region, zone, hostname, CIDRs/AZs, ports, edge settings, private-task mode, single NAT, and separate backend without sandbox state/resource references.
• No hosted-zone resource/data lookup, default-VPC dependency, delegation resource, ECS/ECR/RDS instance, application secret, deployment IAM, storage, SES, or alarm is in scope.
• The dedicated VPC has two ALB, two task, and two isolated database subnets. Sandbox routes comprise one ALB internet route and two public-task internet routes only; database route tables have no default route and sandbox creates no NAT.
• SG reachability is CloudFront managed prefix list pl-4fa04526 → ALB port 80, ALB SG → task SG port 8000, and task SG → database SG port 5432. There is no CIDR-based ingress to tasks or database.
• The ALB default is HTTP 403. Forwarding requires both web.dtcdev.click and the generated 48-character X-Origin-Verify value; CloudFront supplies that sensitive origin header. Viewer TLS is ACM/us-east-1 with TLSv1.2_2021.
• CloudFront has zero TTLs, forwards all viewer headers/cookies/query strings, redirects viewers to HTTPS, and adds X-Robots-Tag: noindex, nofollow plus security headers without replacing application Cache-Control behavior.
• Backend examples use separate keys/buckets, encrypt = true, and native use_lockfile = true. The live sandbox bucket independently verified as us-east-1, versioned, AES256-encrypted, with all four public-access blocks enabled.

Independent validation

• terraform fmt -recursive -check -diff — PASS.
• Sandbox terraform init -backend=false -lockfile=readonly using external project-local TF_DATA_DIR — PASS; no remote backend/state access.
• Sandbox terraform validate — PASS.
• Production fixture terraform init -backend=false -lockfile=readonly and terraform validate — PASS.
• Production mocked terraform test plan — 1 passed, 0 failed; no credentials, APIs, or real state used.
• python3 -B -m unittest discover -s tests/policy -p 'test_*.py' -v — 10/10 passed. Each unsafe fixture was rejected for its expected rule: zone creation, name-only zone lookup, third same-name zone, open task ingress, public database subnet intent, origin bypass, unencrypted backend, unencrypted database resource, wildcard IAM, and committed secret.
• python3 -B tests/policy/check_terraform_policy.py . — PASS.
• tflint is not installed in this environment, so no tflint result is claimed; Terraform validation plus the repository-specific positive/negative policy suite supplied the available lint/static-policy gates.

Fresh live inventory and non-mutating sandbox plan

Before planning, read-only AWS inventory independently confirmed:

• caller account 817685572750;
• delegated public zone Z05963572WVWFHDQZH5NE for dtcdev.click. plus the second same-name public zone Z04966063K9K29ZGHVRYN;
• managed CloudFront origin prefix list pl-4fa04526 in create-complete state;
• no web.dtcdev.click record, no object below sandbox/website/, no website ALB, and no NAT gateway;
• only the known 172.31.0.0/16 default VPC and unrelated 10.82.0.0/24 relay VPC, neither referenced by the candidate.

I initialized the documented S3 backend without migration, then ran the live-account sandbox plan repeatedly only as:

terraform plan -refresh=false -lock=false -input=false \
  -var-file=terraform.tfvars.example

No -out or saved plan was used. Independent JSON-event assertions and text review both passed:

• 48 add, 0 change, 0 destroy/import, with no diagnostics;
• all 48 changes are create actions below module.website.*;
• network subtotal: 34 resources — 1 VPC, 1 IGW, 6 subnets, 5 route tables, 3 routes, 6 associations, 1 DB subnet group, 3 SGs, and 8 SG rules;
• edge subtotal: 14 resources — origin password, ALB/target/listener/rule, ACM certificate/validation, three CloudFront policies, distribution, and three DNS records;
• exactly these Route 53 instances: certificate validation, web.dtcdev.click A, and web.dtcdev.click AAAA;
• plan text shows zone_id = "Z05963572WVWFHDQZH5NE" on all three and no other workload DNS record;
• no aws_route53_zone, NAT gateway, default VPC, ECS resource, RDS instance/cluster, change, destroy, delegation, or unrelated shared mutation.

After all plans, the same read-only inventory showed:

• web.dtcdev.click record set still empty;
• website state prefix KeyCount 0;
• the same two pre-existing VPCs;
• no website ALB, NAT gateway, or CloudFront alias.

This proves the tester run caused no external mutation.

Acceptance and UI scope

All 8/8 issue acceptance criteria are independently verified; they were already checked, so no checkbox edit was necessary. No Playwright run or screenshots were applicable because #67 creates no rendered application surface; deployed TLS/routing/browser verification remains correctly assigned to #70.

Verdict: PASS. Ready for product-manager acceptance.

[alexeygrigorev]

Product / DX Acceptance

Verdict: ACCEPT

Issue #67 is ready for the engineer to commit on the aws-infra issue branch with commit body Closes #67.

Because the implementation commit lives in DataTalksClub/aws-infra while the issue lives in DataTalksClub/website, the cross-repository reference may not auto-close this issue. After the approved branch is merged and pushed, manually close #67 if GitHub leaves it open, linking the resulting aws-infra commit and CI/on-call evidence.

Operator and developer evidence

• modules/django-website/README.md establishes a crisp reusable boundary: network, edge, TLS, origin protection, DNS records, and downstream security-group/subnet contracts only. It explicitly excludes compute, database instances, application secrets, storage, deployment IAM, and product integrations.
• sandbox/website/README.md is actionable for a new operator. It explains ownership and blast radius, the two same-name hosted zones, why the exact zone ID is mandatory, public-task/no-NAT behavior, origin verification, state handling, safe init/validate/plan commands, review points, forbidden artifacts, and the inputs exported to later stacks.
• The backend contract is reproducible and isolated: the bootstrap-owned encrypted/versioned/public-blocked S3 bucket, native locking, and independent sandbox/website/terraform.tfstate key are documented. No backend credentials, generated backend file, real tfvars, plan, state, or secret value is part of the candidate.
• Production portability is demonstrated rather than merely asserted. The fixture changes account, primary region, hostname, hosted zone, CIDRs/AZs, ports, health path, edge settings, task mode, NAT model, and backend; it uses no sandbox state/resource reference and clearly identifies itself as non-deployable mock documentation.
• Inputs are explicit and environment-owned. The reusable module contains no embedded account, zone, hostname, CIDR/AZ, port, health path, size, retention, or environment selection.

Safety, ownership, and downstream usability

• The fresh inventory names the sandbox account, exact delegated zone Z05963572WVWFHDQZH5NE, second ambiguous zone, CloudFront prefix list, backend controls, current collisions, and absence of any pre-existing website record/state/resource requiring import.
• The reviewed plan is appropriately narrow: 48 workload-owned creates, zero changes, zero destroys/imports. DNS ownership is limited to certificate validation plus web.dtcdev.click A/AAAA records in the exact delegated zone. No hosted zone, delegation, default-VPC dependency, compute service, RDS instance, NAT gateway, WAF, SES, storage, deployment role, or unrelated shared mutation leaked into scope.
• The accepted Decision: Approve the cost-aware sandbox network topology #25 topology is represented clearly: dedicated two-AZ VPC, separate ALB/task/database subnet tiers, public sandbox tasks without NAT, no database default route, CloudFront-only ALB ingress, ALB-only task ingress, and task-only PostgreSQL ingress. Production can select private tasks with single/per-AZ NAT or caller-owned endpoint routing.
• Direct-origin protection has two independent controls: the AWS-managed CloudFront origin prefix list and a generated 48-character origin header. The ALB defaults to 403 and forwards only when the expected host and header both match.
• Development indexing/cache safety is preserved: the edge forces X-Robots-Tag: noindex, nofollow; default CloudFront TTLs are zero; viewer auth context is forwarded; and the response policy does not replace Django Cache-Control, leaving no-store semantics authoritative.
• Outputs are sufficient and well-described for Provision the minimum HTTPS-origin scaffold runtime on ECS and RDS #68: task subnet IDs/public-IP mode, task route tables, task/database security groups, database subnet group, target group, VPC/edge/certificate identifiers, and public URL. No sensitive origin header is exported.
• Defaults are intentionally environment-explicit. The sandbox example makes deletion protection, WAF absence, price class, ports, CIDRs, account, region, and no-NAT selection visible instead of hiding them in the module.

Verification relied upon

Independent QA passed formatting, both root validations, the mocked different-environment production plan, 10/10 negative safety fixtures, the repository policy scan, fresh live inventory, and a non-mutating live-account plan. QA also reconfirmed after planning that no DNS record, state object, ALB, NAT gateway, or other AWS resource was created. The absence of Playwright/screenshots is correct because this issue creates no rendered application surface; deployed behavior remains owned by #70.

All eight issue acceptance criteria and the explicit non-goals are satisfied. The module/root are understandable to the next infrastructure implementer, safe to plan, portable to production inputs, and provide the contracts required by #68 without prematurely owning its resources.

[alexeygrigorev]

On-call CI Report

Verdict: NO APPLICABLE CI RUN — manual completion

Verified the exact post-push DataTalksClub/aws-infra commit:

• Target: b5bc86c517283e2ffd2d27db264177f3c92e6cd9
• Remote main: exactly the same full SHA
• Merge contains the focused engineer commit b2b105fcc6fbcd9811eeefa8ad995a5fd4136957 with Closes #67
• Committed scope: the reviewed 34 files below modules/django-website/, sandbox/website/, tests/fixtures/website-production/, and tests/policy/

This is not being reported as a green pipeline. GitHub reports for the exact target SHA:

• Actions workflow runs: 0
• Check runs: 0
• Commit statuses: 0

The repository currently has one active workflow, Deploy shared authentication. Its automatic push filter includes only:

paths:
  - ".github/workflows/deploy-shared-auth.yml"
  - "sandbox/auth/**"

None of commit b5bc86c's paths match that filter, so no workflow was applicable and dispatching the unrelated authentication deployment would have been incorrect. Automated post-push CI is not yet configured for the website module/sandbox/policy paths; the broader deployment pipeline is tracked by open issue #69.

The release gate for this push is therefore the already completed independent local QA evidence: QA PASS, including Terraform format/init/validate, the production mock plan (1/1), positive policy plus 10/10 negative fixtures, and the non-mutating live sandbox plan showing 48 add, 0 change, 0 destroy with unchanged pre/post AWS/DNS/state inventory. Product/DX subsequently accepted the same reviewed candidate and explicitly authorized manual cross-repository closure after verified push.

No workflow was triggered, no Terraform apply/state mutation was performed, and no file, PR, or infrastructure change was made during on-call observation.

Closing #67 as completed under that explicit manual-close instruction, while recording the CI coverage gap rather than calling absent CI green.