Securing Inter-VPC Traffic: Multi-Account & Intra-Account Strategies

This guide explores the mechanisms for securing traffic between Virtual Private Clouds (VPCs), whether they reside within a single AWS account or across multiple accounts in an organization.

Learning Objectives

After studying this guide, you will be able to:

• Differentiate between stateless and stateful traffic filtering in inter-VPC communication.
• Implement security measures for VPC Peering, Transit Gateway, and PrivateLink.
• Configure VPC Endpoint Policies to restrict access to specific AWS resources.
• Design a layered security architecture that combines network-level and application-level controls.

Key Terms & Glossary

• Security Group (SG): A stateful virtual firewall for EC2 instances that controls inbound and outbound traffic at the ENI level.
• Network Access Control List (NACL): A stateless layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets.
• VPC Endpoint Policy: An IAM resource policy attached to a VPC endpoint to control which principals can use the endpoint to access which resources.
• Transit Gateway (TGW): A network transit hub used to interconnect VPCs and on-premises networks.
• AWS PrivateLink: Technology that provides private connectivity between VPCs, AWS services, and on-premises networks without exposing traffic to the public internet.

The "Big Idea"

Securing inter-VPC traffic is not a "one-size-fits-all" task. It requires Defense in Depth. While VPC Peering and Transit Gateways provide the connectivity, the security is enforced by layering stateless filters (NACLs), stateful filters (Security Groups), and identity-based policies (Endpoint Policies). The goal is to ensure that even if one layer is bypassed, the internal network remains protected.

Formula / Concept Box

Hierarchical Outline

• Network-Level Security (Infrastructure)
  • Security Groups: Filtering at the resource level; support for referencing SGs in peered VPCs (within the same region).
  • Network ACLs: Subnet-level protection; useful for blocking specific IP ranges (CIDRs) across inter-VPC links.
• Inter-Connectivity Security
  • VPC Peering: Private routing between two VPCs; requires updated route tables and SG rules.
  • Transit Gateway (TGW): Centralized hub; security is managed via TGW Route Tables and associated SG/NACLs at the VPC attachments.
• Application-Level Security (Data Perimeter)
  • VPC Endpoints: Interface and Gateway types.
  • Endpoint Policies: Restricting access to specific S3 buckets or DynamoDB tables, even if the user has broad IAM permissions.

Visual Anchors

Choosing the Right Connectivity Security

Layered Security Diagram

This diagram visualizes how traffic must pass through multiple filters when moving from VPC A to VPC B.

\begin{tikzpicture}[node distance=2cm, every node/.style={draw, rectangle, align=center, minimum height=1cm}] \node (VPC_A) [fill=blue!10] {VPC A\Source Instance}; \node (SG_A) [right of=VPC_A, xshift=1.5cm, fill=orange!20] {Security Group$Outbound)}; \node (NACL_A) [right of=SG_A, xshift=1.5cm, fill=red!20] {NACL$Egress)}; \node (TGW) [right of=NACL_A, xshift=1.5cm, fill=gray!20, rounded corners] {Transit Gateway /\VPC Peering}; \node (NACL_B) [right of=TGW, xshift=1.5cm, fill=red!20] {NACL$Ingress)}; \node (SG_B) [right of=NACL_B, xshift=1.5cm, fill=orange!20] {Security Group$Inbound)}; \node (VPC_B) [right of=SG_B, xshift=1.5cm, fill=green!10] {VPC B\Target Instance};

\end{tikzpicture}

Definition-Example Pairs

• Term: Stateless Firewall (NACL)
  • Definition: A firewall that treats each packet as an individual unit, requiring separate rules for request and response traffic.
  • Example: If you allow inbound traffic on port 80 in a NACL, you must also allow outbound traffic on ephemeral ports (1024-65535) for the response to reach the client.
• Term: VPC Endpoint Policy
  • Definition: An IAM-style policy attached to a VPC Endpoint that acts as a guardrail for what actions are permitted through that specific pipe.
  • Example: An S3 Endpoint Policy that allows s3:PutObject only to a specific corporate bucket, preventing data exfiltration to a personal S3 bucket.

Worked Examples

Example 1: Multi-Account S3 Access via PrivateLink

Scenario: A company has a "Production" account and a "Logging" account. VPC A (Production) needs to upload logs to an S3 bucket in the Logging account without using the public internet.

1. Connectivity: Create a Gateway VPC Endpoint for S3 in VPC A.
2. Security (Bucket Policy): Update the S3 bucket policy in the Logging account to only allow traffic from the VPC Endpoint ID of VPC A.
3. Security (Endpoint Policy): Attach a policy to the VPC Endpoint in VPC A:
   jsonCopy

   { "Statement": [{ "Effect": "Allow", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::corporate-logs-bucket/*" }] }
4. Result: Even if an instance in VPC A is compromised, it cannot send data to any S3 bucket other than the one specified.

Checkpoint Questions

1. True or False: If a Security Group allows inbound traffic, the return outbound traffic is automatically allowed.
2. In a multi-account setup using Transit Gateway, where do you apply the route tables to control which VPCs can talk to each other?
3. What is the primary difference between a Security Group and a VPC Endpoint Policy?

[!NOTE] Answers:

1. True (Security Groups are stateful).
2. At the Transit Gateway level (TGW Route Tables).
3. SGs filter by IP/Port/Protocol (Network Layer); Endpoint Policies filter by IAM Principal/Action/Resource (Application Layer).

Muddy Points & Cross-Refs

• Referencing Security Groups: You can reference a Security Group ID from a peered VPC as a source/destination, but this only works if the VPCs are in the same Region. For cross-region or Transit Gateway connections, you must use CIDR blocks (IP ranges).
• NACL vs. SG Priority: A packet must pass through the NACL and the Security Group. If the NACL denies the packet, it never reaches the Security Group.

Comparison Tables

Inter-VPC Connectivity Security Features