Skip to main content
Jira progress: loading…

AWS

AWS Usage & Tenant Routing Architecture

This document defines how ZAYAZ uses AWS, with a strong focus on tenant routing, data residency, and disaster recovery (DR). It is normative and intended for developers, architects, auditors, and partners. All implementations MUST conform unless explicitly exempted.

1. Design Principles​

ZAYAZ is built as a multi-region, policy-driven SaaS platform. The architecture separates tenant policy decisions from cloud infrastructure mechanics.

Core principles:

  • Tenant-centric routing: All routing decisions are based on tenant policy, never on user geolocation.
  • Explicit data residency: Where data lives is a contractual and auditable decision.
  • Region determinism: Every tenant has a single active primary AWS region at any time.
  • Controlled resilience: Secondary and DR regions are platform-governed, not tenant-defined.
  • Fail-safe defaults: Strict Residency (SR) is always possible; Resilient Residency (RR) is explicit and opt-in.

2. Core Concepts​

2.1. Residency Zone vs AWS Region​

ZAYAZ distinguishes between:

  • Residency Zone: A legal / policy boundary (e.g. eu, na, as, af, me, sa).
  • AWS Region: A physical deployment target (e.g. eu-north-1, us-east-1).

A residency zone may contain multiple AWS regions. A tenant is always bound to exactly one zone.

3. Authoritative Configuration Objects​

3.1 residency_region_policy​

Platform-governed mapping defining *what ZAYAZ supports- per primary region.

residency_region_policyStable
Source file: residency_region_policy.xlsx
SignalTypeExampleDescription
alb_dnsstring / aws_alb_dnszyz-alb-eu-north-1-123456.eu-north-1.elb.amazonawsAWS-generated DNS name of the regional Application Load Balancer serving this API region. Used as the Cloudflare CNAME target. May be empty until ingress is provisioned.
apistring / dns_hostnameapi.ap-northeast-2.zayaz.ioRegional API hostname used for tenant routing (e.g. api.eu-north-1.zayaz.io). This is the externally visible ingress endpoint.
aws_regionstring / aws_regionAsia Pacific (Seoul) ap-northeast-2Human-readable AWS region name and code describing the physical deployment location (e.g. Europe (Stockholm) eu-north-1).
default_countriesjson / iso_country_listKR, KPList of ISO-3166-1 alpha-2 country codes that default to this AWS region during tenant onboarding. Used for suggestion only, not enforcement.
dr_encryptionstring / encryption_policysse_kms_requiredRequired encryption standard for all DR copies (e.g. sse_kms_required). Applies to both SR and RR modes.
dr_region_rrstring / aws_region | nullnullDisaster recovery region used under Resilient Residency (RR) mode. May be cross-zone if explicitly allowed. null when RR is not supported for this primary region.
dr_region_srstring / aws_regionap-northeast-3Disaster recovery region used under Strict Residency (SR) mode. Must remain inside the same residency zone. May equal the primary region in single-region zones.
effective_fromtimestamptz2025-06-10T09:55:31ZValid from date
effective_totimestamptz2025-06-10T09:55:31ZDate of deprecation
notesstring / governance_notesKR/JP triangle. Secondary in Tokyo, DR in Osaka to diversify away from primary/secondary pair.Rationale and governance notes explaining regional constraints, DR strategy, and compliance considerations. Intended for auditors, architects, and operators.
primary_regionstring / aws_regionap-northeast-2AWS region used as the tenant’s primary data and compute location under normal operation.
region_notestring / descriptive_labelAP SeoulHuman-readable short description of the region for internal clarity (e.g. AF Cape Town, AP Tokyo).
rr_allowedboolean / policy_flagFALSEIndicates whether Resilient Residency (cross-zone emergency DR) is permitted for this primary region.
rrp_idstring / identifierRRP-0003Unique identifier for the residency region policy record. Used for traceability, versioning, and audit references.
s3_linkstring / aws_s3_bucket_refzyz-td-ap-northeast-2Canonical S3 bucket identifier used for tenant production data in this primary AWS region (e.g. zyz-td-eu-north-1).
secondary_regionstring / aws_regionap-northeast-1AWS region used for high availability or fast recovery. Must always remain within the same residency zone as the primary region.
vpc_cidstring / cidr_block10.41.0.0/16CIDR block allocated to the regional ingress VPC. Must be globally non-overlapping across all ZYZ regions.
zonestring / residency_zoneapLogical data residency zone representing the legal/policy boundary (e.g. eu, na, as, af, me, sa).
Family
auditclassificationcodeid
Used by modules
Input-HubSIS

Characteristics:

  • One entry per allowed primary_region
  • Defines secondary and DR candidates
  • Defines whether Resilient Residency is allowed

Key fields:

char-key-fields.jsonGitHub ↗
{
  "primary_region": "eu-north-1",
  "zone": "eu",
  "secondary_region": "eu-west-1",
  "dr_region_sr": "eu-west-3",
  "dr_region_rr": null,
  "rr_allowed": false,
  "dr_encryption": "sse_kms_required"
}

This object is immutable at runtime and versioned when changed.

See the JSON file for the full Residency Region Policy).

3.2 Tenant Policy Record​

Tenant-specific, contract-bound configuration.

Key fields:

tenant-fields.jsonGitHub ↗
{
  "user_id": "ECO-276-...",
  "legal_country": "DE",
  "primary_region": "eu-north-1",
  "data_residency_zone": "eu",
  "dr_mode": "sr",
  "dr_activation": "emergency_only",
  "dr_legal_basis": "contractual_consent"
}

Derived (computed) fields:

  • secondary_region
  • dr_effective_region
  • tenantdata_bucket_primary
  • tenantdata_bucket_dr

4. Tenant Onboarding Flow​

4.1 Region Suggestion​

During onboarding:

  1. Capture tenant legal country (ISO-3166-1 alpha-2)
  2. Use country→region mapping to suggest a primary AWS region
  3. Present only regions allowed for the tenant’s residency zone

The suggestion is non-binding. Final selection is explicit.

4.2. Primary Region Selection​

The tenant selects:

  • primary_region

The system validates:

  • Region is allowed for the tenant’s zone
  • Region exists in residency_region_policy

Once confirmed:

  • primary_region becomes sticky
  • Changing it requires a migration procedure

4.3. Secondary & DR Resolution​

ZAYAZ resolves:

secondary_region = residency_region_policy.primary_region.secondary_region

if tenant.dr_mode == "sr":
    dr_effective_region = dr_region_sr
else if tenant.dr_mode == "rr":
    dr_effective_region = dr_region_rr

Tenants never select secondary or DR regions directly.

5. Runtime Tenant Routing​

5.1. Control Plane vs Data Plane​

  • Control Plane: Global (auth, tenant registry, routing logic)
  • Data Plane: Regional (APIs, storage, computation)

The control plane determines *where- a request must go.

5.2. Request Routing Algorithm​

At request time:

  1. Resolve tenant_id from auth context
  2. Load tenant policy record
  3. Determine active_region (normally = primary_region)
  4. Route request to regional API endpoint

Example:

request-routing.tsGitHub ↗
// request-routing.ts

export type AwsRegion =
  | "af-south-1"
  | "ap-northeast-1"
  | "ap-northeast-2"
  | "ap-northeast-3"
  | "ap-south-1"
  | "ap-southeast-1"
  | "ap-southeast-2"
  | "eu-central-1"
  | "eu-north-1"
  | "eu-west-1"
  | "eu-west-2"
  | "eu-west-3"
  | "me-central-1"
  | "sa-east-1"
  | "us-east-1"
  | "us-east-2"
  | "us-west-1"
  | "us-west-2";

export interface TenantRouting {
  active_region: AwsRegion;
}

/** Resolves the regional API hostname for a tenant. */
export function resolveRegionalApiHost(tenant: TenantRouting): string {
  return `api.${tenant.active_region}.zayaz.io`;
}

Usage:

import { resolveRegionalApiHost } from "./request-routing";

const host = resolveRegionalApiHost(tenant);
// then the caller decides what "routeTo" means

User IP location is never used.

6. Storage Architecture​

6.1. Bucket Naming​

Tenant production data buckets:

zyz-td-<aws-region>

Examples:

  • zyz-td-eu-north-1
  • zyz-td-us-east-1

Test tenants use separate buckets (e.g. zyz-tenantdata-eu).

6.2. Object Layout​

/<tenant_id>/<dataset>/<yyyy>/<mm>/<dd>/<object_id>.<ext>

Isolation is enforced via:

  • Prefix discipline
  • S3 Access Points per tenant
  • IAM + bucket guardrail policies

7. Encryption & Security​

  • All tenant data uses SSE-KMS
  • KMS keys are region-local
  • DR copies must use equivalent or stronger encryption

Non-TLS access is explicitly denied.

8. Disaster Recovery Modes​

8.1. Strict Residency (SR)​

  • DR region remains inside residency zone
  • No cross-zone data copies
  • May result in prolonged outage in single-region zones

Default for:

  • EU
  • North America
  • Asia Pacific

8.2. Resilient Residency (RR)​

  • Emergency DR may use pre-approved foreign zone
  • Activated only on declared regional disaster
  • Requires explicit tenant consent

Default-suggested for:

  • Africa
  • South America
  • Middle East

9. Failover & Recovery​

9.1. DR Activation​

When DR is activated:

  • tenant.active_region is switched
  • Routing table updated
  • DR bucket becomes active read/write target

All activations are:

  • Logged
  • Time-stamped
  • Auditable

9.2. Post-Recovery Cleanup​

After recovery:

  • Primary region restored
  • DR data re-synchronized or purged per policy
  • Compliance state documented

10. Ingress Architecture (Normative)​

This section defines the minimum required AWS infrastructure per region to support ZAYAZ tenant routing via regional API hostnames (e.g. api.<region>.zayaz.io).

This specification is intentionally minimal and exists to:

  • allow DNS and TLS configuration to proceed early
  • decouple network ingress from application deployment
  • ensure deterministic, auditable regional entry points

10.1. Ingress VPC – Minimum Specification​

For each supported AWS region, the following resources MUST exist.

10.1.1. VPC​

  • Name: zyz-vpc-<region> (e.g. zyz-vpc-eu-north-1)

  • CIDR: one non-overlapping /16 per region

    • Example allocation:

      • eu-north-1 → 10.20.0.0/16
      • eu-west-1 → 10.21.0.0/16
      • us-east-1 → 10.30.0.0/16

  • CIDR planning MUST be global and documented to prevent future peering conflicts

10.1.2. Subnets​

  • Create at least two (2) public subnets

  • Subnets MUST be in different Availability Zones

  • Subnets MUST have:

    • route to Internet Gateway
    • auto-assign public IPv4 enabled

10.1.3. Internet Gateway​

  • Attach one Internet Gateway to the VPC
  • Required for public Application Load Balancer ingress

10.2. Regional Application Load Balancer (ALB)​

Each region MUST expose a single regional ingress ALB.

ALB requirements​

  • Name: zyz-alb-<region> (e.g. zyz-alb-eu-north-1)

  • Type: Application Load Balancer (public)

  • Subnets: all public subnets created above

  • Security group:

    • Allow inbound 443/tcp
    • Allow inbound 80/tcp (optional; typically redirected to HTTPS)

Listener​

  • Protocol: HTTPS

  • Port: 443

  • Certificate:

    • MAY be added later
    • MUST exist before Cloudflare proxying is enabled

Target Group​

  • Target type: IP, Instance, or Lambda (implementation-dependent)
  • Targets: MAY be empty initially
  • An empty target group is acceptable for DNS and TLS preparation

10.3. Required Output for DNS Configuration​

For each region, the infrastructure team MUST provide:

  • ALB DNS name, e.g.

    zyz-alb-eu-north-1-123456.eu-north-1.elb.amazonaws.com

This DNS name is the only valid target for the corresponding Cloudflare CNAME:

api.<region>.zayaz.io → <alb-dns-name>

No URLs, paths, or placeholders are permitted in final DNS records.

10.4. Separation of Responsibilities​

This ingress stack is intentionally application-agnostic.

  • The ingress VPC and ALB MAY be created before any services exist
  • Application teams MAY attach services later via target groups
  • DNS and TLS teams MAY proceed independently once ALB DNS names exist

This separation enables parallel workstreams and reduces deployment coupling.

11. Audit & Compliance Posture​

ZYZ can always answer:

  • Where is tenant X’s data stored right now?
  • Where can it be stored under emergency conditions?
  • Under what legal basis?

This is critical for:

  • CSRD
  • ESRS
  • DPA reviews
  • Third-party assurance

12. Non-Negotiable Invariants​

  • Tenant routing is policy-driven
  • Buckets never mix zones
  • DR behavior is explicit, never implicit
  • Control plane never bypasses tenant policy

13. Complete JSON Lists​

13.1. Default Country List for the Various AWS S3 Locations.​

default-country.jsonGitHub ↗
{
  "af-south-1": [
    "AO","BF","BI","BJ","BW","CD","CF","CG","CI","CM","CV","DJ","DZ","EG",
    "EH","ER","ET","GA","GH","GM","GN","GQ","GW","KE","KM","LR","LS","LY",
    "MA","MG","ML","MR","MU","MW","MZ","NA","NE","NG","RE","RW","SC","SD",
    "SH","SL","SN","SO","SS","ST","SZ","TD","TG","TN","TZ","UG","YT","ZA",
    "ZM","ZW"
  ],

  "ap-northeast-1": [
    "JP","CN","HK","MO","TW"
  ],

  "ap-northeast-2": [
    "KR","KP"
  ],

  "ap-northeast-3": [
    "JP"
  ],

  "ap-south-1": [
    "AF","BD","BT","IN","IR","LK","MV","NP","PK"
  ],

  "ap-southeast-1": [
    "BN","ID","KH","LA","MM","MY","PH","SG","TH","TL","VN"
  ],

  "ap-southeast-2": [
    "AU","NZ","CC","CX","NF","NR","NU","CK","FJ","PG","SB","VU","WS","TO",
    "TV","KI","MH","FM","PW"
  ],

  "eu-central-1": [
    "AT","BE","BG","CH","CY","CZ","DE","DK","EE","FI","HR","HU","LI","LT","LU",
    "LV","NL","NO","PL","RO","SE","SI","SK"
  ],

  "eu-north-1": [
    "SE","NO","FI","IS","DK","EE","LV","LT","AX","FO","GL","SJ"
  ],

  "eu-west-1": [
    "IE","FR","ES","PT","BE","NL","LU","MC","AD"
  ],

  "eu-west-2": [
    "GB","IM","JE","GG"
  ],

  "eu-west-3": [
    "FR"
  ],

  "me-central-1": [
    "AE","SA","QA","KW","BH","OM","JO","IL","LB","IQ","YE","PS"
  ],

  "sa-east-1": [
    "AR","BO","BR","CL","CO","EC","GF","GY","PE","PY","SR","UY","VE"
  ],

  "us-east-1": [
    "US","CA","MX","PR","VI","DO","HT","JM","TT","BS","BB","AG","KN","LC",
    "VC","GD","DM","BZ","GT","HN","SV","NI","CR","PA","CU"
  ],

  "us-east-2": [
    "US","CA"
  ],

  "us-west-1": [
    "US","CA","MX"
  ],

  "us-west-2": [
    "US","CA"
  ]
}

13.2. Residency Region Policy​

residency_region_policy.jsonGitHub ↗
{
  "af-south-1": {
    "zone": "af",
    "primary_region": "af-south-1",
    "secondary_region": "af-south-1",
    "dr_region_sr": "af-south-1",
    "dr_region_rr": "eu-west-1",
    "rr_allowed": true,
    "dr_encryption": "sse_kms_required",
    "notes": "Africa has a single AWS region in our footprint. Strict Residency (SR) uses same-region multi-AZ only. Resilient Residency (RR) uses encrypted emergency DR in EU (eu-west-1)."
  },

  "ap-northeast-1": {
    "zone": "as",
    "primary_region": "ap-northeast-1",
    "secondary_region": "ap-northeast-3",
    "dr_region_sr": "ap-northeast-2",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "JP/KR triangle. Secondary in Osaka for low-latency redundancy, DR in Seoul for true regional diversity within Asia."
  },

  "ap-northeast-2": {
    "zone": "as",
    "primary_region": "ap-northeast-2",
    "secondary_region": "ap-northeast-1",
    "dr_region_sr": "ap-northeast-3",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "KR/JP triangle. Secondary in Tokyo, DR in Osaka to diversify away from primary/secondary pair."
  },

  "ap-northeast-3": {
    "zone": "as",
    "primary_region": "ap-northeast-3",
    "secondary_region": "ap-northeast-1",
    "dr_region_sr": "ap-northeast-2",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "Osaka primary. Secondary in Tokyo, DR in Seoul for regional diversity."
  },

  "ap-south-1": {
    "zone": "as",
    "primary_region": "ap-south-1",
    "secondary_region": "ap-southeast-1",
    "dr_region_sr": "ap-southeast-2",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "South Asia primary. Secondary in Singapore, DR in Sydney for strong geographic separation inside AP footprint."
  },

  "ap-southeast-1": {
    "zone": "as",
    "primary_region": "ap-southeast-1",
    "secondary_region": "ap-southeast-2",
    "dr_region_sr": "ap-south-1",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "Singapore primary. Secondary in Sydney, DR in Mumbai to avoid single sub-region concentration."
  },

  "ap-southeast-2": {
    "zone": "oc",
    "primary_region": "ap-southeast-2",
    "secondary_region": "ap-southeast-1",
    "dr_region_sr": "ap-south-1",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "Oceania primary (Sydney). Secondary in Singapore, DR in Mumbai for wide-area diversity."
  },

  "eu-central-1": {
    "zone": "eu",
    "primary_region": "eu-central-1",
    "secondary_region": "eu-west-1",
    "dr_region_sr": "eu-north-1",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "EU-only. Secondary in Ireland, DR in Stockholm to diversify grid/climate and reduce correlated risk."
  },

  "eu-north-1": {
    "zone": "eu",
    "primary_region": "eu-north-1",
    "secondary_region": "eu-west-1",
    "dr_region_sr": "eu-west-3",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "EU-only. Secondary in Ireland, DR in Paris for continental diversity."
  },

  "eu-west-1": {
    "zone": "eu",
    "primary_region": "eu-west-1",
    "secondary_region": "eu-west-3",
    "dr_region_sr": "eu-north-1",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "EU-only. Secondary in Paris, DR in Stockholm for strong geographic separation."
  },

  "eu-west-2": {
    "zone": "eu",
    "primary_region": "eu-west-2",
    "secondary_region": "eu-west-1",
    "dr_region_sr": "eu-west-3",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "EU-only (note: UK is outside EU; treat this as 'Europe' offering if you sell it separately). Secondary Ireland, DR Paris."
  },

  "eu-west-3": {
    "zone": "eu",
    "primary_region": "eu-west-3",
    "secondary_region": "eu-west-1",
    "dr_region_sr": "eu-north-1",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "EU-only. Secondary Ireland, DR Stockholm."
  },

  "me-central-1": {
    "zone": "me",
    "primary_region": "me-central-1",
    "secondary_region": "me-central-1",
    "dr_region_sr": "me-central-1",
    "dr_region_rr": "eu-west-1",
    "rr_allowed": true,
    "dr_encryption": "sse_kms_required",
    "notes": "Middle East has a single AWS region in our footprint. SR uses same-region multi-AZ only. RR uses encrypted emergency DR in EU (eu-west-1)."
  },

  "sa-east-1": {
    "zone": "sa",
    "primary_region": "sa-east-1",
    "secondary_region": "sa-east-1",
    "dr_region_sr": "sa-east-1",
    "dr_region_rr": "us-east-1",
    "rr_allowed": true,
    "dr_encryption": "sse_kms_required",
    "notes": "South America has a single AWS region in our footprint. SR uses same-region multi-AZ only. RR uses encrypted emergency DR in North America (us-east-1)."
  },

  "us-east-1": {
    "zone": "na",
    "primary_region": "us-east-1",
    "secondary_region": "us-east-2",
    "dr_region_sr": "us-west-2",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "NA: Secondary on US East (Ohio) for fast recovery; DR to US West (Oregon) for true regional disaster resilience."
  },

  "us-east-2": {
    "zone": "na",
    "primary_region": "us-east-2",
    "secondary_region": "us-east-1",
    "dr_region_sr": "us-west-2",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "NA: Secondary on US East (N. Virginia); DR to US West (Oregon)."
  },

  "us-west-1": {
    "zone": "na",
    "primary_region": "us-west-1",
    "secondary_region": "us-west-2",
    "dr_region_sr": "us-east-2",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "NA: Secondary on US West (Oregon) for fast recovery; DR to US East (Ohio) for cross-continent resilience."
  },

  "us-west-2": {
    "zone": "na",
    "primary_region": "us-west-2",
    "secondary_region": "us-west-1",
    "dr_region_sr": "us-east-2",
    "dr_region_rr": null,
    "rr_allowed": false,
    "dr_encryption": "sse_kms_required",
    "notes": "NA: Secondary on US West (California); DR to US East (Ohio)."
  }
}

Appendix A: Ingress Readiness Checklist (One Page)​

Use this checklist to validate that a region is ready for DNS cutover and tenant routing. The goal is to prevent “it resolves but doesn’t work” failures.

A.1 Inputs & Ownership​

  • Region selected (e.g. eu-north-1)

  • Ingress owner assigned (AWS/IaC) and DNS owner assigned (Cloudflare)

  • Naming confirmed

    • VPC: zyz-vpc-<region>
    • ALB: zyz-alb-<region>
    • Hostname: api.<region>.zayaz.io

A.2 Network (VPC)​

  • VPC exists with approved CIDR (see Appendix B)
  • 2+ public subnets exist in different AZs
  • Internet Gateway attached
  • Route tables configured (0.0.0.0/0 → IGW) for public subnets
  • Subnets have auto-assign public IPv4 enabled (if required for your design)

A.3 Load Balancer (ALB)​

  • ALB exists in the region: zyz-alb-<region>

  • ALB is internet-facing (public)

  • ALB attached to the public subnets

  • Security group allows inbound:

    • 443/tcp from Cloudflare (preferred) or internet (temporary)
    • 80/tcp optional (only if you need HTTP→HTTPS redirect at origin)

  • Listener configured:

    • HTTPS :443 exists
    • Default action set (forward to target group OR fixed-response)

  • Target group exists (may be empty initially)

A.4 Origin TLS (before enabling Cloudflare proxy)​

Choose one origin TLS strategy and complete it:

Option 1 — Cloudflare Origin Certificate (recommended for fast rollout)

  • Origin cert installed/attached to ALB listener (or to origin component if using different ingress)
  • Cloudflare SSL mode set to Full (strict)

Option 2 — AWS ACM certificate per region

  • ACM cert issued in-region covering api.<region>.zayaz.io (or api.*.zayaz.io if applicable)
  • ACM cert attached to ALB HTTPS listener
  • Cloudflare SSL mode set to Full (strict)

A.5 Cloudflare DNS​

  • CNAME record exists:

    • api.<region>.zayaz.io → ALB DNS name (no URL, no path)

  • Proxy status:

    • DNS-only during initial validation
    • Switch to proxied only after TLS validation succeeds

A.6 Validation Tests (minimum)​

Run these tests after DNS is set (first with DNS-only):

  • dig api.<region>.zayaz.io returns expected CNAME chain

  • curl -I https://api.<region>.zayaz.io returns a valid TLS handshake

    • Acceptable early responses: 200/301/302/401/403/404/503 (503 is OK if targets not attached)

  • Browser test loads without certificate warnings

A.7 Security & Guardrails​

  • ALB only accepts TLS1.2+ (policy enforced)

  • If restricting to Cloudflare:

    • ALB security group allows only Cloudflare IP ranges (or use Cloudflare Tunnel / mTLS later)

  • Access logging enabled (ALB logs to an S3 logging bucket)

  • WAF strategy decided:

    • Cloudflare WAF (typical) OR AWS WAF (optional)

A.8 Go-Live Gate​

A region is considered ingress-ready when:

  • TLS works end-to-end (curl + browser)
  • DNS points to correct ALB DNS
  • Proxy can be enabled without breaking TLS
  • The region is added to the ZYZ allow-list for tenant.active_region

Appendix B: CIDR Allocation Table (Lock Early)​

This table provides a non-overlapping /16 per region for ingress VPCs. Locking this early prevents future peering/VPN overlap issues.

Rule: Do not reuse CIDRs across regions or environments. If you later introduce separate accounts/environments, allocate separate RFC1918 ranges per account.

AWS RegionSuggested VPC CIDR (/16)Notes
eu-north-110.20.0.0/16EU Nordics primary
eu-west-110.21.0.0/16EU Ireland
eu-west-210.22.0.0/16EU/UK London
eu-west-310.23.0.0/16EU Paris
eu-central-110.24.0.0/16EU Frankfurt
us-east-110.30.0.0/16NA Virginia
us-east-210.31.0.0/16NA Ohio
us-west-110.32.0.0/16NA California
us-west-210.33.0.0/16NA Oregon
ap-northeast-110.40.0.0/16AP Tokyo
ap-northeast-210.41.0.0/16AP Seoul
ap-northeast-310.42.0.0/16AP Osaka
ap-south-110.43.0.0/16AP Mumbai
ap-southeast-110.44.0.0/16AP Singapore
ap-southeast-210.45.0.0/16OC Sydney
me-central-110.50.0.0/16ME UAE
sa-east-110.60.0.0/16SA São Paulo
af-south-110.70.0.0/16AF Cape Town

Subnet suggestion (optional standard):

  • Public subnets (2 AZs): 10.xx.0.0/20 and 10.xx.16.0/20
  • Private subnets (2 AZs, if/when needed): 10.xx.32.0/20 and 10.xx.48.0/20


GitHub RepoRequest for Change (RFC)