Network topologies
The five ways a customer network reaches TRANXACT, what the network team prepares for a VPN or a private connection, /22 address planning and the subnet layout, hub-and-spoke peering, DNS and certificates, egress, and operator access.
The network is where most deployments lose time. Every option below is available on AWS, Microsoft Azure and Google Cloud; only the product names differ.
Five connectivity options
| Option | Status | What it is | Fits when | R&R |
|---|---|---|---|---|
| Public HTTPS | Default | Users reach TRANXACT through the load balancer and WAF over TLS 1.2+; SSO through the customer IdP. | Everything is a web user or an HTTPS integration. No network build; fastest to go live. | INFRA_2.6.01 (Standard) |
| Site-to-site VPN | Optional | Redundant IPsec tunnels from the customer network to the TRANXACT VPC/VNet. | Private integrations (MES, legacy), admin restrictions. | INFRA_2.2.03 – 2.2.05 |
| Private connection | Optional | AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect. Predictable bandwidth and latency; VPN as the automatic backup path. | High, steady volume or a policy that bans the internet path. | INFRA_2.2.06 – 2.2.07 |
| Peering / private link | Optional | VPC/VNet peering with the customer’s landing zone in the same cloud; private endpoints for selected services; local or global peering. | The customer already runs a landing zone in the same cloud — the lowest-latency private path. | INFRA_2.2.08, 2.2.10 |
| Transit hub | Optional | AWS Transit Gateway, Azure Virtual WAN or GCP Network Connectivity Center; TRANXACT attaches as a spoke. | Hub-and-spoke landing zones. | INFRA_2.2.09 – 2.2.10 |
What the customer network team prepares, per region
| Item | Site-to-site VPN (IPsec) | Private connection |
|---|---|---|
| Customer device | An IPsec-capable firewall or router with a static public IP | A customer or carrier edge router at a cloud meet-me location |
| Tunnels / circuits | Two tunnels per region to separate cloud gateways | Redundant circuits recommended; VPN as the backup path |
| Protocol | IKEv2, AES-256, SHA-256, DH group 14 or higher (proposed default) | BGP over a private virtual interface / peering |
| Routing | BGP preferred; static routes accepted | BGP with agreed ASNs and route filters |
| Bandwidth | Up to the gateway limit of the chosen cloud | The circuit size the customer orders, e.g. 1–10 Gbps |
| Live DR region | A second pair of tunnels to the Live DR region (INFRA_2.2.04) | A circuit or VPN to the Live DR region |
| Ownership | Customer: device, ISP, on-premise firewall rules (Excluded). TRANXACT: the cloud gateway. | Customer: circuit and carrier contract (Excluded). TRANXACT: the gateway attachment. |
Order a private-connection circuit at contract signature. Circuits often take weeks from the carrier; run on VPN until the circuit is live.
Address planning
- At least a /22 private (RFC 1918) range per region — 1,024 addresses.
- A second, different /22 for the Live DR region.
- Neither may overlap any customer, partner or landing-zone network — offices, data centres, other clouds.
- Kubernetes pod and service ranges are planned inside or alongside the range, and are subject to the same no-overlap rule if they are routed.
- Avoid the cloud provider’s reserved and link-local ranges.
- Providing the ranges is the customer’s task (INFRA_2.2.02, Excluded). Changing them after the build means a rebuild (INFRA_2.2.12, Additional Service, by change request).
Collect the customer’s full IP plan before choosing. One overlap blocks VPN, peering and DR routing at once, and one missing /22 can hold up the whole build.
The subnets inside one region
| Subnet | Holds |
|---|---|
| Ingress | Load balancer, WAF, public IPs |
| Node · AZ1, AZ2, AZ3 | Kubernetes workers, one subnet per zone |
| Database | Private only, with no internet route |
| Egress | NAT gateway to allow-listed destinations |
| Gateway | VPN / private-connection termination |
| Admin | Bastion / zero-trust access point for operators |
One way to carve 10.40.0.0/22 — an illustration for training, not a TRANXACT standard; the Ledger Architect sets the real plan at design:
Primary region 10.40.0.0/22 (10.40.0.0 - 10.40.3.255)
ingress 10.40.0.0/26
gateway 10.40.0.64/27
admin 10.40.0.96/27
egress (NAT) 10.40.0.128/27
database AZ1 10.40.0.192/27
database AZ2 10.40.0.224/27
nodes AZ1 10.40.1.0/24
nodes AZ2 10.40.2.0/24
nodes AZ3 10.40.3.0/24
Live DR region 10.40.4.0/22 (same layout, never overlapping the primary)Peering: hub and spoke
For a customer with an existing landing zone in the same cloud, TRANXACT is the spoke and the customer’s landing zone the hub. The peering is the point of demarcation. The hub gateway carries traffic on to offices and data centres, and the customer may put its own firewalls or network virtual appliances in the hub.
Transitive routing through the hub must be explicitly allowed, and hub routing and inspection are the customer’s (INFRA_2.2.10, Excluded). Agree route ownership and inspection points with the customer’s cloud team before the build.
Name resolution and certificates
| Customer provides | TRANXACT provides |
|---|---|
| The domain or subdomain, e.g. erp.customer.com (INFRA_2.3.01) | Ingress endpoints in both live regions behind a global traffic manager (INFRA_2.3.03) |
| A public-CA certificate for the FQDN, wildcard allowed (INFRA_2.3.02) — unless the managed certificate option is contracted (INFRA_2.3.06) | Installation and renewal of the certificate, with an expiry alert 30 days ahead (INFRA_2.3.05, TO_4.11.01) |
| The public DNS record; a private zone or conditional forwarding if private access is used | A low DNS TTL, region-specific hostnames for monitoring and drills, and the DNS failover runbook (INFRA_2.3.04) |
Users and integrations connect to one location-agnostic name. It resolves through the traffic manager across both live regions, so a Live DR failover needs no reconfiguration anywhere.
Never use .local suffixes, hard-coded IP addresses or region-specific names in integrations. An expired certificate or a missing DR record is the most common avoidable outage — put both in the joint runbook.
Data in transit
| Inbound to TRANXACT | Outbound from TRANXACT |
|---|---|
| HTTPS only (TLS 1.2+) through the load balancer and WAF | Egress through NAT with an allow-list of destinations |
| SSO through the customer IdP; MFA enforced there | Typical: banks, tax / e-invoicing portals, payroll providers, email, the AI engine |
| APIs authenticated per integration client with scoped roles | Outbound calls use TLS; credentials held in a secrets store |
| Optional IP allow-listing or private-only access | No other internet egress from nodes or the database |
| Service traffic inside the cluster encrypted |
The customer lists every outbound destination (INFRA_2.6.03, Excluded); TRANXACT maintains the allow-list, one service request per destination (INFRA_2.6.02).
A missing allow-list entry blocks payments or filings on day one. List them during design, not during go-live week.
How TRANXACT operators get in
- Through a zero-trust or bastion access point in the dedicated admin subnet. No node or database is exposed directly.
- Just-in-time, time-boxed elevation, approved per change or incident — approved by the customer (TO_4.5.05, Excluded).
- MFA on every operator identity; least privilege; role-based.
- Every admin session and cloud-API call logged, and exportable to the customer’s SIEM.
- Operators administer the platform. Business data is accessed only under a customer-approved ticket.
Agree at design who on the customer side may approve operator elevation, and whether production data access must be co-signed.
Common integration scenarios
| Scenario | Pattern | Direction | Connectivity | Endpoint owner |
|---|---|---|---|---|
| Banking & payments | API / host-to-host SFTP | Both | Egress allow-list; private link where offered | Customer |
| Tax & e-invoicing | API | Outbound | Egress allow-list | Customer |
| Payroll & benefits | API / SFTP | Both | Egress allow-list or VPN | Customer |
| Identity | Federation (SAML / OIDC), SCIM | Inbound | Public HTTPS | Customer |
| BI & data platforms | Read API / scheduled extract | Outbound | Private link or HTTPS | Joint |
| Legacy & shop floor | API / events | Both | VPN or private connection | Customer |
| Email & notifications | SMTP / API | Outbound | Egress allow-list | Joint |
| AI engine for ASK | API | Outbound | Egress allow-list | TRANXACT, or the customer with BYOK |
Every integration goes through TRANXACT APIs or managed file transfer. Nothing connects to the database.
Values marked proposed default are the deployment guide’s recommended starting points. Confirm each one per customer; the contract, order form, SLA and DPA prevail over this page.