Ingress and Egress Traffic
Ingress and egress traffic describe data moving in and out of a network. Ingress is data coming in, while egress is data going out. Teams set up firewall rules to filter both directions by IP and port. When teams write broad network rules, any host on a subnet can talk to databases. A wide rule lets bad queries or scripts move across the network with no checks. How ingress and egress traffic rules work Every network splits data flow into two basic paths based on direction. Packets that start
East-West Traffic Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Ingress and egress traffic describe data moving in and out of a network. Ingress is data coming in, while egress is data going out. Teams set up firewall rules to filter both directions by IP and port. When teams write broad network rules, any host on a subnet can talk to databases. A wide rule lets bad queries or scripts move across the network with no checks.
How ingress and egress traffic rules work
Every network splits data flow into two basic paths based on direction. Packets that start outside a network and enter it count as ingress. For example, a user request hitting a public web app is inbound flow. An engineer opening a database tool from a laptop also creates inbound packets.
Egress is the reverse path for data leaving the local network boundary. When an internal server downloads a software patch, those packets count as outbound flow. When a worker node sends data to an external API, that is also outbound.
Cloud teams manage ingress and egress traffic with stateful security groups and subnet lists. Stateful rules track each active network session from start to finish. If a rule allows an inbound packet, the return response goes out by default. If a rule allows an outbound request, the reply packet comes back in.
Teams usually block all inbound ports except the exact ones an app needs. For example, a database subnet might only accept inbound packets on one database port. Teams often leave outbound rules wide open so servers can fetch software updates. Stricter setups block all outbound paths except approved partner IP ranges.
Where network port rules fall short
Network rules do a good job of stopping random scans from the public web. They keep unknown IP addresses from reaching your private database or server ports. They also stop internal hosts from sending data to random outside servers.
East-West Traffic Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, network rules only check IP addresses, ports, and basic packet headers. They cannot see who the user is or what command runs inside the session. Once a firewall opens a port for an engineer, the network step is done. The firewall does not read the SQL query or shell command in flight.
Shared network paths make this problem much worse for growing engineering teams. When engineers use a VPN, they all share the same internal IP pool. The database firewall must allow that whole IP pool to reach the database port. Every person on the VPN can now reach the port with the same network rights.
Database credentials still sit on laptops or in shared team vaults. If an engineer runs a drop table command, the firewall lets the packets pass. If a query returns raw emails, phone numbers, or card numbers, the firewall sends them out. Egress rules see normal return packets on an open session and let them through. To control risk, teams must check single commands and mask sensitive fields in results.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the main difference between ingress and egress?
Ingress is any network data that starts outside and enters your private network. Egress is any network data that starts inside your network and goes out.
Why do teams block egress traffic on private subnets?
Open outbound rules let bad scripts send stolen data to outside servers. Strict outbound rules stop hosts from talking to unknown IP addresses on the web.
Do firewall rules protect database data during a user session?
No, firewall rules only check IP addresses and ports when a session starts. They do not inspect SQL queries or rewrite emails and card numbers in results.