Amazon VPC Lattice: Service-to-Service Auth for Coding-Agent Tool Microservices

Your coding agent is no longer one Lambda. It is a planner, a repo RAG service, a sandbox executor, a linter sidecar, and a secrets broker — often in different VPCs or accounts. Security groups and PrivateLink endpoints multiply until nobody can explain who can call what. Amazon VPC Lattice gives you a service network: register tool services, attach auth policies (IAM / SigV4), and connect clients without flattening every VPC into one flat trust domain. Use Lattice next to PrivateLink for Bedrock, Verified Permissions / Cedar, and Network Firewall egress.

⚡ TL;DR: Create a VPC Lattice service network for coding-agent-tools. Register each tool microservice (ECS/EKS/Lambda/ALB targets). Attach auth policies so only the planner role can vpc-lattice-svcs:Invoke on sensitive tools. Associate sandbox and prod VPCs deliberately. Log access; deny by default. Related: App Runner HTTP APIs, API GW + WAF, Fargate Spot sandboxes.

Why security groups stop scaling for agents

Agent tool graphs are many-to-many:

• Planner → RAG, planner → sandbox, sandbox → package mirror, linter → planner callback
• New tools appear weekly (agents invent needs)
• Tenants may need isolation at the network policy layer, not only in app code

Security group rules become a ticket queue. Lattice centralizes service identity + policy the way an internal service mesh would — with AWS IAM integration.

Lattice building blocks for tool fleets

1. Service network — the trust boundary (coding-agent-tools-prod)
2. Services — each tool (rag-search, sandbox-exec, lint-runner)
3. Target groups — IP/Lambda/ALB backends
4. Auth policies — IAM policy documents on the service or network
5. VPC associations — which VPCs can resolve/invoke

# ✅ create service network + auth-required default
aws vpc-lattice create-service-network \
  --name coding-agent-tools-prod \
  --auth-type AWS_IAM \
  --tags key=workload,value=coding-agent

# ✅ register a tool service and attach to the network
aws vpc-lattice create-service --name sandbox-exec --auth-type AWS_IAM
aws vpc-lattice create-service-network-service-association \
  --service-network-identifier sn-xxxx \
  --service-identifier svc-yyyy

❌ Associating the entire corporate VPC “for convenience” — sandboxes should join a dedicated association with tighter policies.

Auth policies: planner can invoke, tools cannot freestyle

Lattice auth policies look like IAM resource policies on the service.

// ✅ sandbox-exec service policy: only planner task role may invoke
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PlannerOnly",
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::111122223333:role/coding-agent-planner-prod"
    },
    "Action": "vpc-lattice-svcs:Invoke",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "vpc-lattice-svcs:RequestHeader/x-tenant-id": "${aws:PrincipalTag/tenant_id}"
      }
    }
  }]
}

# ✅ client call with SigV4 to Lattice-generated service DNS
import boto3
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest
import requests, os

def invoke_tool(service_dns: str, path: str, body: bytes, tenant_id: str):
    url = f"https://{service_dns}{path}"
    headers = {"Content-Type": "application/json", "x-tenant-id": tenant_id}
    request = AWSRequest(method="POST", url=url, data=body, headers=headers)
    SigV4Auth(boto3.Session().get_credentials(), "vpc-lattice-svcs", os.environ["AWS_REGION"]).add_auth(request)
    # ✅ signed headers required — ❌ bare curl without SigV4 will 403
    return requests.post(url, data=body, headers=dict(request.headers), timeout=30)

Application-level authorization still belongs in Verified Permissions / Cedar for fine-grained tool args. Lattice answers can this principal reach this service at all?

Topology patterns that work

Pattern A — Single network, prod tools
Planner VPC + tool VPCs associate to one network. Sandboxes are targets with short-lived tasks (Fargate Spot).

Pattern B — Split networks
coding-agent-tools-prod and coding-agent-tools-sandbox separate. Agents promote configs, not network trust.

Pattern C — Cross-account tools
Shared RAG account registers services; consumer accounts associate VPCs with RAM/Lattice sharing. Planner roles in tenant accounts get explicit principals in auth policies.

// ✅ CDK sketch: Lattice service + IAM auth for a tool
import * as lattice from "aws-cdk-lib/aws-vpclattice";

// Use L1 Cfn* constructs matching your CDK version for service network / service
// Enforce authType AWS_IAM and tag workload=coding-agent on every resource

Observability and fail-closed defaults

# ✅ access log subscription on the service network
aws vpc-lattice put-access-log-subscription \
  --resource-identifier sn-xxxx \
  --destination-arn arn:aws:s3:::company-lattice-logs/coding-agent/

Production checklist

• [ ] Service network per environment (prod/sandbox); tagged workload=coding-agent
• [ ] Every tool registered as a Lattice service with AWS_IAM auth
• [ ] Auth policies least-privilege by planner/tool role ARNs
• [ ] Tenant id conditions aligned with session tags on AssumeRole
• [ ] Access logs retained ≥ 90 days; SIEM ingest
• [ ] No auth-type NONE in prod
• [ ] Cedar/Verified Permissions still authorize tool arguments
• [ ] Bedrock stays on PrivateLink — Lattice is for your services
• [ ] Chaos: revoke planner role → invokes must 403 (FIS post next)

FAQ

Q: Lattice vs PrivateLink?
A: PrivateLink exposes a specific endpoint service (great for Bedrock or a single SaaS). Lattice is a many-service network with shared auth and discovery for internal microservices.

Q: Does Lattice replace API Gateway?
A: No. API Gateway/WAF remains the north-south public/partner edge. Lattice is east-west inside AWS.

Q: Lambda tools supported?
A: Yes — Lattice can target Lambda (and other target types). Still apply auth policies; do not rely on “Lambda URL open to VPC” shortcuts.

Migration path from SG spaghetti

Do not flip every tool on day one. Pick the hottest east-west path (usually planner → sandbox-exec). Register that service on Lattice, dual-run with the old SG path behind a flag, then remove the wide SG rule once SigV4 clients are stable. Next: RAG search. Last: anything that still needs raw IP allowlists for legacy agents.

# ✅ verify auth: unsigned request must fail
curl -i "https://sandbox-exec-xxxx.vpc-lattice-svcs.us-east-1.on.aws/v1/exec"   -H "content-type: application/json" -d '{"cmd":"true"}'
# expect 403 — ✅
# ❌ if 200, auth-type is wrong or policy is open

Document the Lattice DNS names in your internal service catalog so agents (and humans) stop hardcoding private IPs that die on redeploy.

Related reading

• AWS PrivateLink for Bedrock: Keep Model Calls Off the Public Internet
• AWS Verified Permissions (Cedar): Authorize Agent Tools
• AWS Network Firewall: Egress Filtering for Coding-Agent Sandboxes
• AWS App Runner: Host Coding-Agent HTTP APIs

Give every tool a Lattice identity, deny-by-default IAM auth, and stop pretending security groups are a service mesh for coding-agent fleets.

Last updated on October 1, 2026