Pre-Migration Outbound IP Dependency Audit

Status: Ready for review. All 8 NAT IPs (4 non-prod + 4 prod, us-central1) verified live as of 2026-04-30. Author: miko.hadikusuma Created: 2026-04-29 Updated: 2026-04-29 Jira: HB-8210 Gates: HB-8218 (Allowlist updates) → HB-8232 (Deploy production swarm)

Table of Contents

1. Purpose & Scope
2. Current vs. Target State
3. Audit by Surface
   1. GCP Cloud SQL authorized_networks
   2. Azure SQL Firewall (HA Apps Only)
   3. Cloudflare Access Groups (IP Bypass)
   4. Caddy VPN Bypass List
   5. Partner API Webhooks / External Integrations
   6. Other (lower priority but worth verifying)
4. Cutover Sequence (handoff to HB-8218)
5. Open Questions
6. Action Item Traceability
7. References

1. Purpose & Scope

When the nine Phase 0 THB applications consolidate onto shared Docker Swarm workers, every per-VM external IP currently used as the source of an outbound connection disappears. Workers run with no external IP behind a shared Cloud NAT with 4 static egress IPs per region (us-central1) — see §2 for the verified set.

Anything that allowlists today’s per-VM IPs needs to be updated to the new NAT IPs before workloads cut over. This audit enumerates every such allowlist surface, where the rule lives, and the migration action needed. The deliverable feeds directly into HB-8218 (the implementation ticket).

Apps in scope (canonical list per ./zig/zig build scripts -- compose-file-linter --list): bees, benefits-platform, consumer_portal, django_homealign, hb-buzz, hbcrm, pd, thb-keycloak, the_consumer_portal. (HA apps — Azure-side — are out of scope for the swarm migration but their Azure SQL firewall is still affected; see §3.2.)

In scope: anywhere a current VM’s external IP is referenced as a source/allowed origin for outbound calls from one of these nine apps.

Out of scope:

• Inbound allowlists for user access to our infra (e.g. THB VPN exit IPs gc{2,4,5,6}-algo in infra/bees-infra/common.auto.tfvars). These remain identical post-migration.
• Partner-side IPs allowlisting them into our systems (e.g. local.partner_ip_addresses in infra/ha-infra/business_unit_1/production/environment.tf). Partner IPs don’t change.
• App service-account permissions (covered by HB-8212 / HB-8213).

2. Current vs. Target State

Current per-VM external IPs

Discovered via data.google_compute_addresses.* and per-resource google_compute_address definitions:

Quick inventory command:

gcloud compute addresses list --filter="address_type=EXTERNAL" --format="table(name,address,project)" \
  --project=<env-project-id>

Target swarm NAT IPs

Provisioned per HB-8217 / HB-8360 as Cloud NAT on the vpc-{env}-shared-base shared VPC. Capacity: 4 IPs × 64,512 ports / 2048 min_ports_per_vm = ~126 VM ceiling per region.

Canonical TF source (separate repo): thehelperbees/gcp-networks

NAT IPs to allowlist (verified 2026-04-30 against live state):

All four IPs per region are attached round-robin to the Router NAT, so every IP must be in every allowlist — partial allowlisting causes intermittent ~50% failures as workers cycle through unallowlisted IPs.

📝 Historical note: HB-8218 originally listed only 2 of 4 IPs per env. The remaining 6 were discovered live during this audit (gcp-networks provisions nat_num_addresses_region1 = 4 for both envs per envs/{production,non-production}/boa_vpc_fw.tf:45). HB-8218 description updated 2026-04-30 with the corrected set.

⚠️ us-west1 NAT IPs exist but are out of scope. A gcloud compute addresses list query against either shared-base-vpc-host project also returns 4 IPs in us-west1 (e.g., non-prod 34.105.111.96 / 34.127.70.253 / 136.109.214.215 / 34.169.152.90; prod 35.227.138.226 / 35.185.201.232 / 34.168.190.12 / 8.229.103.135). These belong to a parallel Cloud NAT in us-west1 for non-swarm workloads (Cloud Functions and any future regional expansion). The swarm cluster runs only in us-central1 — managers in us-central1-{a,b,c}, workers default to ["us-central1-a","us-central1-b","us-central1-c","us-central1-f"] per swarm_worker/variables.tf. Workers cannot egress through the us-west1 NAT pool. Do not include the us-west1 IPs in any partner-side allowlist — they’re zero-yield (no traffic ever comes from them) and create future change-control burden.

Verification command (per env):

# Non-production
gcloud compute addresses list \
  --project=prj-n-shared-base-cb89 \
  --filter='name~^ca-n-shared' \
  --format='table(name,address)'

# Production
gcloud compute addresses list \
  --project=prj-p-shared-base-11f6 \
  --filter='name~^ca-p-shared' \
  --format='table(name,address)'

Manager IPs (3 per env, separate from worker NAT):

• Non-prod: google_compute_address.swarm_manager_external in infra/hb-infra/business_unit_1/non-production/swarm.tf (deployed)
• Prod: same resource in production/swarm.tf — block-commented (/* ... */), gated on HB-8232

Verifying egress before partner outreach

Before notifying partners (§3.5), confirm that worker traffic actually exits via the NAT IPs above. Misalignment between the reserved IPs and the IPs partners see is exactly the silent-failure mode that caused the HB-8218 4-vs-2 finding — but for partner allowlists, that failure happens at the partner’s edge, after cutover, with no logs on our side.

Two complementary checks. Pass criteria: every worker is mapped to one of the 4 NAT IPs, and a curl from inside the worker echoes back the same IP that GCP’s mapping table claims for it.

Check 1 — control-plane mapping: ask GCP which NAT IP each worker is using. No cluster shell access needed.

NETWORK_HOST_NON_PROD="$(gcloud projects list \
  --filter='labels.application_name=base-shared-vpc-host AND labels.environment=non-production' \
  --format='value(projectId)')"

gcloud compute routers get-nat-mapping-info \
  cr-n-shared-base-spoke-us-central1-nat-router \
  --nat-name=rn-n-shared-base-spoke-us-central1-egress \
  --region=us-central1 \
  --project="$NETWORK_HOST_NON_PROD"

Output is a JSON list, one entry per VM, each with natIpPortRanges[].natIp. Group by natIp to confirm: every worker maps to one of 34.72.82.40, 34.122.251.101, 34.170.35.69, 35.194.23.180. Any other IP is a finding.

Check 2 — partner’s-eye view: run a one-shot global service that hits an IP echo from every worker. What it reports is what a partner will see.

# From a swarm manager (SSH via IAP):
docker service create \
  --name nat-ip-check \
  --mode global \
  --restart-condition none \
  alpine sh -c 'echo "$(hostname): $(wget -qO- https://ifconfig.me)"'

# Wait ~30s for tasks to complete, then:
docker service logs nat-ip-check --no-trunc

# Cleanup:
docker service rm nat-ip-check

Cross-check the IP each worker reports against Check 1: they should match per-worker. If they don’t, the egress path isn’t what we think it is — stop and investigate before partner outreach.

If you don’t have manager shell access, alternate per-worker approach:

gcloud compute ssh swarm-worker-n-XXXX --tunnel-through-iap \
  --command='curl -s https://ifconfig.me'

…repeated for each worker.

Optional — Check 3, NAT translation logs: the gcp-networks egress_nat_region1 resource enables log_config { filter = "TRANSLATIONS_ONLY" }, so every flow gets logged. While Check 2 is running, tail the logs to see actual translations:

gcloud logging read \
  'resource.type="nat_gateway"
   resource.labels.gateway_name="rn-n-shared-base-spoke-us-central1-egress"' \
  --project="$NETWORK_HOST_NON_PROD" \
  --limit=50 \
  --format='value(jsonPayload.connection.nat_ip,jsonPayload.connection.src_ip,jsonPayload.connection.dest_ip)'

Three columns: NAT IP exited from, worker internal IP, destination. Confirms what we expect from a third independent angle.

If all three checks agree, the IP set is ground-truthed and partner outreach can go out. If any disagree, the disagreement is the next thing to chase.

3. Audit by Surface

3.1 GCP Cloud SQL authorized_networks

Action item: Add a new entry to the allowlist concat in pd-p-mssql.ip_configuration.authorized_networks once swarm NAT IPs are known.

# Live audit
gcloud sql instances describe <instance-name> --project=<env-project-id> \
  --format="value(settings.ipConfiguration.authorizedNetworks)"

3.2 Azure SQL Firewall (HA Apps Only)

These rules are NOT in Terraform. They live only in Azure. Inventory:

# Production
az sql server firewall-rule list --resource-group HA-PROD1-SQL-RG \
  --server ha-prod1-azsqldb --output table

# Non-prod
az sql server firewall-rule list --resource-group HA-DEV-SQL-RG \
  --server ha-dev-azsqldb --output table

Add rule (one invocation per NAT IP from §2):

./zig/zig build scripts -- add_az_sql_fw_rule.sh -e production -n SWARM_WORKER_NAT_0 -ip <nat-ip-0>
./zig/zig build scripts -- add_az_sql_fw_rule.sh -e production -n SWARM_WORKER_NAT_1 -ip <nat-ip-1>
./zig/zig build scripts -- add_az_sql_fw_rule.sh -e production -n SWARM_WORKER_NAT_2 -ip <nat-ip-2>
./zig/zig build scripts -- add_az_sql_fw_rule.sh -e production -n SWARM_WORKER_NAT_3 -ip <nat-ip-3>

The script is idempotent (checks for existing rule with same IP first). The _0 through _3 suffix aligns with the gcp-networks address resource indices (ca-{env_code}-shared-base-spoke-us-central1-{0..3}).

3.3 Cloudflare Access Groups (IP Bypass)

Two locations:

A) infra/pd-infra/business_unit_1/production/cloudflare.tf — most action here:

B) HB-side cloudflare-access module calls — these live in hb-infra (not pd-infra) and use a dynamic vpn_ip_addresses input rather than named Cloudflare Access groups:

Why this matters for pdp24 → eligibility: When pdp24 calls https://eligibility.thb.nu, Cloudflare Access checks if the source IP is in the vpn_bypass group. Today, pdp24’s 35.225.100.177 is in local.pd_addresses (via the dynamic data lookup) so it passes. After migration, pdp24’s IP becomes a swarm NAT IP — which is not in the PD project’s external addresses, so the dynamic lookup won’t include it. The static-entry fix above is what keeps this internal flow working post-migration. No partner action required — this is our own infrastructure.

C) infra/ha-infra/business_unit_1/production/cloudflare/cloudflare.tf — uses only var.authorized_networks (THB VPN). No change needed.

Live audit:

# Already in TF — read current state
./zig/zig build plan -- pd-infra production cloudflare
./zig/zig build plan -- hb-infra production cloudflare
./zig/zig build plan -- hb-infra production eligibility_service

3.4 Caddy VPN Bypass List

Important: The Terraform-supplied caddy_vpn_bypass_list is one of three inputs that compose the actual runtime Caddy allowlist. The full picture, assembled by Ansible at deploy time:

admin_allowed_ip_addresses = [vm_ip] + vpn_ip_addresses + caddy_vpn_bypass_list

(Composed across gc_deploy_with_gcp_secrets.yml:358-360 — the playbook actually used in production — and roles/caddy_create/tasks/main.yml:46-48 in hb-ansible.) This list drives the (is-public-ip) / (is-vpn-ip) snippets in roles/caddy_create/templates/Caddyfile.j2, which gate the admin/flower/camunda/websocket routes that bypass Cloudflare Access.

How caddy_vpn_bypass_list flows from Terraform to runtime

The caddy_vpn_bypass_list value is not read at deploy time from a static file in hb-ansible. It traverses three systems:

infrahive Terraform (hb-infra/.../main.tf)
    local.caddy_pd_addresses
        |
        v
    module "hb-p-ansible-config5" { caddy_vpn_bypass_list = local.caddy_pd_addresses }
        |  (terraform apply)
        v
    ansible_config TF module (terraform-modules.git, external)
        |
        v
    GCS: gs://ansible-config-65ab/<app>/config.yml      ← regenerated on every apply
        |
        v
    hb-ansible playbook (gc_deploy_with_gcp_secrets.yml) loads bucket_path at deploy time
        |
        v
    filtered_app.caddy_vpn_bypass_list (per-app dict)
        |
        v
    caddy_create role (roles/caddy_create/tasks/main.yml:46-48)
        admin_allowed_ip_addresses = [vm_ip] + vpn_ip_addresses + filtered_app.caddy_vpn_bypass_list
        |
        v
    Caddyfile.j2 (is-public-ip / is-vpn-ip matchers)

Verified end-to-end via gsutil cat gs://ansible-config-65ab/hbcrm/config.yml — that file already contains a populated caddy_vpn_bypass_list array with all PD partner VM IPs (78+ entries today).

Implication for HB-8413 (Caddy VPN bypass) and HB-8414 (Cloudflare Access): changes happen in infrahive only. No edits to hb-ansible. The Caddy template is data-driven — it picks up whatever’s in the GCS config on next deploy. And because the same local.caddy_pd_addresses / local.pd_addresses data lookup feeds all three downstream surfaces (Caddy bypass, standard cloudflare-access, eligibility-cloudflare-access), a single Terraform PR closes both HB-8413 and HB-8414 — coordinate so the work isn’t duplicated.

Terraform sources of caddy_vpn_bypass_list:

Decision (resolves Q1): The migration will not introduce an HB↔︎PD swarm overlay network. HB→PD calls continue to traverse the public internet via Cloudflare, requiring the swarm NAT IPs in this bypass list. A future overlay is tracked under HB-8620 (parented to the HB-6748 DevOps KTLO epic), which would let us remove this bypass list entirely.

Note on partner_allowed_ip_addresses (inbound, out of scope): While inspecting hb-ansible, we also reviewed the per-app partner_allowed_ip_addresses variable (roles/caddy_create/tasks/main.yml:32, only set on stage_hbpdp11 with [76.187.226.216]). This is the inverse direction — a partner’s IP allowlisted on our Caddy for inbound /partner/* traffic — and is therefore out of scope for HB-8210. Additionally, the variable is set as a fact but never referenced in the current Caddyfile.j2 template, suggesting it is either vestigial or enforced at the app layer inside partner_django. Either way, partner IPs don’t change during our migration, so no action.

3.5 Partner API Webhooks / External Integrations

This is the highest-risk and least-discoverable surface. Partner systems often allowlist our outbound IP for inbound webhooks, SFTP polling, or API calls.

Known surfaces requiring live inventory (cannot enumerate from infrahive alone):

1. Partner SFTP destinations — infra/pd-infra/cloudfunctions/sftp_pubsub_messages/SFTP/client.go, infra/pd-infra/cloudfunctions/sftp_bucket_file/SFTP/client.go. SFTP from cloud functions, not VMs — likely uses its own NAT. Verify these aren’t routed through partner VMs.

2. PSR (Provider Services Request) handler — out of scope, documented for clarity — infra/pd-infra/modules/partner_psr_request_handler/. On first read this looked like a possible outbound surface, but inspection of the module and its callers (pdp8, pdp24, …) confirms the flow is the opposite direction: a partner’s Salesforce instance pushes files into our GCS bucket (psr-{partner_code}-{env}-*), authenticated by a service-account key that we generate and hand to the partner’s Salesforce dev. A Cloud Function then converts uploads to PDF/XML for hbcrm to read. No partner-side IP allowlist is involved, and our outbound IP doesn’t appear in this flow at all — so it’s unaffected by the swarm migration. Listed here only so future readers don’t re-add it as an open question.

3. Per-partner outbound API integrations — likely configured per-partner in either:

   • pd repo .envs/ files (partner API base URLs and auth)
   • hb-buzz / hbcrm / django_homealign per-tenant settings
   • Salesforce / Camunda outbound webhooks

Recommended path: post in #devops asking team members which partners allowlist our outbound IP. Active outreach: #devops thread on 2026-04-30. Track replies there and add new partners to the confirmed-partners table below as they surface.

Owner for partner outreach: PD partner success / integrations team. Best to start parallel to HB-8218 implementation since some partners have multi-week change-control SLAs.

Confirmed partners with our outbound IP allowlisted

All IPs below verified live via curl ifconfig.me from the corresponding VM. Each address resource carries lifecycle { ignore_changes = all } so the IPs have been stable.

Source TF for all rows: google_compute_address.external in infra/pd-infra/business_unit_1/{production,non-production}/pdp{N}/main.tf:12.

Whether each partner actually has the non-prod IP allowlisted on their side is unknown. Confirmed partner integrations may be prod-only; partner outreach (per pre-cutover checklist below) should ask explicitly: “do you allowlist any IPs of ours other than the prod one above?” and capture the answer here.

Other partners — unknown. Coverage is tribal; PD partner success / integrations team should confirm no others exist. Outreach posted in #devops on 2026-04-30 — track replies there.

Internal flows that depend on these IPs: pdp24 → eligibility.thb.nu / eligibility.thb.sh (confirmed). Our own Cloudflare Access vpn_bypass group includes all PD partner VM IPs (pdp7, pdp10, pdp24, and any other active partner) via local.pd_addresses (dynamic data lookup), so any of them calling our HB-side services rides this allowlist. After migration the dynamic lookup shrinks to nothing and is replaced by static swarm NAT IP entries — covered by §3.3 row B. No partner action needed for these internal flows.

Decision (post-migration): notify each partner contact of the swarm NAT IPs across both environments (4 non-prod + 4 prod, per §2) and have them update their allowlist in a single change. Bundling envs minimizes partner change-control churn — most partners have one allowlist that covers any of our outbound, regardless of which env it originated from. After prod cutover (the last env to migrate), the per-partner production GCE addresses can be released (delete the google_compute_address.external resources in pdpN/main.tf).

Why not preserve the existing per-partner IPs?

To pick the right path it helps to know how Cloud NAT actually distributes IPs to outbound flows. With the MANUAL_ONLY mode + min_ports_per_vm = 2048 that gcp-networks configures, Cloud NAT does per-VM IP allocation, not per-flow:

1. Each worker VM is assigned a fixed allocation of ~2048 ports from one of the pool’s NAT IPs.
2. The worker uses that single IP for all its outbound flows (until port exhaustion, which is rare with 2048 ports).
3. The assignment is Cloud-NAT-internal — we don’t control which IP a given worker gets.
4. With N IPs in the pool and M workers, roughly M/N workers land on each IP.

Service replicas in Swarm are scheduled across the worker pool, so per-partner outbound traffic (e.g., pdp24 → partner API, pdp10 → partner API) comes from whichever NAT IP was assigned to the worker the scheduler placed it on — not from any IP we can pre-select.

Options compared (per partner)

Why option 4 keeps coming up

Option 4 feels like it should work: “we have the IPs, just keep using them.” It would work if Cloud NAT supported per-flow IP selection rules (“traffic to partner.example.com → source IP X”), but it doesn’t — IP assignment is per-VM, not per-flow or per-destination. So a preserved IP ends up tied to whichever workers Cloud NAT happens to assign it to, used by every outbound flow from those workers regardless of destination, while partner replicas on other workers don’t use it at all. It’s effectively option 1 with extra unused IPs in the pool.

The only real ways to preserve a partner-specific IP are option 3 (proxy steers at the application layer) or option 5 (node pinning forces the worker assignment), and we’ve ruled out 5. Reconsider option 3 only if option 1 is blocked for a specific partner.

Pre-cutover checklist (per partner, run for pdp7, pdp10, and pdp24):

Precondition: the §2 verification procedure (“Verifying egress before partner outreach”) must have been run for non-prod, with the 4 verified IPs locked in. For prod, communicate the IPs we have today and follow up before prod cutover with any updates from the same verification run.

1. Send the partner contact the full swarm NAT IP set across both environments (from §2). Communicating both envs at once minimizes partner change-control churn:
   • Non-production (4 IPs, verified live): 34.72.82.40, 34.122.251.101, 34.170.35.69, 35.194.23.180
   • Production (4 IPs, all verified live 2026-04-30): 34.132.72.45, 35.226.246.142, 34.136.40.107, 34.57.41.236
2. Ask the partner to enumerate every IP of ours they currently allowlist — both prod and non-prod, if applicable. Capture this in the audit’s confirmed-partners table so we know which entries to clean up post-migration.
3. Get written confirmation that all 8 swarm NAT IPs (or current best subset for prod) are in their allowlist before the corresponding env’s migration day.
4. Keep existing per-partner IPs allowlisted on the partner side throughout the dual-allowlist window per §4. The window must extend through the last migration to complete (= prod, gated on HB-8232). Per-partner IPs to keep (only those the partner confirms in step 2 are actually in their allowlist):
   • pdp7 prod: 35.238.12.142 / non-prod: 35.232.30.74
   • pdp10 prod: 34.69.126.254 / non-prod: 34.134.208.190
   • pdp24 prod: 35.225.100.177 / non-prod: 34.30.125.50
5. One week after prod cutover: ask the partner to remove the old IPs from their allowlist; release the corresponding google_compute_address.external resources in pdp{N}/main.tf (and non-prod equivalents if applicable) on our side.

Tableau Analytics — internal system that allowlists our partner IPs

The internal Tableau server hosting Analytics pages allowlists outbound IPs from pdp1, pdp5, and pdp14 so those partner stacks can fetch/render dashboards. After migration, those stacks egress through swarm NAT IPs and Tableau’s allowlist won’t match.

This is structurally identical to the partner allowlist pattern above — Tableau is “external” from the swarm’s perspective even though it’s internal to THB. Not managed by infrahive (zero references to tableau / Tableau / tab.thb in the repo); the tab_user DB user in crm_database is a read-role for Tableau to query CRM data, not the Tableau server itself.

The migration action (add swarm NAT IPs to Tableau’s allowlist, dual-allowlist window through prod cutover, verify Tableau → our Cloud SQL access still works post-migration) is tracked under HB-8623 (subtask of HB-8218).

Open questions for whoever owns Tableau (Analytics / DevOps): where does the Tableau server live (self-hosted VM? Tableau Cloud?), who owns its allowlist, and are there any other partner stacks beyond pdp1/5/14 that hit it?

3.6 Other (lower priority but worth verifying)

• Cloudflare Tunnel / cloudflared config — src/tools/launchbot/templates/cloudflared/config.yml.tmpl. Tunnel is identity-based, not IP-based, but verify there’s no IP-pinned policy.
• Datadog allowlists — outbound to Datadog via dd_agent. Datadog accepts traffic from any source; Datadog API key auths the call. No change.
• Papertrail (syslog+tls://logs7.papertrailapp.com:23105) — same; no IP allowlist on Papertrail’s side.
• Camunda / Keycloak outbound — internal, no external allowlist.
• GitHub Actions deploy proxy (infra/common-infra/business_unit_1/shared/gh_actions_deploy_proxy.tf) — separate proxy, not impacted.

4. Cutover Sequence (handoff to HB-8218)

1. Provision swarm Cloud NAT for prod (HB-8217 already done for non-prod; prod gated on HB-8232).
2. Capture the NAT IPs per env via gcloud compute addresses list --filter='name~^ca-{n,p}-shared-base-spoke-us-central1-' --format='table(name,address)' against the corresponding network host project (full commands in §2). Use addresses list rather than routers nats describe here — describe returns address-resource URLs, not IP values. For defense-in-depth, also run routers nats describe to confirm those addresses are actually attached to the NAT, and routers get-nat-mapping-info to confirm workers map to them (per §2 verification procedure).

# Non-production
gcloud compute routers nats describe rn-n-shared-base-spoke-us-central1-egress \
  --router=cr-n-shared-base-spoke-us-central1-nat-router \
  --region=us-central1 \
  --project=prj-n-shared-base-cb89

# Production
gcloud compute routers nats describe rn-p-shared-base-spoke-us-central1-egress \
  --router=cr-p-shared-base-spoke-us-central1-nat-router \
  --region=us-central1 \
  --project=prj-p-shared-base-11f6

3. Pre-add NAT IPs to all surfaces before any workload moves:
   • PD shared MSSQL authorized_networks (Terraform PR adding static entries to the concat in pd-infra/.../mssql.tf:110).
   • Azure SQL firewall: 2 rules per env via add_az_sql_fw_rule.sh.
   • Cloudflare Access groups green_p_ip_bypass and yellow_p_ip_bypass: TF PR adding static entries.
   • Caddy VPN bypass: TF PR adding the swarm NAT IPs as static entries to the caddy_vpn_bypass_list callers. (No overlay during migration — see HB-8620 for the future overlay work.)
   • Partner systems: outreach in flight (longest-tail; start now).
4. Validate (workers boot but stay drained until allowlists confirmed).
5. Cut over workloads.
6. Post-migration cleanup: remove now-stale per-VM rules.

Dual-allowlist window

Steps 3-6 deliberately leave both per-VM IPs and the new NAT IPs allowlisted for the duration of the cutover. This is necessary for zero-downtime migration but expands the allowlist by ~4 IPs per environment for the duration of the window. Treat this as a known temporary security posture:

• Expected duration: hours to days for in-house surfaces (Cloud SQL, Azure SQL, Cloudflare); weeks for partner-side allowlists where partner change-control SLAs apply (most acute for §3.5 partner webhooks).
• Highest-impact surfaces during the window: PD shared MSSQL (§3.1) and partner webhooks (§3.5) — both expose data paths, not just management.
• Monitoring: before the window opens, enable connection logging on Cloud SQL (cloudsql.googleapis.com/postgres.log or equivalent) and Azure SQL audit logging filtered by client_ip. Watch for traffic from the new NAT IPs before cutover (should be zero) and unexpected continued traffic from per-VM IPs after cutover (signals incomplete migration of a workload).
• Cleanup commitment: step 6 is not optional. Each surface owner is on the hook for removing the stale per-VM entry within 1 week of cutover, tracked in HB-8218 subtasks.

5. Open Questions

6. Action Item Traceability

Every migration action this audit identifies maps to an existing Jira ticket. Comments noted below were posted to the corresponding ticket on 2026-04-30 to add audit-derived scope detail that wasn’t in the original ticket description.

7. References

• Swarm worker module README
• Swarm cluster (non-prod) / (prod, gated) — managers, manager external IPs, and worker MIG, consolidated per #766
• THB VPN authorized networks
• Add Azure SQL firewall rule script