VPC, Private Subnets, and Service Connectivity

How Guard workloads run in a private VPC with controlled egress and interface endpoints.

Overview

Guard’s AWS deployment provisions a dedicated VPC with public and private subnets, security groups, and NAT-based outbound connectivity for private workloads. This design keeps sensitive compute off the public internet while still allowing controlled access to AWS APIs and other services.

Network layout (high level)

  • VPC CIDR: The stack defines a single VPC (for example 10.1.0.0/16 in the default template) with DNS support and hostnames enabled.

  • Public subnets: Used for internet-facing components such as the internet gateway attachment, NAT gateway placement, and related routing.

  • Private subnets: Non-public address space (for example 10.1.96.0/19 and 10.1.128.0/19 in the default template) with no automatic public IP assignment on launch. Application compute that should not be directly reachable from the internet is placed here.

Routing is split so private subnets send 0.0.0.0/0 via the NAT gateway, while public subnets use the internet gateway where public ingress or egress is required.

Lambda and VPC attachment

AWS Lambda functions use a global VPC configuration in the serverless template: by default they attach to the private subnets and a dedicated Lambda security group. This means routine API and worker logic executes inside the private network context rather than on unscoped public addresses.

Lambda execution roles include VPC access permissions where functions are VPC-attached, consistent with AWS requirements for ENI-based connectivity.

Security groups

Dedicated security groups are defined for Lambda, VPC endpoints, databases, and other tiered resources. Egress is generally permissive for operational connectivity from private tiers, while ingress is scoped to the VPC and required peers (for example database clients from Lambda security groups only).

VPC endpoints (private AWS API access)

The stack defines Gateway and Interface VPC endpoints so traffic to selected AWS services can stay on the AWS network instead of traversing the public internet. Examples present in the template include endpoints for DynamoDB (gateway), S3 (gateway), and interface endpoints for services such as SQS, CloudWatch Logs, Lambda, Kinesis, and Bedrock Runtime, each associated with the private subnets and endpoint security groups.

Together with NAT for general egress, this yields defense in depth: private compute, constrained security group surfaces, and private connectivity to major platform dependencies.