Ingress and Egress Rules
You set up ingress and egress rules by defining allowed ports, protocols, and IP ranges. Ingress rules filter incoming traffic, while egress rules filter outgoing traffic leaving your workloads. Many teams start by opening broad IP blocks so engineers can work fast. Broad network permissions expose databases and internal apps to unwanted network scans. When a rule is too wide, any host on that network can reach your port. How ingress and egress rules work in cloud networks Cloud networks use
AWS Config Rules: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up ingress and egress rules by defining allowed ports, protocols, and IP ranges. Ingress rules filter incoming traffic, while egress rules filter outgoing traffic leaving your workloads. Many teams start by opening broad IP blocks so engineers can work fast. Broad network permissions expose databases and internal apps to unwanted network scans. When a rule is too wide, any host on that network can reach your port.
How ingress and egress rules work in cloud networks
Cloud networks use virtual firewalls to check every packet that enters or leaves a server. Each rule looks at five main traits of a network packet. These traits are source IP, destination IP, source port, destination port, and protocol. If a packet matches an allow rule, the firewall lets it pass through. If a packet does not match any rule, the firewall drops it right away.
Stateful firewalls remember valid requests and let the return traffic back in by default. You do not need to write a separate rule for reply packets on stateful setups. Stateless network lists work in a different way and check both directions one by one. With stateless rules, you must allow both the inbound request and the outbound reply. Teams often combine host security groups with subnet network lists for extra safety.
To set up ingress rules, you list the exact client IPs that need entry. Then you pick the single port that your database or web server listens on. To set up egress rules, you restrict where your internal servers can send data out. Good egress filters stop a compromised server from sending data to unknown external hosts. You only allow outbound traffic to known partner APIs, package hosts, and internal subnets.
What network rules solve and what they miss
Network rules are great at stopping random bots from hitting your private server ports. They reduce the attack surface by hiding internal services from the public internet. They also keep staging servers from talking to production databases across different virtual networks. A strict egress setup prevents malware from calling home to an attacker control server.
Still, network rules only look at IP addresses and port numbers on the wire. Once a packet passes the port check, the firewall does not inspect the session. The firewall knows which IP address sent the packet, not which person logged in. Two engineers sharing a corporate VPN will show up with the exact same source IP. Network logs will show bytes sent, not which SQL query or shell command ran.
AWS Config Rules: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Network rules also cannot stop a valid user from running a bad drop table statement. If port access is open, the user can read thousands of rows of private data. A firewall will never mask emails, phone numbers, card numbers, or national IDs in results. Managing static IP lists also becomes painful when remote developers change home networks often. Teams end up opening wide subnet ranges just to keep daily work moving forward.
Best practices for managing network traffic filters
Start every new virtual network with a default deny rule for both directions. Only open the exact ports that your app needs to run its daily tasks. Replace wide IP ranges with specific host addresses or peer security group references. Review your firewall rule list every month to remove old entries from past projects. Tag every rule with an owner name and a clear reason for the open port.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the main difference between ingress and egress traffic?
Ingress traffic starts outside your network and travels inward toward your local servers. Egress traffic starts inside your network and travels outward to an external destination.
Why should teams restrict egress traffic on database servers?
Database servers rarely need to start outbound calls to the public web on their own. Blocking egress traffic stops attackers from stealing data or downloading bad tools onto the host.
Do ingress and egress rules replace user roles inside a database?
No, network rules only control which IP addresses can reach the database network port. You still need database roles and session controls to manage what queries users can run.