Deploying an AI Governance Proxy on Amazon EKS with AWS PrivateLink to Amazon Bedrock
Make the governance proxy the only workload that can invoke Amazon Bedrock. Connect it through a VPC interface endpoint, scope the endpoint policy and the proxy's IAM permissions to approved models, block every other pod from reaching Bedrock with network policies and IAM, and log each request in the proxy so it can be reconciled with AWS logs. Then test the private path and the bypass controls directly.
Reference architecture
Every Bedrock call follows one governed path. AI workloads call the proxy through an internal Kubernetes service, the proxy forwards approved requests through a VPC interface endpoint, and Amazon Bedrock receives requests only from the proxy's identity over that approved path.
| Component | Role in the path |
|---|---|
| 1. AI workloads | Call the proxy through an internal Kubernetes service. No direct Bedrock access. |
| 2. Governance proxy | Authenticates the caller, evaluates policy, forwards the request, and records the decision. |
| 3. VPC interface endpoint | Private connectivity to Bedrock with its own security group and endpoint policy. |
| 4. Amazon Bedrock | Receives requests only from the proxy's identity over the approved path. |
Deployment sequence
Work through the deployment in this order, so that the private path and the restrictions are in place before any workload depends on them.
- Connect the proxy privately. Use a VPC interface endpoint to reach Amazon Bedrock.
- Scope the policies. Limit the endpoint policy and the proxy's IAM permissions to approved models.
- Block every other pod. Use network policies and IAM to stop other workloads from reaching Bedrock.
- Log each request in the proxy. Keep records that can be reconciled with AWS logs.
- Test directly. Verify the private path and the bypass controls, using the checklist below.
Preventing proxy bypass
The proxy only governs traffic that passes through it, so no other pod should be able to invoke Bedrock. Apply two independent layers: network policies that block other pods from reaching Bedrock, and IAM that denies Bedrock access to every identity except the proxy's.
Scoping identity and policy to least privilege
Approved models are enforced in more than one place. The proxy authenticates the caller and evaluates policy, the proxy's IAM permissions are scoped to approved models, and the endpoint policy on the VPC interface endpoint applies the same limit. The endpoint also has its own security group.
A request from the proxy for an unapproved model should be denied by the proxy's policy and by IAM or endpoint policy.
Request-level audit logging and reconciliation
The proxy records each decision it makes, and those records are reconciled with AWS logs. Every invocation in AWS-side logs should have a matching proxy audit record. Denied requests should appear in the proxy log with the policy rule that blocked them. VPC Flow Logs show whether proxy traffic goes to the endpoint interfaces and whether any Bedrock traffic leaves by a public path.
Verification checklist
- DNS resolution for the Bedrock runtime hostname from the proxy pod returns private addresses.
- VPC Flow Logs show proxy traffic going to the endpoint interfaces, with no Bedrock traffic leaving by a public path.
- A test pod in a workload namespace fails a direct Bedrock call at both the network layer and the IAM layer.
- A request from the proxy for an unapproved model is denied by the proxy's policy and by IAM or endpoint policy.
- Every invocation in AWS-side logs has a matching proxy audit record.
- Denied requests appear in the proxy log with the policy rule that blocked them.
Plan runtime policy enforcement for LLM traffic
If your team is designing a central control point for Bedrock traffic on EKS, discuss how runtime policy enforcement, agent identity, and audit logging fit your architecture.
Talk to an Expert