Security Architecture

Network Security Architecture

Designing layered network security: firewalls, WAF, IDS/IPS, VPC segmentation, PrivateLink, east-west traffic inspection, and Zero Trust Network Access.

⏱ 10 min read

What it is

Network security architecture defines how traffic flows are controlled, inspected, and logged to prevent unauthorised access and detect attacks at the network layer. In cloud-native environments, this is primarily implemented through VPC (Virtual Private Cloud) design — separating public-facing resources (load balancers, CDN edges) from application servers and databases in private subnets, with controlled ingress and egress at every boundary. The key controls are: Security Groups (stateful, instance-level virtual firewalls — the primary control for AWS/GCP/Azure), Network ACLs (stateless, subnet-level — second line of defence, often used for explicit deny rules), WAF (Web Application Firewall — Layer 7, inspects HTTP request content, blocks OWASP top-10 attacks, SQL injection, XSS), and Next-Generation Firewall (NGFW) (inspects traffic at application layer with deep packet inspection, TLS termination/inspection, and IDS/IPS signatures).

East-west traffic refers to service-to-service traffic within a network (lateral movement), as opposed to north-south traffic (ingress from external users). Traditional network security focused almost exclusively on north-south (perimeter) traffic and did not inspect east-west traffic at all — allowing attackers who gained a foothold inside to move freely. Modern architectures address east-west through microsegmentation (Zero Trust network policies), service mesh mTLS, and in some cases, an internal NGFW or network inspection layer that all inter-service traffic passes through. AWS PrivateLink and equivalent cloud services allow applications to consume third-party or partner APIs over private network paths without traffic traversing the public internet, reducing the external attack surface.

Why it exists

Network-based attacks — DDoS, SQL injection via HTTP, lateral movement — are among the most common attack vectors. Network security controls provide defence in depth at a layer below the application, so that application-layer vulnerabilities can be mitigated partially or detected by network-layer controls. A WAF can block a SQL injection attempt even if the application code contains the vulnerability, buying time for a code fix. A properly segmented VPC means an attacker who compromises a web tier server cannot directly reach the database tier without passing through an additional security group boundary. Network monitoring (VPC Flow Logs, network IDS) provides visibility into anomalous traffic patterns that application logs may miss.

When to use

  • All production cloud deployments — proper VPC segmentation and security groups are baseline requirements, not optional.
  • Public-facing web applications — WAF with OWASP Core Rule Set is standard practice.
  • Environments processing sensitive data — PrivateLink for cloud service access, private subnets for data stores.
  • Regulated environments (PCI DSS, HIPAA) — explicit network segmentation requirements with audit evidence.
  • Zero Trust adoption — east-west inspection is required to control lateral movement in a Zero Trust model.

When not to use

  • WAF as only application security control: WAFs have false positive and bypass risks; they supplement but do not replace application-layer input validation and parameterised queries.
  • IDS/IPS over encrypted traffic without TLS inspection: Network IDS cannot inspect encrypted payloads; TLS inspection (which has its own privacy implications) is required for deep packet inspection of HTTPS traffic.

Typical architecture

VPC NETWORK ARCHITECTURE (three-tier):

  Internet
     │
  [CloudFront CDN / DDoS protection]
     │
  [WAF — OWASP rules, rate limiting]
     │
  Public Subnet (AZ-a, AZ-b):
  [Application Load Balancer]
     │ HTTPS only (security group: 443 inbound)
  Private Subnet (App):
  [App Servers / ECS Tasks]
  SG: inbound 8080 from ALB SG only
      egress: 5432 to DB SG, 443 to internet (via NAT GW)
     │
  Private Subnet (Data):
  [RDS PostgreSQL / ElastiCache]
  SG: inbound 5432 from App SG only
      egress: none
     │
  [NAT Gateway in public subnet — for outbound only]

SECURITY GROUPS vs NACLs:
  Security Groups:
  - Stateful (return traffic auto-allowed)
  - Applied to instances/ENIs
  - Allow rules only (implicit deny)
  - Reference other SGs ("allow from ALB-SG")
  - PRIMARY control — use for all ingress/egress

  NACLs:
  - Stateless (must allow return traffic explicitly)
  - Applied to subnets
  - Allow + deny rules, numbered priority
  - Use for: explicit subnet-level deny rules,
             blocking specific IP ranges (abuse)

EAST-WEST INSPECTION:
  AWS Network Firewall in inspection VPC:
  VPC A → Transit Gateway → Inspection VPC
                             (NGFW + IDS/IPS rules)
                          → Transit Gateway → VPC B

ZTNA (Zero Trust Network Access):
  No VPN; employees connect to Cloudflare Access
  or Zscaler Private Access; identity + device
  posture verified before proxying to internal app

Pros and cons

Pros

  • VPC segmentation limits blast radius: a compromised web tier cannot directly access database tier without passing additional security controls.
  • WAF provides automated protection against common web attacks (SQLi, XSS, SSRF) even when application code contains vulnerabilities.
  • Security groups with inter-group references (allow from ALB-SG) are more secure and maintainable than IP-based rules that become stale.
  • PrivateLink eliminates public internet egress for cloud service calls, reducing data exfiltration risk and compliance scope.
  • VPC Flow Logs and NGFW logs provide network-level visibility for threat detection even when application logs are insufficient.

Cons

  • WAF false positives can block legitimate traffic; tuning WAF rules requires ongoing operational effort.
  • East-west inspection via central NGFW adds latency and creates a potential bottleneck if not properly scaled.
  • Security group sprawl: large environments with hundreds of security groups become difficult to audit without automation.
  • PrivateLink endpoints have cost implications and add endpoint management overhead.

Implementation notes

Design security groups with the principle of least privilege: each security group should allow only the specific protocol and port required from a specific source (another security group, not a CIDR). Never use 0.0.0.0/0 as an ingress source except for public-facing load balancers accepting internet traffic on port 443. Enable VPC Flow Logs to S3 or CloudWatch for all production VPCs — they are essential for incident investigation and anomaly detection. For WAF deployment, start with AWS WAF Managed Rules (OWASP Core Rule Set) in count mode, monitor false positive rate for 1–2 weeks, then switch to block mode. Use WAF rate-based rules to automatically block IP addresses making more than a defined threshold of requests per 5-minute period.

For microsegmentation in Kubernetes, use Kubernetes NetworkPolicies (with a CNI plugin that enforces them — Calico, Cilium, or Antrea) to restrict pod-to-pod communication to the minimum required. The default allow-all policy in Kubernetes means any pod can communicate with any other pod; NetworkPolicies are deny-by-default once applied to a namespace. Define both ingress and egress NetworkPolicies for all production workloads. Cilium with eBPF-based enforcement provides Layer 7 aware policies (e.g., allow HTTP GET /api only) beyond the Layer 3/4 NetworkPolicy standard.

Common failure modes

  • Database in public subnet: RDS or similar databases placed in a public subnet with a security group restricting access — security group misconfiguration or removal exposes the database to the internet. Always place databases in private subnets with no internet gateway route.
  • 0.0.0.0/0 SSH/RDP in security groups: Allowing SSH or RDP from any IP is one of the most commonly misconfigured settings in cloud environments and one of the most scanned by attackers.
  • WAF in count-only mode permanently: WAFs left in count mode provide visibility but no protection; teams enable count mode for testing and forget to switch to block mode.
  • No egress filtering: Security groups that restrict inbound traffic but allow all outbound traffic enable data exfiltration and C2 communication from compromised instances.
  • Overlapping NACL deny/allow rules: NACL rules are processed in numbered order; an allow rule with a lower number than a deny rule for the same traffic causes the deny to be ineffective.

Decision checklist

  • Are databases and application servers in private subnets with no direct internet gateway route?
  • Do security groups use inter-group references rather than CIDR-based rules for internal traffic?
  • Is a WAF deployed in front of all public-facing web applications in block mode?
  • Are VPC Flow Logs enabled and shipped to a centralised log store?
  • Is east-west traffic inspected for lateral movement, either via NGFW or service mesh mTLS?
  • Are Kubernetes NetworkPolicies enforced with a deny-by-default posture?

Example use cases

  • Multi-tier web application: Public ALB → private app tier (SG allows 443 from ALB-SG) → private data tier (SG allows 5432 from app-SG only). Databases unreachable from the internet by design.
  • SaaS platform DDoS protection: Cloudflare in front of origin; AWS WAF on ALB with rate limiting; AWS Shield Advanced for volumetric DDoS. CloudFront CDN absorbs the majority of traffic before it reaches origin infrastructure.
  • Kubernetes zero-trust networking: Cilium NetworkPolicies with L7 enforcement; the payment service can receive only HTTP POST /charge from the order service; all other sources are denied at network layer.

Further reading