Executive summary
Enterprise cloud deployments often deploy expensive next-generation firewalls for all network security, including internal virtual private cloud (VPC) traffic, without considering the significant cost overhead this creates.
For most intra-VPC communication scenarios, native security groups deliver equivalent Layer 4 protection at 70% to 80% lower cost, while providing better performance and simpler operations.
This blog post shows why firewalls should be reserved for specific deep packet inspection needs, while more granular internal network segmentation can be achieved far more efficiently through cloud native controls.
The problem of overengineered internal security
Why internal traffic control matters
Today's applications are a web of microservices and containers, constantly communicating with shared databases and serverless functions inside the cloud. This intense east-west traffic is the lifeblood of modern IT architectures. Relying on traditional, perimeter-focused security for this internal communication is not only inefficient, but also creates significant operational complexity and prohibitive costs.
The reality is that every millisecond of latency and every dollar of overhead created by a security bottleneck in this environment multiplies rapidly across a fleet of hundreds of queries per minute — a scale at which traditional approaches simply break down.
The default firewall assumption
Many organizations still rely on next-generation firewalls (NGFWs) for all internal network security, without questioning whether their advanced features are necessary. While NGFWs have a place for specific needs, like compliance or advanced threat detection, the best practice is to not unquestioningly apply them to all east-west traffic.
Instead, modern security strategies increasingly supplement or replace internal NGFWs with microsegmentation and cloud native tools to provide targeted protection without the unnecessary cost and complexity.
Two approaches: Complex vs simple
The firewall path: Centralized and expensive
Firewall-based intra-VPC control requires the routing of all internal traffic through centralized appliances or cloud firewall services. This means deploying virtual machines running firewall software (such as Palo Alto VM-Series or Fortinet FortiGate-VM) or using cloud native services like Amazon Web Services (AWS) Network Firewall.
The architectural complexity becomes apparent when you realize that normal VPC routing must be modified to force traffic through these inspection points. Route tables need updates, network address translation may be required, and high availability demands duplicate everything. Each connection between application tiers now travels through additional network hops, adding latency and creating potential bottlenecks.
This approach does not completely prevent lateral movements, as intersubnet and intrasubnet traffic within a VPC is not subjected to a similar kind of policy enforcement. As a result, there are gaps in both visibility of inter-VPC traffic and a lack of control to prevent lateral movements.
This approach also does not provide comprehensive visibility or control. Firewalls fundamentally cannot inspect all intra-VPC traffic, as intersubnet and intrasubnet communications within a VPC bypass these centralized inspection points entirely. This creates significant security gaps where lateral movement can occur undetected between workloads that never route through the firewall appliances.
The native security group approach: Distributed and efficient
Cloud native security controls work differently. AWS Security Groups, Azure Network Security Groups, and Google Cloud VPC firewall rules operate at the hypervisor level, filtering traffic before it reaches virtual machines. This distributed enforcement eliminates the need for centralized chokepoints and additional routing complexity.
Think of these controls as intelligent gatekeepers attached directly to each server, making decisions instantly without requiring traffic to detour through separate security appliances. They provide stateful filtering by automatically handling return traffic and connection tracking without the overhead of centralized processing.
These controls also help reduce the amount of traffic handled by conventional firewalls as egress traffic to the internet can be blocked at the security groups level itself for those sensitive workloads.
We would like to emphasize two important qualities of security groups:
Security groups provide complete visibility and control of all VPC traffic, including intersubnet and intrasubnet communications that firewalls cannot inspect. This comprehensive coverage enables true Zero Trust microsegmentation without the visibility gaps that characterize firewall-based approaches.
Additionally, when security groups block unwanted connections at the source, they significantly reduce the traffic burden on internet-facing firewalls, creating a layered defense that optimizes the performance and cost-effectiveness of perimeter security appliances.
Figure 1 illustrates the differences in traffic flow between firewall-routed and security group–filtered architectures.
The cost reality: Numbers that matter
Real-world cost comparison
Consider a mid-sized enterprise deployment with 150 virtual machines across web, application, and database tiers, generating 5 Gbps of average internal traffic in AWS US-East-1 region (Table).
NGFW-based architecture monthly costs
Line item |
Estimate (in US$) |
Range (in US$) |
|---|---|---|
NGFW virtual appliance pair (c5.2xlarge) |
$876 |
$792–$855 |
NGFW licensing (mid-tier, with discount) |
$2,400 |
$1,680–$2,400 |
Storage for logs/config (150 GB EBS) |
$120 |
$12–$15 |
Cross-AZ data transfer (5 Gbps sustained) |
$180 |
$2,160–$3,240 |
Analytics/log management |
Included |
Included |
Total |
$3,576 |
$4,644–$6,510 |
Security group–based architecture monthly costs
Line item |
Estimate (in US$) |
Range (in US$) |
|---|---|---|
AWS Security Groups |
$0 |
$0 |
VPC flow logs |
$45 |
$45–$75 |
CloudWatch monitoring |
$30 |
$30–$60 |
Network analytics service (GuardDuty/Athena/third-party) |
N/A |
$750–$1,500 |
Total |
$75 |
$825–$1,635 |
Overall comparison and savings
Option |
Total monthly cost (in US$) |
|---|---|
NGFW (with all features) |
$4,644–$6,510 |
Security groups + analytics |
$825–$1,635 |
Potential savings |
$3,019–$4,875 (82%–87%) |
Real-world monthly cost comparison of NGFW-based architecture and security group–based architecture
The difference is stark: US$4,875 in monthly savings, representing an 87% cost reduction. Over one year, this single architectural decision can save US$58,500 while improving performance.
Hidden operational costs
Beyond licensing and compute costs, firewalls introduce operational overhead that security groups avoid. Firewall management requires specialized skills, regular software updates, backup and recovery procedures, and complex change management when routing modifications are needed.
Security groups integrate natively with cloud infrastructure-as-code tools, enabling automated management and version control. This operational simplicity translates to lower staffing requirements and faster deployment cycles.
Modern segmentation platforms like Akamai Guardicore Segmentation simplify security group orchestration by providing intuitive policy constructs that automatically translate business requirements into appropriate security group rules across cloud platforms. This reduces the complexity of managing granular microsegmentation policies while ensuring a consistent security posture.
When each approach makes sense
Security groups handle most use cases
For typical enterprise scenarios, security groups provide sufficient protection. They excel at controlling which application tiers can communicate, restricting database access to specific ports and protocols, and implementing basic Zero Trust microsegmentation.
The key insight is that most internal traffic control requirements focus on "who can talk to whom" rather than "exactly what they are saying." Security groups answer the first question perfectly through stateful Layer-4 filtering, protocol restrictions, and source-destination controls.
Firewalls for specialized requirements
Firewalls become justified when organizations need deep packet inspection for compliance, advanced threat detection across internal communications, or application-layer control beyond basic port filtering.
For example, financial services organizations might require transaction monitoring between internal systems. Healthcare environments might need specialized protocol inspection for medical device communications. These scenarios represent legitimate use cases where firewall capabilities justify their cost.
Implementation decision framework
Start with native controls
The recommended approach begins with security groups for all routine intra-VPC filtering needs. This establishes effective segmentation at minimal cost and minimal latency while providing operational experience with cloud native security controls.
Organizations can then evaluate specific traffic flows that might benefit from advanced inspection. Rather than defaulting to firewalls everywhere, this approach applies expensive tools only where their advanced capabilities provide genuine value.
A layered approach like this ensures complete visibility into the VPC’s communications, optimizes the security costs, and provides multiple layers of controls to minimize lateral movements, application risks, and data exfiltration risks.
Migration strategy
Existing firewall-heavy architectures can be optimized by identifying traffic flows that only require Layer-4 filtering. Database replication, web-to-application server communication, and similar standard patterns typically work well with security group controls.
The migration process should prioritize noncritical environments first, which allow teams to gain confidence with native controls before applying them to production systems.
Cloud platform considerations
AWS Security Groups
AWS Security Groups attach to Elastic Network Interfaces and provide stateful filtering with automatic return traffic handling. They integrate seamlessly with Auto Scaling Groups and load balancers, scaling automatically as infrastructure grows.
The key AWS advantage is zero additional cost for security group processing, regardless of traffic volume or rule complexity within reasonable limits (50 rules per security group, 16 security groups per interface).
Azure Network Security Groups
Azure Network Security Groups can be applied at subnet or network interface levels, providing flexibility in implementation approaches. Application Security Groups enable logical service grouping, making rule management more intuitive for complex applications.
Azure's integration with Azure Policy enables organization-wide governance of security rules, ensuring consistent application of security standards across multiple subscriptions.
Google Cloud VPC firewall rules
Google Cloud Platform’s approach uses project-wide firewall rules with tag-based targeting, enabling sophisticated rule inheritance through hierarchical policies. This model works particularly well for organizations with complex multiproject structures.
Enterprise-level policy management
Cloud platforms provide native hierarchical security controls that firewalls cannot replicate. Azure Virtual Network Manager enables tenant-level network security group rule management, while Google Cloud Platform supports organization-level firewall policies. These cloud native governance capabilities allow enterprises to define organization-wide compliance policies that automatically propagate across all virtual networks, creating consistent security postures that traditional firewall solutions cannot match in scope or efficiency.
Some organizations may view a single vendor's NGFW as a tool to manage multicloud segmentation policy because the idea of using a familiar interface across different cloud environments is appealing.
However, this approach often fails to deliver a truly unified solution. NGFWs are still deployed as separate virtual appliances in each hub VPC in a hub-and-spoke cloud network architecture, creating multiple disparate management points. This is not a single interface, but rather a collection of consoles that still miss crucial intra-VPC traffic.
A solution like Akamai Guardicore Segmentation, by contrast, provides a single, centralized policy engine and management console to orchestrate and enforce a consistent Zero Trust policy across on-premises, AWS, Azure, and Google Cloud environments. It delivers true multicloud segmentation without the complexity of routing, the need for virtual appliances, or the visibility gaps that characterize firewall-based approaches.
Figure 2 is a decision matrix for choosing the appropriate security controls according to an organization’s requirements.
Conclusion
The evidence demonstrates that most intra-VPC traffic control scenarios benefit from cloud native security groups rather than traditional firewall approaches. The 70% to 80% cost reduction combines with improved performance and operational simplicity to create compelling business value.
Organizations should adopt a risk-based approach to network security tool selection. Reserve firewalls for scenarios that require deep packet inspection or advanced threat detection capabilities. For comprehensive microsegmentation and application tier isolation, native cloud security controls provide superior cost-performance characteristics while maintaining necessary security posture.
Recommendation
The strategic recommendation is clear: Start with security groups for intra-VPC control, then selectively apply firewall capabilities only where advanced features provide genuine value beyond basic filtering. This approach optimizes both security effectiveness and operational costs while building cloud native expertise within security teams.
Speak with our experts to learn more.
Tags