Architecture

Outbound has two clearly separated halves:

• The data plane: gateway instances running in your VPCs, forwarding your egress traffic. Everything on the forwarding path runs locally on the gateway.
• The control plane: Outbound’s managed backend, which provisions and configures gateways through the cross-account role and receives flow telemetry. It is never on the forwarding path.

Traffic flow

 Private subnet                      Public subnet
┌─────────────────┐                ┌──────────────────────────────────┐
│  EC2 / ECS /    │   route table  │        Outbound gateway          │
│  pod workload   │──0.0.0.0/0────▶│                                  │
└─────────────────┘                │  1. eBPF sensor (observe only)   │
                                   │  2. Linux forwarding + conntrack │
                                   │  3. iptables NAT (masquerade)    │
                                   └────────────────┬─────────────────┘
                                                    │ Elastic IP
                                                    ▼
                                        Internet gateway → Internet

1. A workload in a private subnet opens an outbound connection. Its subnet’s route table sends 0.0.0.0/0 traffic to the gateway (details).
2. The packet arrives at the gateway’s network interface, where the eBPF sensor observes it (and never alters it — see below).
3. The Linux kernel forwards the packet, tracking the connection in conntrack.
4. iptables NAT rewrites the source address to the gateway’s, so the traffic leaves via the gateway’s Elastic IP through the VPC’s internet gateway.
5. Return traffic matches the conntrack entry and flows back to the workload.

The gateway instance

Each gateway is an EC2 instance in your account, launched from a hardened, purpose-built Amazon Linux AMI on Graviton (ARM) instance types. It is visible, taggable, and auditable like any other instance you run — look for Name=cloudphilos-gateway. Its NAT stack is deliberately boring:

• IP forwarding enabled, with kernel network settings tuned for a forwarding workload — including a connection-tracking table sized for over a million concurrent connections.
• iptables masquerade: a standard POSTROUTING masquerade rule rewrites outbound source addresses, and FORWARD rules permit new outbound connections and established return traffic. There is no DNAT, no packet mangling, no traffic filtering — the gateway forwards everything its security group accepts.
• Source/destination check disabled on the instance, as required for any EC2 instance that forwards traffic it didn’t originate.
• All services (NAT setup, the sensor, host metrics) run under systemd with automatic restarts, and the NAT configuration is re-applied on every boot.

The eBPF flow sensor

Visibility comes from an XDP (eBPF) program attached to the gateway’s network interface. Its design principle: observation can never affect forwarding.

• The program returns XDP_PASS for every single packet, unconditionally. It has no code path that can drop, modify, or redirect traffic.
• It maintains per-flow counters (packets, bytes, last seen) for each connection 5-tuple in a fixed-size, memory-bounded map.
• For each new TCP connection it captures at most the first 3 packets (up to 1460 bytes each) so the userspace sensor can extract the destination domain — the TLS SNI for HTTPS, or the Host header for HTTP. Once the domain is found (or the packet budget is spent), capture stops for that flow; payload beyond that is never inspected.
• If the sensor’s buffers are ever full, packets are simply not recorded — forwarding is unaffected. Telemetry is strictly fail-open (more on reliability).

The userspace sensor aggregates flow records — source private IP, destination IP and domain, ports, protocol, byte and packet counts — and reports them in batches to Outbound’s ingest API over HTTPS, authenticated with the API key held in your Secrets Manager. Flow metadata leaves your account; packet payloads do not.

Resources Outbound creates in your VPCs

Resource	Details
Gateway EC2 instance(s)	Tagged Name=cloudphilos-gateway, one or more per managed VPC, in public subnets.
Security group	cloudphilos-gateway-<vpc-id>, one per VPC. Ingress: your VPC CIDR only. Egress: open (it’s an internet gateway).
Elastic IPs	The gateway’s egress IP, plus pooled spares tagged do-not-delete-cloudphilos-gateway that preserve your egress IP across gateway replacements.
Route entries	Only the 0.0.0.0/0 route in private subnets’ route tables. See Route Table Management.

Outbound never creates or modifies VPCs, subnets, internet gateways, your security groups, or your workloads.

Control plane boundary

The control plane’s only two touchpoints with your environment are:

1. The cross-account role, used for discovery and gateway lifecycle operations — every permission is listed in the AWS connector reference.
2. The ingest API, which receives flow metadata and host metrics from gateways over HTTPS (outbound connections initiated by the gateway — nothing connects into your network).

Received telemetry is processed and stored in Outbound’s analytics platform, where the dashboard queries it per tenant. Because the control plane sits outside the forwarding path, its availability has no effect on your traffic — see Reliability.