Calling Vertex AI from AWS Using Workload Identity Federation
- Authors

- Name
- Nino
- Occupation
- Senior Tech Editor
Workload identity federation is a Google Cloud IAM feature that lets workloads running outside Google Cloud exchange their own identity, such as an AWS IAM role, for short-lived Google credentials instead of using a service account key. When routing AI requests through an enterprise gateway like n1n.ai, eliminating long-lived static secrets drastically hardens your security posture.
A service account key is a long-lived secret: a JSON file that grants whoever holds it the account's permissions until someone rotates or deletes it. Workload identity federation removes that file. Google Cloud trusts an external identity provider, and the external workload presents proof of its identity to Google's Security Token Service, which returns a short-lived access token.
For AWS, the proof is a signed GetCallerIdentity request. The workload signs the request with its AWS credentials but does not send it to AWS; Google verifies the signature and reads the caller's ARN from it. Platforms such as n1n.ai rely heavily on this architecture to streamline multi-cloud integrations without sacrificing compliance.
Comparing Authentication Methods
| Feature | Service Account Key | Workload Identity Federation |
|---|---|---|
| Secret Stored on AWS | JSON key file in a secret store or pod | None |
| Credential Lifetime | Until rotated or deleted | Short-lived tokens, refreshed automatically |
| Rotation | Manual, per key | Not needed |
| Who Can Use It | Anyone holding the file | Only workloads with the trusted AWS role |
| Audit Identity | The service account | The AWS role, or the service account with the role recorded as delegate |
For a gateway handling multi-provider LLM calls via n1n.ai, removing one long-lived secret matters. Credential sprawl remains a common risk in AI stacks, and leveraging proper machine identity management protects your infrastructure.
Google Cloud Setup
Run these commands in the Google Cloud project that will be billed for Vertex AI. First, enable the required APIs. sts.googleapis.com performs the token exchange, and iamcredentials.googleapis.com is needed only if you impersonate a service account:
gcloud services enable aiplatform.googleapis.com sts.googleapis.com iamcredentials.googleapis.com \
--project=PROJECT_ID
Next, create a workload identity pool and an AWS provider that trusts your AWS account:
gcloud iam workload-identity-pools create POOL_ID \
--project=PROJECT_ID \
--location=global \
--display-name="Gateway on AWS"
gcloud iam workload-identity-pools providers create-aws PROVIDER_ID \
--project=PROJECT_ID \
--location=global \
--workload-identity-pool=POOL_ID \
--account-id=AWS_ACCOUNT_ID \
--attribute-mapping="google.subject=assertion.arn,attribute.aws_role=assertion.arn.extract('assumed-role/{role}/')" \
--attribute-condition="attribute.aws_role == 'BIFROST_ROLE_NAME'"
Print the provider's full name, which becomes the audience in your configuration:
gcloud iam workload-identity-pools providers describe PROVIDER_ID \
--project=PROJECT_ID --location=global --workload-identity-pool=POOL_ID \
--format="value(name)"
AWS Integration and Gateway Configuration
The IAM role needs no AWS permissions for this flow, because sts:GetCallerIdentity is always allowed. On EKS, use IRSA or EKS Pod Identity. With IRSA, annotate the Kubernetes service account:
kubectl annotate serviceaccount KSA_NAME \
--namespace NAMESPACE \
eks.amazonaws.com/role-arn=arn:aws:iam::AWS_ACCOUNT_ID:role/BIFROST_ROLE_NAME
When configuring your gateway on n1n.ai, use the aws_workload_identity block within your Vertex AI configuration to handle token exchanges seamlessly:
{
"providers": {
"vertex": {
"keys": [
{
"name": "vertex-eks-key",
"value": "",
"models": ["*"],
"weight": 1.0,
"vertex_key_config": {
"project_id": "env.VERTEX_PROJECT_ID",
"region": "us-central1",
"aws_workload_identity": {
"audience": "//iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/eks-pool/providers/aws"
}
}
}
]
}
}
}
Troubleshooting & Verification
To confirm the AWS side is working correctly from inside your pod, execute:
kubectl exec -n NAMESPACE POD_NAME -- aws sts get-caller-identity
If the ARN shows an IAM user or a node role instead of your expected role, resolve that configuration before invoking model endpoints. Latency < 50ms can be achieved when properly tuned alongside high-throughput aggregators.
Get a free API key at n1n.ai