Skip to content

FAQ

Does Multistax Outbound add latency to my traffic?

Section titled “Does Multistax Outbound add latency to my traffic?”

Negligibly. The gateway is a straight Linux forwarding path (route → forward → NAT) in the same VPC as your workloads, and the eBPF sensor observes packets without touching them. You’re replacing one NAT hop (the AWS NAT Gateway) with another (the Multistax Outbound gateway) — not adding one.

Can Multistax Outbound’s sensor drop or block my traffic?

Section titled “Can Multistax Outbound’s sensor drop or block my traffic?”

No, by construction. The XDP program’s only verdict is “pass”; it has no code path to drop, modify, or redirect a packet. If telemetry buffers fill up, Multistax Outbound loses visibility data — never your packets. See Reliability.

Does Multistax Outbound see my packet payloads?

Section titled “Does Multistax Outbound see my packet payloads?”

The sensor inspects at most the first 3 packets of each new TCP connection, solely to extract the destination domain from the TLS SNI or HTTP Host header. Encrypted payloads can’t be read (Multistax Outbound does no TLS interception), payload bytes are not stored or transmitted, and only flow metadata — IPs, ports, domain, byte/packet counts — leaves your account. See Security.

What happens if Multistax Outbound’s backend goes down?

Section titled “What happens if Multistax Outbound’s backend goes down?”

Your traffic keeps flowing — the forwarding path has no runtime dependency on our control plane. You’d see stale dashboards and paused configuration changes, nothing more. See Reliability.

Local services auto-restart via systemd; an unrecoverable instance is replaced with a new one that inherits the same Elastic IP. New connections from the affected subnets are interrupted during replacement. Multi-AZ layouts limit any single failure to one zone’s subnets.

Not during normal operation. Gateway upgrades, resizes, and replacements all preserve the Elastic IP via the spare-IP pool — Multistax Outbound aborts an operation rather than complete it with a different IP. Your IP changes only at offboarding.

Can I choose which VPCs and subnets Multistax Outbound manages?

Section titled “Can I choose which VPCs and subnets Multistax Outbound manages?”

Yes. Networks are managed per-VPC, and only after you enable them — the initial scan is read-only. Public subnets’ routing is never touched, and unmanaged VPCs are never modified.

The gateway forwards and attributes IPv4 traffic today. If IPv6 egress visibility matters for your environment, let us know at servicedesk@sue.nl — it directly informs our roadmap.

TCP, UDP, and ICMP flows are tracked and attributed. Domain extraction (SNI/Host) applies to TCP. Other IP protocols are forwarded but not individually attributed.

Can I use Multistax Outbound across multiple regions and accounts?

Section titled “Can I use Multistax Outbound across multiple regions and accounts?”

Yes. Deploy the onboarding stack per region (StackSets makes this one step) and register each account in the dashboard. Gateways and their telemetry are managed per region.

Do I need to change my workloads, AMIs, or security groups?

Section titled “Do I need to change my workloads, AMIs, or security groups?”

No. Workloads keep their subnets, security groups, and configuration. The only change in your network is the private subnets’ default route — see Route Table Management.

Why must I remove routes, EIPs, and NAT gateways from Terraform?

Section titled “Why must I remove routes, EIPs, and NAT gateways from Terraform?”

Because after cutover Multistax Outbound owns their state, and two owners means an apply/reconcile fight that can break egress or release your static IP. Full explanation and copy-paste fixes in Terraform & IaC.

Yes — it’s an EC2 instance in your account, tagged Name=cloudphilos-gateway, visible in your console, CloudTrail, and VPC Flow Logs, and managed via AWS Systems Manager. Don’t stop, resize, or modify it manually, though: the control plane will treat manual changes as drift.

How current is the application attribution?

Section titled “How current is the application attribution?”

New EC2 instances and ECS tasks are registered by the discovery Lambda within seconds of entering the running state; Kubernetes pods are registered by the in-cluster sensor. Flows from an IP that isn’t registered yet appear with IP-level detail and gain the application name once registration catches up.