DNS Isolation on AWS

DNS isolation on AWS refers to designing your Amazon Web Services environment so that certain workloads or networks can only resolve DNS names you explicitly allow, while blocking or segregating access to all other DNS sources—internal or external.

It is often used for security-sensitive, regulated, or multi-tenant architectures where you want to strictly control what resources can discover each other via DNS.

What DNS Isolation Means

DNS isolation ensures that a workload or subnet does not automatically inherit DNS visibility from the broader VPC or the internet. Instead, you tightly control where it gets DNS answers from (e.g., Route 53 Resolver rules, inbound/outbound resolvers, private hosted zones).

• Isolates DNS Resolution Paths: Prevents workloads from resolving public DNS names or internal/private AWS names not intended for them.
• Controls Resource Discovery: Restricts which internal services can be discovered by name.
• Prevents Data Exfiltration via DNS: Cuts off malware from using DNS to exfiltrate data.

How to Implement DNS Isolation in AWS

1. Disable the Default VPC Resolver

At the subnet level, set enableDnsSupport = false or override DNS servers via DHCP option sets to force workloads to use only your DNS servers.

2. Use Custom DNS Servers or Route 53 Resolver Endpoints

Point instances/subnets to custom DNS appliances or Route 53 outbound resolver endpoints with controlled forwarding rules.

3. Use Route 53 Resolver Rules for Fine-Grained Control

Define conditional forwarding rules, e.g.:

• corp.local → internal DNS server
• serviceA.internal → specific resolver
• Block everything else

4. Private Hosted Zones (PHZs) for Segregation

Attach PHZs only to specific VPCs to achieve multi-tenant DNS isolation and environment separation (dev vs prod).

5. Use Security Groups or Route 53 Resolver DNS Firewall

Create DNS firewall rule groups to:

• Allow only approved domains
• Block malware/TLDs
• Prevent access to external DNS servers

Common Use Cases for DNS Isolation

• Zero-Trust Network Design: Only authorized services resolve each other.
• Regulated Workloads: Ensures workloads resolve only internal names (HIPAA, FedRAMP, PCI).
• Multi-Tenant SaaS Platforms: Each tenant/VPC uses separate PHZs and resolver rules.
• Highly-Sensitive Internal Apps: Prevents accidental communication.
• Preventing Data Exfiltration: Blocks DNS tunneling by design.

Example Architecture for Isolated DNS

VPC (DNS Support Disabled)
   |
   +-- DHCP Option Set: DNS = Custom DNS Servers
   |
   +-- Route 53 Outbound Resolver Endpoint
           |
           |-- RULE: *.corp.local → Internal Data Center DNS
           |-- RULE: *.aws.local → AmazonProvidedDNS (private endpoints only)
           |-- RULE: BLOCK everything else

Workloads in this VPC cannot resolve public DNS, cannot query VPC private DNS unless allowed, and cannot access external resolvers.

The post DNS Isolation on AWS appeared first on AWS Security Architect.

1. Only AWS Security Hub can directly inherit & enforce Org-level guardrails. Deep Native Integration With AWS Control APIs (Preventive + Detective Controls)

Security Hub isn’t just reading posture — it is tightly wired into:

• AWS Organizations / Control Tower

• AWS Config and Config Conformance Packs

• IAM Access Analyzer

• GuardDuty

• Macie

• Inspector

• CloudTrail

• Network Firewall

• RDS Enhanced Monitoring

• Route 53 Resolver DNS Firewall

Wiz can ingest some of this data after it is generated,
but cannot natively participate in enforcement or orchestration because only AWS can modify guardrails at the organization level.

Only AWS Security Hub can directly inherit & enforce Org-level guardrails.

2. Automatic, Native Remediation via SSM Automation Documents

Security Hub integrates natively with:

• AWS Systems Manager Automation

• Pre-built remediation playbooks (SSM documents)

  • e.g., “Enable S3 block-public-access”,

  • “Rotate IAM access keys”,

  • “Encrypt EBS volumes”,

  • “Enable CloudTrail globally”.

Wiz can create tickets, alerts, or send webhook actions —
but it cannot directly run AWS-managed remediation automation.

AWS provides out-of-the-box remediation actions Wiz cannot trigger or manage natively.

3. Organization-Wide Mandatory Controls (FSBP, CIS Benchmarks)

Security Hub offers AWS Foundational Security Best Practices — tuned specifically to AWS internals, such as:

• Ensuring CloudTrail multi-region logging

• Ensuring GuardDuty is enabled in all regions

• Ensuring EBS encryption-by-default

• Ensuring VPC Flow Logs coverage

• Ensuring S3 public access block (account-level)

Wiz can check configurations, but cannot enforce AWS-level mandatory controls such as:

• Forced CloudTrail global

• Forced GuardDuty onboarding

• Automatic region enrollment

• Policy inheritance via Organizations

AWS-native CSPM can enforce security at the root account / org level, Wiz cannot.

4. Guaranteed Data Freshness from AWS APIs (Zero Lag)

AWS-native CSPM tools pull data directly from AWS control-plane APIs with:

• zero throttling issues

• full permission coverage

• immediate state awareness

Wiz relies on:

• periodic scans

• configuration snapshots

• ingestion delays

Security Hub always has the canonical truth from AWS itself.

5. Fully Managed Multi-Account Aggregation Through AWS Organizations

Security Hub can:

• auto-enable itself on new AWS accounts

• apply controls org-wide via delegated admin

• manage cross-account aggregation without custom roles

• ensure region-by-region mandatory configuration

Wiz requires:

• manually setting up IAM roles

• cross-account connectors

• agentless scanning permissions

• manual policy propagation

AWS CSPM has zero maintenance overhead for new accounts and new regions.

Summary: When AWS CSPM Outperforms Wiz

Security Hub is stronger when you need:

Org-level governance
Guaranteed integration correctness
AWS-managed remediations
Compliance-heavy requirements
Zero external dependencies
Cost + security combined governance
Deep AWS internal telemetry

Wiz is stronger when you want:

Attack path analysis
Cloud-graph visualization
Multi-cloud posture
Unified risk context (identity + vuln + config)

The post AWS Security Hub versus Wiz on AWS appeared first on AWS Security Architect.

Shared VPC Host (Public & Private Subnets) + TGW + Security VPC (GWLB); Participant Accounts place ENIs in Shared Subnets

Overview

This architecture uses a Shared VPC model where a central Host Account owns and manages a VPC containing both
Public and Private subnets. Multiple Participant Accounts launch their workloads
(ENIs, EC2 instances, ECS tasks, etc.) directly into these subnets. All inter-VPC and north-south traffic is routed through a
Transit Gateway (TGW) and inspected by a centralized Security VPC hosting
Gateway Load Balancer (GWLB) firewalls.

Key Components

1. Shared VPC Host Account

• Owns the Shared VPC — including subnets, route tables, and TGW attachments.
• Contains:
  • Public Subnets (connected to an Internet Gateway):
    • Host Internet-facing components such as ALBs, NAT Gateways, or public EC2 instances.
    • Default route 0.0.0.0/0 → IGW.
  • Private Subnets (non-Internet-facing):
    • Host backend workloads or participant ENIs.
    • Routes for internal CIDRs (e.g., 10.0.0.0/8) point to the TGW attachment.
• Transit Gateway Attachment:
  • Connects the Shared VPC to the TGW for both east-west and north-south routing.
  • TGW route table determines if traffic is inspected or forwarded to other VPCs.

2. Security Account and Security VPC

• A dedicated account owned by the security team.
• Contains the Gateway Load Balancer (GWLB) and firewall appliances
  (e.g., Palo Alto, FortiGate, Check Point, or Suricata).
• Security VPC details:
  • Subnets per AZ connected to GWLB target groups.
  • TGW attachment with Appliance Mode enabled to maintain flow symmetry.
• GWLB endpoints are used by the Shared VPC’s private route tables to forward traffic for inspection.

3. Transit Gateway (TGW)

• Acts as the central routing fabric connecting:
  • The Shared VPC (Host Account)
  • The Security VPC (Security Account)
  • Any additional application or support VPCs in other accounts
• TGW Route Tables configured for traffic steering:
  • Routes between participant workloads go through the Security VPC for inspection.
  • North-south (Internet-bound) traffic also passes through the Security VPC before reaching the IGW.
  • Blackhole routes prevent direct bypass of inspection.

4. Participant Accounts

• Do not own a VPC; workloads are deployed into exported subnets of the Shared VPC.
• Each participant’s ENIs appear within the Shared VPC’s subnets.
• Participants rely on the Host Account for:
  • Subnet routing configuration
  • Security group and NACL enforcement
  • TGW connectivity and inspection routing

Traffic Flow Scenarios

North–South (Internet Ingress/Egress)

1. Internet traffic enters via the IGW in the Shared VPC’s Public Subnets.
2. Traffic passes through ALB/firewall endpoints and then through the GWLB in the Security VPC for inspection.
3. Allowed traffic is routed via TGW to workloads in private subnets (participant ENIs).
4. Outbound follows the reverse path — Private → TGW → GWLB → IGW.

East–West (Inter-VPC / Internal Traffic)

1. Workload in Shared VPC initiates traffic to another internal VPC.
2. Traffic routes Shared VPC → TGW → Security VPC (inspection) → TGW → destination VPC.
3. All inter-VPC traffic is centrally monitored and inspected.

Operational Benefits

• Centralized governance: Host Account owns routing and TGW attachments ensuring policy consistency.
• Least privilege & separation of duties:
  • Security Account manages firewalls and policies.
  • Host Account manages network infrastructure.
  • Participant Accounts manage only their workloads.
• Scalable & multi-account compliant: Works under AWS Organizations + RAM.
• Reduced operational duplication: One shared IGW/NAT/firewall layer for all accounts.
• Inspection assurance: All traffic (north-south and east-west) passes through GWLB via TGW routing.

Design Best Practices

• Enable Appliance Mode on the Security VPC TGW attachment for stateful symmetry.
• Use dedicated TGW route tables for inspected vs. trusted paths.
• Export both Public and Private subnets to participant accounts for flexible placement.
• Use AWS Firewall Manager or SCPs to enforce inspection and prevent direct IGW use by participants.
• Enable VPC Flow Logs and TGW Flow Logs for audit visibility.

The post Replace DMZ with Shared VPC in AWS appeared first on AWS Security Architect.

AWS Shared VPC Architecture – Segmentation by Ingress Type

In an AWS Shared VPC architecture, the host account owns and manages the VPC, subnets, and routing.
It shares specific subnets with participant accounts through AWS Resource Access Manager (RAM).
This allows each participant account to deploy workloads into shared subnets — without owning or modifying the core VPC networking.

1. Segmentation Models

A. Environment-Based

Each participant account represents an environment (e.g., Dev, Test, Prod).
Subnets within the shared VPC are labeled and shared accordingly:

• Dev Account: dev-public-*, dev-private-* subnets
• Test Account: test-public-*, test-private-* subnets
• Prod Account: prod-public-*, prod-private-*, prod-isolated-* subnets

This keeps environments isolated while maintaining consistent security and routing through a single centrally managed VPC.

B. Workload-Based (by Ingress Profile)

Alternatively, participant accounts may represent workload ingress types:

• Edge / Public Ingress Account: Internet-facing workloads using ALB/NLB, CloudFront origins.
• Private Services Account: Application workloads reachable only through internal ALBs, VPC Lattice, or PrivateLink.
• Data or Regulated Account: Isolated workloads (RDS, MSK, S3 endpoints) accessible only through endpoints or service meshes.

2. Ingress Flow Diagram

          +----------------------+
          |      Internet        |
          +----------+-----------+
                     |
                     v
         +-----------+-----------+
         |  Edge (Public Ingress)|
         |  Account – ALB/NLB    |
         +-----------+-----------+
                     |
                     v
         +-----------+-----------+
         |  Private App Services |
         |  Account – ECS/EKS    |
         +-----------+-----------+
                     |
                     v
         +-----------+-----------+
         |   Data/Isolated Tier  |
         |   Account – RDS, EFS  |
         +-----------------------+

Each tier runs in its own participant account using subnets shared from the host VPC.
Traffic flows from public ALBs → internal services → data layers, all within controlled ingress boundaries.

3. Governance and Control Layers

• Subnet Sharing: Host account shares only the appropriate subnets (public/private/isolated) with each participant account.
• Routing: Host account manages route tables (e.g., IGW routes only for public subnets, NAT or GWLB for private).
• Security Groups: Participant accounts define SGs for their resources; AWS Firewall Manager can enforce org-wide SG policies.
• Network Firewall: Centralized inspection via AWS Network Firewall or GWLB in the host account.
• SCPs & Config: Prevent public resources in private-only accounts; ensure compliance via Config/FMS rules.

4. Example Mapping Table

5. Key Enforcement Mechanisms

• Use AWS Firewall Manager to enforce org-wide SG and NFW policies.
• Apply Service Control Policies (SCPs) to block creation of public ALBs or IGWs in private-only accounts.
• Implement Config Rules for continuous compliance (public IP detection, restricted-ssh).
• Tag subnets and accounts with Environment and IngressType for automation and visibility.

The post DMZs versus Shared VPCs appeared first on AWS Security Architect.

Shared VPC Use Cases & Shared VPC vs Transit Gateway

This document provides additional Shared VPC use cases for AWS Network Firewall and explains how Shared VPCs differ technically and operationally from AWS Transit Gateways (TGWs).

Network Firewall Policies — Shared VPC Support

When AWS Network Firewall is deployed through Firewall Manager in a Shared VPC environment, it provides consistent network-layer inspection across workloads owned by multiple AWS accounts but hosted in a single VPC owned by the networking (host) account.

How Shared VPCs Differ from Transit Gateways

While both Shared VPCs and Transit Gateways enable multi-account connectivity, they operate at different scopes and layers of the network.

Tip: Pair Firewall Manager policies (Network Firewall, Security Group, WAF, DNS Firewall) with centralized logging to S3 or CloudWatch and integrate with AWS Security Hub or GuardDuty for organization-wide visibility and automated compliance.

The post Firewall Manager and Shared VPCs in AWS appeared first on AWS Security Architect.

aws ec2 authorize-security-group-ingress \
  --group-id sg- \
  --source-group sg-

The post AWS Shared VPC vs. Transit Gateways appeared first on AWS Security Architect.

Transit Gateway vs API Gateway — and a Reference Architecture with NGINX

Key Differences

Architecture Diagram

External APIs: Internet → WAF → API Gateway → (private integration via VPC Link) → ALB/NLB → NGINX → services.
Internal APIs: Internal clients → Corp Edge → Transit Gateway → (Internal VPC) → NGINX (internal) → services.

Security Policies

1) API Gateway (External)

• Edge protections: WAF (OWASP, bot control, geo/IP blocks).
• Auth: JWT (Cognito/OIDC), IAM SigV4, or Lambda authorizers.
• Resource policies: Restrict by VPC Endpoint/CloudFront Distribution.
• Threat controls: Throttling, quotas, usage plans, API keys.
• Data protection: TLS 1.2+, request/response validation, payload limits, sensitive header redaction.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "execute-api:Invoke",
    "Resource": "arn:aws:execute-api:us-east-1:123456789012:abcde12345/*/*/*",
    "Condition": {
      "StringNotEquals": {
        "aws:SourceVpce": "vpce-0abc123def4567890",
        "aws:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E123ABC456DEF"
      }
    }
  }]
}

2) NGINX (Reverse Proxy)

• Transport: Enforce TLS; mTLS for service-to-service.
• Identity: Validate JWT (OIDC) or client certs.
• Access control: Path/host routing, IP allow/deny for admin paths, tenant scoping.
• Rate limiting: Per IP/token; connection/request limits.
• Hygiene: Header normalization, body size caps, method allowlists.
• Observability: Structured logs, correlation IDs.

# mTLS
ssl_verify_client on;
ssl_client_certificate /etc/nginx/ca_bundle.pem;

# JWT validation (auth_jwt or OpenResty)
auth_jwt "closed api";
auth_jwt_key_file /etc/nginx/jwks.pem;

# Rate limiting
limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
server {
  listen 443 ssl http2;
  server_name api.example.com;

  limit_req zone=api burst=40 nodelay;
  client_max_body_size 5m;

  location /service-a/ {
    proxy_set_header Authorization $http_authorization;
    proxy_pass http://svc-a:8080;
  }
}

3) Transit Gateway (L3)

• Segmentation: Separate TGW route tables per environment/domain.
• Least-route: Propagate/associate only where needed; deny east‑west by default.
• Inspection: Force inter‑VPC traffic via an inspection VPC/NVA firewall.
• Adjacencies: Complement with Security Groups/NACLs; use VPC endpoints for private API consumption.
• Observability: TGW + VPC Flow Logs for anomalous inter‑VPC flows.

Layered Security Summary

1. Edge: WAF + API Gateway throttling/authorizers.
2. VPC: NGINX enforces mTLS/JWT, routing, rate limits.
3. Network Hub: Transit Gateway confines routes, funnels inspection.
4. Workloads: SG/NACL and app‑level authorization/validation.

The post API Gateway versus Transit Gateway appeared first on AWS Security Architect.

Potential Benefits (Why People Do This)

• Cloudflare: DDoS protection, WAF, CDN, TLS offload, bot protection — global edge network.
• Palo Alto VM-Series: Layer 4-7 inspection, IPS/IDS, app-level policies, advanced logging, east-west traffic inspection within VPCs, integration with enterprise tooling.

Potential Downsides

1⃣ Latency and Performance

• Cloudflare terminates TLS at edge, then re-encrypts to origin (your AWS app).
• Introducing Palo Alto in-line can add latency and path complexity.
• Improper design can cause hairpinning (traffic looping between VPCs/interfaces).

2⃣ Cost Overhead

• Palo Alto VM-Series is costly — licensing, compute, bandwidth.
• Running both Cloudflare and Palo Alto may duplicate features and increase total cost.

3⃣ Operational Complexity

• Two security stacks mean two dashboards, two logging systems, two policy engines.
• Increased burden on security and operations teams.
• Clear ownership boundaries required (who manages Cloudflare vs Palo Alto?).

4⃣ Debugging Complexity

• Failures may require debugging across multiple layers:
  • Cloudflare edge rules
  • Cloudflare WAF
  • Palo Alto firewall policies
  • AWS NACLs, Security Groups, ALB settings

5⃣ TLS / Encryption Conflicts

• Careful design needed for TLS termination:
  • Cloudflare terminates TLS, then Palo Alto inspects plaintext? (often not desirable)
  • Cloudflare passes through TLS, Palo Alto inspects encrypted traffic (requires decryption licenses and proper configuration).
• Improper handling can break mTLS or other sensitive integrations.

6⃣ Overlap in Features

• Cloudflare Advanced WAF is powerful.
• Palo Alto WAF/IPS may introduce redundant protection.
• Requires careful coordination to avoid double blocking and false positives.

7⃣ Routing & Asymmetry

• Improper architecture can cause asymmetric routing:
  • Inbound path through Cloudflare & Palo Alto.
  • Outbound path bypasses Palo Alto.
• This can break stateful firewalling and cause unpredictable behavior.

Summary — When It Makes Sense vs Not

Recommendation: Simple Public Web Apps

For simple public web applications — marketing sites, basic informational apps, low-sensitivity data — Cloudflare alone typically provides sufficient protection:

• Global DDoS protection
• Advanced WAF and bot management
• Global CDN and TLS termination
• Minimal operational overhead

Adding Palo Alto in such scenarios may introduce unnecessary cost and complexity.

Recommendation: Complex High-Traffic eCommerce Web Apps

For high-traffic eCommerce applications with sensitive data (PII, PCI), compliance needs, and fraud prevention requirements:

• Use Cloudflare for edge security (DDoS, TLS, global CDN, bot mitigation).
• Use Palo Alto VM-Series for:
  • Deep application inspection
  • Advanced IPS/IDS
  • East-West traffic security between microservices
  • Detailed logging and forensic analysis

For best performance, ensure traffic paths and TLS flows are carefully designed to avoid latency spikes and asymmetric routing.

Final Advice

• Carefully design traffic path and TLS termination points.
• Define clear responsibility boundaries between Cloudflare and Palo Alto management.
• Monitor latency and debug complexity continuously.
• Justify the cost of dual stack vs using either one effectively.

The post Using Cloudflare and Palo Alto Together on AWS: Pros and Cons appeared first on AWS Security Architect.

Yes, a DMZ (Demilitarized Zone) in the cloud can include both a public subnet and a private subnet. This configuration helps to separate internet-facing resources from internal application layers that require added security.

DMZ Subnet Responsibilities

• Public Subnet: Load balancers, web servers, bastion hosts. Directly accessible from the internet.
• Private Subnet: Backend services like APIs, internal app servers, or firewalls. No direct internet access.

Traffic Flow

1. User sends request to public IP on the DMZ Public Subnet (e.g., via a Load Balancer).
2. Load Balancer forwards request to app servers in the DMZ Private Subnet.
3. App servers in the DMZ Private Subnet may access internal services in the Internal VPC.

Firewall Rules

Security groups – defined at VPC level – enforced at Instance Level

1. DMZ Public Subnet → DMZ Private Subnet

2. DMZ Private Subnet → Internal VPC

Optional: NACL Rules

DMZ Private Subnet NACL

Internal VPC Subnet NACL

The post AWS DMZ Public and Private Subnets, Traffic to Internal VPC appeared first on AWS Security Architect.

AWS VPC Flow Logs do not use PCAP (Packet Capture) format. Instead, VPC Flow Logs capture metadata about the traffic flowing to and from network interfaces in a Virtual Private Cloud (VPC). This metadata is stored in a structured log format, typically in Amazon CloudWatch Logs or Amazon S3.

Data Captured by VPC Flow Logs

VPC Flow Logs capture information such as:

• Version: The version of the flow log format.
• Account ID: The ID of the AWS account that owns the network interface.
• Interface ID: The ID of the network interface for which traffic is recorded.
• Source Address: The source IP address of the traffic.
• Destination Address: The destination IP address of the traffic.
• Source Port: The source port of the traffic.
• Destination Port: The destination port of the traffic.
• Protocol: The IANA protocol number of the traffic (e.g., TCP is 6, UDP is 17).
• Packets: The number of packets transferred during the flow.
• Bytes: The number of bytes transferred during the flow.
• Start Time: The time at which the flow started.
• End Time: The time at which the flow ended.
• Action: Whether the traffic was accepted or rejected.
• Log Status: The status of the flow log.

Example of a VPC Flow Log Entry

Here is an example of a single VPC Flow Log entry:

Breakdown of the Example Entry

• 2: The version of the flow log format.
• 123456789012: The AWS account ID.
• eni-abc123de: The ID of the network interface.
• 192.168.1.1: The source IP address.
• 10.0.0.1: The destination IP address.
• 443: The destination port (HTTPS).
• 12345: The source port.
• 6: The protocol (TCP).
• 10: The number of packets transferred.
• 840: The number of bytes transferred.
• 1623101047: The start time of the flow (in Unix epoch time).
• 1623101107: The end time of the flow (in Unix epoch time).
• ACCEPT: The action taken (whether the traffic was accepted or rejected).
• OK: The log status (indicating the logging status).

Differences from PCAP

• Granularity: PCAP files capture the entire packet, including headers and payloads. VPC Flow Logs capture metadata about the flow, not the packet contents.
• Format: PCAP is a binary format, while VPC Flow Logs are plain text entries.
• Use Case: PCAP is used for detailed packet-level analysis, often in network troubleshooting and forensics. VPC Flow Logs are used for monitoring and analyzing network traffic patterns and security within AWS environments.

Usage of VPC Flow Logs

1. Security Monitoring: Analyze traffic patterns to detect suspicious activities or security breaches.
2. Compliance: Maintain logs for auditing and compliance requirements.
3. Performance Monitoring: Identify and troubleshoot network performance issues by examining traffic flow data.
4. Cost Management: Understand data transfer costs by analyzing traffic volume.

In summary, AWS VPC Flow Logs do not use PCAP format. Instead, they provide a high-level overview of network traffic, capturing essential metadata to help with security monitoring, compliance, performance analysis, and cost management.

The post Packet Capture and AWS VPC Flow Logs appeared first on AWS Security Architect.