We had built the CloudTrail query runbook to comb through events at scale, then found ourselves staring at a wall inside a VPC private subnet. No internet egress. No direct AWS API reach. Every path forward meant threading requests through a proxy we didn’t want to manage, but had to deploy with surgical precision.
Deploying a proxy in a VPC private subnet is not just spinning up an instance. It’s about designing a path for controlled, auditable queries from your CloudTrail logs without breaking the isolation your network enforces. The runbook becomes the bridge.
First, define the scope. Private subnets mean no inbound traffic from the internet by default. To run CloudTrail queries in this model, a proxy deployment in the subnet must route authorized traffic to AWS endpoints. Use an autoscaling group or container orchestration if high availability is mandatory. Strip everything unnecessary. Load balancer optional, NAT gateway avoidable if you lock this to a single-purpose proxy tunnel.
Second, provision the proxy near your CloudTrail data sources, ideally in the same region and AZ to cut latency. Use minimal AMIs hardened for security. Bake IAM roles with custom policies granting read-only access to the CloudTrail bucket or CloudWatch Logs Insights as needed. Bind security groups to allow only whitelisted internal traffic paths.