India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Cloud Network Security: Segmentation, Inspection & Egress Control
Cloud network security is the set of controls that decide which traffic may enter, leave and move inside your cloud networks: segmentation, firewall inspection, private service access and egress filtering. NTSPL designs and builds these layers on AWS, Azure and Google Cloud so that a single compromised server cannot reach the database tier or send data to the internet unchecked.
Delivered on
In scope
Flat Networks, Open Egress and Why Perimeter Rules Are Not Enough
Cloud networks in Indian enterprises are often flatter than the data centres they replaced. VPC peering meshes connect every environment to every other, security groups allow 10.0.0.0/8, and dozens of VMs carry public IPs because that was the quickest way to give a vendor SSH. Outbound traffic is almost never filtered, so malware or a compromised build agent can reach any domain on the internet. When a single web server is breached, nothing in the network stops lateral movement to the payments database or bulk exfiltration over HTTPS.
NTSPL rebuilds the network around a hub that inspects traffic between zones and to the internet, with workloads in spokes that have no direct public path. Segmentation follows data sensitivity rather than team boundaries. Administrators reach servers through identity-aware proxies instead of open ports, PaaS databases and storage are reached over private endpoints, and outbound traffic passes a domain allowlist. Everything is built as Terraform so rules stay reviewable.
Network Symptoms That Point to a Segmentation Rebuild
Signals you need Cloud Network Security
- More than 20 VMs have public IPs, or SSH and RDP are open to 0.0.0.0/0 anywhere
- Security groups, NSGs or firewall rules exceed 300 with no owner or review date
- Outbound internet traffic from production is unfiltered and nobody can list required external domains
- Managed databases and storage are reached over public endpoints with IP allowlists
- Auditors or a penetration test have shown lateral movement from a web tier to the data tier
When to choose something else
- Your exposure is at the application layer, such as OWASP attacks, bots and API abuse: see Web Application Protection.
- You are still choosing between VPN and dedicated links for a migration; that is a Network & Connectivity Assessment decision.
Zones, Inspection Points and Private Paths We Build
Zoning model
Define 4-6 zones such as internet-facing, application, data, management, partner and shared services, with an allowed-flow matrix between them signed off by application owners.
Central inspection
Deploy AWS Network Firewall, Azure Firewall Premium or Cloud NGFW Enterprise in a hub to inspect east-west traffic between zones and all north-south egress.
Egress control
Replace open outbound access with FQDN and domain allowlists, DNS filtering and NAT through inspected paths only.
Private service access
Move managed databases, storage, key vaults and container registries to private endpoints, PrivateLink or Private Service Connect, and disable public network access.
Administrative access
Retire public SSH and RDP in favour of Systems Manager Session Manager, Azure Bastion or Identity-Aware Proxy TCP forwarding.
Hub Inspection and Zoned Spokes: The Reference Network
Hub-and-Spoke Inspection Network with Egress Allowlisting
Spoke networks for each zone route all inter-zone and outbound traffic through a hub where a managed firewall applies IPS and domain rules. Workloads have no public IPs; administrators enter through identity-aware access, and PaaS services sit behind private endpoints.
Select any component
Hub-and-Spoke Inspection Network with Egress Allowlisting: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Network Firewall, Azure Firewall and Cloud NGFW in Practice
Inspection VPCs need Transit Gateway appliance mode enabled to avoid asymmetric drops across Availability Zones; Network Firewall accepts Suricata-compatible rules.
Firewall Premium adds TLS inspection and IDPS; private DNS zones for Private Link must be linked centrally or name resolution silently returns public IPs.
Hierarchical policies at the org and folder level enforce deny rules projects cannot override; Secure Web Proxy handles URL-based egress allowlisting.
Inspection Placement, TLS Decryption and Egress Policy Choices
Where to inspect east-west traffic
Inspect between zones, not within them. Sending every app-to-app call through a central firewall adds latency of 1-3 ms per hop and firewall processing cost per GB. Use security groups or NSGs for intra-zone control and reserve firewall inspection for app-to-data, partner and management flows. Inspect within a zone only for PCI or highly regulated workloads.
TLS inspection
Decrypt outbound traffic to uncategorised and newly registered domains, where malware hides, but bypass banking, healthcare and government portals to avoid breaking certificate pinning and to limit privacy exposure under the DPDP Act. Inbound TLS is better inspected at the WAF. Budget for an internal CA and plan certificate distribution to every VM before enabling.
Egress allowlist strictness
Run the firewall in logging mode for 2-4 weeks, then build the allowlist from observed domains, usually 80-200 for a mid-size estate. Allow wildcards only for provider domains such as OS update mirrors. Production should default-deny; development can default-allow with alerting. Review new-domain requests within one business day or teams will route around the control.
One hub or one per region
Use one inspection hub per region, for example Mumbai and Hyderabad on AWS or Pune and Chennai on Azure, so DR failover does not depend on cross-region inspection. Share rule sets through Firewall Manager or policy inheritance so both hubs enforce identical policy. A single global hub works only if all workloads sit in one region.
Re-Segmenting a Live Network Without Breaking Flows
Flow discovery from flow logs
Enable flow logs everywhere and build the real communication matrix between workloads and external domains.
Zone design and flow sign-off
Agree zones and allowed flows with application owners, flagging unexplained connections.
Hub and firewall build in alert mode
Deploy the hub and firewall, route one non-production spoke through it and tune IPS false positives.
Spoke migration and public IP removal
Move spokes behind the hub one at a time, switch admin access to identity proxies and release public IPs.
Enforce egress deny and private endpoints
Switch egress to default-deny and disable public network access on PaaS services.
What you receive
Exposure and Rule Hygiene Measures After the Rebuild
| KPI | Typical target |
|---|---|
| VMs with public IP addresses | Only load balancers and documented exceptions |
| Inbound SSH/RDP rules from the internet | Zero |
| Production egress through allowlisted paths | 100% |
| Firewall rules with no hits in 90 days | Under 5% after quarterly cleanup |
Asymmetric Routing, Rule Sprawl and Other Network Pitfalls
| Risk | How NTSPL prevents it |
|---|---|
| Asymmetric routing through a multi-AZ firewall drops long-lived connections | Appliance mode or equivalent symmetric routing is enabled and tested with database replication traffic before cutover. |
| Default-deny egress breaks a monthly job that calls an undocumented API | Alert-mode observation covers a month-end and a quarter-end cycle before deny is enforced. |
| Private endpoint DNS misconfiguration sends traffic to public endpoints | Central private DNS zones and a test that resolves each PaaS endpoint from every spoke. |
Cloud-native firewall or a virtual NGFW appliance from our on-prem vendor?
Choose the cloud-native firewall unless you have a hard requirement it cannot meet. AWS Network Firewall, Azure Firewall Premium and Cloud NGFW Enterprise scale automatically, need no patching or HA design, and are managed through the same Terraform and policy tooling as the rest of the estate. A virtual appliance from Palo Alto, Fortinet or Check Point makes sense if your SOC is built around that vendor's console, you need identical rules on-prem and in cloud, or you need features like user-ID-based policy. Expect appliances to cost more in licences and operations time, and plan for throughput limits per instance.
Key facts: Cloud Network Security
Cloud Network Security in Practice
2 Cloud Network Security scenarios, from Logistics (express parcel and B2B freight) and Healthcare (multi-city hospital chain), plus related platform case studies.
Express logistics firm closes public SSH on 134 VMs and allowlists all production egress
Hospital chain segments HIS, PACS and LIS on AWS and blocks unapproved outbound traffic
Specialty chemicals group links 6 plants and HQ to AWS with dual-path hybrid network
Container terminal links TOS, gate automation and Azure over dual ExpressRoute
Cloud Network Security: Frequently Asked Questions
What does a cloud network security rebuild cost?
NTSPL's design and build for a single cloud with 10-30 spokes typically runs INR 12-22 lakh over 9-12 weeks. Run costs depend on the firewall: a managed firewall in two Availability Zones plus data processing often lands between INR 1.5 and 4 lakh a month per region for mid-size estates.
Will removing public IPs affect vendor support access?
Vendors move to identity-based access through Session Manager, Azure Bastion or Identity-Aware Proxy, signing in with their own accounts and MFA. Access is logged per session, which most vendors find simpler than managing IP allowlists, and you can revoke it instantly.
How does this support CERT-In logging requirements?
Flow logs and firewall logs from every spoke are sent to a central store or SIEM in an Indian region and kept for at least 180 days, matching CERT-In's April 2022 directions. Clock sources are aligned so timestamps hold up during incident reporting.
Do we need TLS inspection?
For outbound traffic from servers, inspecting connections to uncategorised domains catches most command-and-control and exfiltration attempts. Full decryption of all traffic is rarely worth the certificate management effort. We usually decrypt selectively and leave regulated portals and pinned applications on bypass.
Can segmentation be done without downtime?
Yes. Spokes are moved behind the hub one at a time during agreed windows, with flow logs confirming each application's traffic before and after. Rules start permissive and logged, then tighten, so most migrations complete without user-visible impact. Database replication and HL7 or API integrations are moved last, after a dry run.
How is micro-segmentation different from zoning?
Zoning separates groups of workloads by sensitivity and inspects traffic between them. Micro-segmentation applies identity-based rules per workload, so two servers in the same zone cannot talk unless explicitly allowed. We combine both: zones at the firewall, micro-segmentation through security groups and NSGs.