After I modernized my client’s platform security, the next strategic move was clear: elevate their product with generative AI. They wanted an LLM‑powered component capable of analyzing customer‑submitted documents during application intake and performing price forecasting. The goal was to dramatically improve user experience by streamlining the workflow, offering proactive suggestions, and providing real‑time assistance.

To deliver this, the AI analyst feature needed multilingual support, multi‑modal document understanding (images, PDFs, text files, and more), and advanced reasoning, which pointed directly to models like Claude. But there was a major constraint: the client’s primary business entity is registered in an unsupported region for these advanced AI models. The only viable path was to leverage their overseas entity to create a new AWS account in a supported region and integrate it with their existing environment.

The constraints were non‑negotiable:

  • multilingual inference
  • multi‑modal document processing
  • cross‑account AWS integration
  • cross‑region invocation
  • access to advanced LLMs such as Claude
  • strong security controls for sensitive customer data

It reads like an AWS Solution Architect Professional exam scenario? It wasn’t a hypothetical. This was a real‑world architecture challenge with real compliance, security, and business constraints.

To achieve the goal, I designed a two‑sided trust‑granting model between the two AWS environments. AWS Account A (AC‑a) operates in Region A, and AWS Account B (AC‑b) operates in Region B.

Why Lambda in AC‑b Is Mandatory

Claude enforces region restrictions based on the source IP. This means:

  • all traffic to Claude must originate from Region B, and
  • any request coming directly from Region A will be blocked, regardless of AWS account ownership.

Because of this, the Lambda function in AC‑b becomes a non‑negotiable region proxy. It is the only component allowed to make outbound requests to Claude, ensuring that Anthropic sees a valid Region‑B AWS IP.

In other words: AC‑a (data + app) → AC‑b (Lambda proxy + Claude) is the only viable architecture that satisfies both the business requirements and the regional restrictions.

Resources and IAM Roles

In AC‑a, an EC2 instance acts as the caller of the AI service hosted in AC‑b. The EC2 instance assumes the IAM role ec2‑production, which must be explicitly granted permission to invoke the Lambda function in AC‑b. 

{
    "Effect": "Allow",
    "Action": "lambda:InvokeFunction",
    "Resource": "arn:aws:lambda:region-b:ac-b-id:function:lambda-name"
}

At the same time, the Lambda function in AC‑b must enforce the reverse trust boundary: it should only accept invocations originating from AC‑a’s ec2‑production role. It uses resource-based policy: 

Statement ID : AllowCrossAccountPHPInvoke
Principal : arn:aws:iam::ac-a-id:user/ec2-production  
Effect : Allow
Action : lambda:InvokeFunction

At the Lambda IAM role level, it must be explicitly granted permission to access Amazon Bedrock and invoke Claude. This role becomes the trusted execution identity for all outbound LLM requests from AC‑b, ensuring that only the Lambda function running in the supported region is authorized to call the model: 

{
    "Sid": "AllowBedrockInvoke",
    "Effect": "Allow",
    "Action": "bedrock:InvokeModel",
    "Resource": [
	"arn:aws:bedrock:*:ac-b-id:inference-profile/your-claude-model",
	"arn:aws:bedrock:*::foundation-model/your-claude-model"
    ]
}

Set the region to “*” in the IAM policy, since Bedrock may internally route the invocation across multiple supported regions. This ensures the Lambda role can invoke the service regardless of the specific regional endpoint used.

This ensures mutual, least‑privilege trust across accounts and regions.

Cross‑Account Data Access

Because the system exchanges customer‑sensitive data across multiple AWS accounts and regions, the communication path must meet strict security guarantees. The design enforces three core requirements:

  • No traffic may traverse the public internet
  • Data can only originate from controlled, authenticated AWS resources
  • Data can only be delivered to controlled, authenticated AWS resources

The PrivateLink endpoint is protected by a dedicated security group that permits inbound HTTPS traffic only from the ec2-production instance. This ensures that no other resource, inside or outside the VPC, can reach the endpoint at the network layer.

In addition, the PrivateLink service is bound to a resource policy that explicitly authorizes only the ec2-production IAM role to invoke the controlled Lambda function. Even if another resource could reach the endpoint, the policy prevents it from calling the Lambda: 

{
    "Sid": "RestrictToLambda",
    "Principal": {
	"AWS": "arn:aws:iam::ac-a-id:user/ec2-production"
    },
    "Action": "lambda:InvokeFunction",
    "Effect": "Allow",
    "Resource": "arn:aws:lambda:aws-region-b:ac-b-id:function:lambda-name"
}

Together, the security group and the endpoint policy enforce strict, dual‑layer Zero Trust: network access is restricted to a single controlled source, and service‑level access is restricted to a single controlled identity.

The Lambda function is responsible for analyzing the customer’s document as part of the AI prediction workflow. However, due to regulatory requirements, all customer data must remain stored in AC‑a’s private S3 bucket. However, AC‑b still needs controlled access to this data for analysis. Therefore, the S3 bucket policy in AC‑a must selectively grant AC‑b permission to read only the required objects, while maintaining strict Zero Trust boundaries. This is the authoritative gatekeeper: 

{
    "Sid": "AllowACBReadSpecificObjects",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::ac-b-id:role/lambda-role"
    },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::your-bucket/path/to/allowed/*"
}

This ensures AC‑b cannot read anything outside the approved prefix.

In the AC-b, the lambda iam role attaches a policy to ensure that only attempt to access the specific S3 objects it is supposed to. This is the identity‑side limiter: 

{
    "Sid": "AllowReadOnlySpecificObjects",
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::your-bucket/path/to/allowed/*"
}

This is the same dual‑layer pattern AWS recommends for cross‑account S3 access with Zero Trust.

After the Claude model is activated and the required use‑case approvals are completed, the EC2 instance in AC‑a can securely invoke the AWS Bedrock service.

Bringing It All Together

This project was not only about adding generative AI to an existing platform, but also delivering advanced LLM capabilities under strict regional, security, and compliance constraints. By designing a cross‑account, cross‑region architecture with a mandatory Lambda proxy, enforcing mutual least‑privilege trust, and routing all sensitive data through PrivateLink, the solution enables multilingual, multi‑modal AI analysis without ever exposing customer information to the public internet.

The result is a fully compliant, Zero Trust, enterprise‑grade AI integration that unlocks Claude’s capabilities for a business operating. Transforming their application workflow while preserving the highest security standards.

What Next’s
Delivering a secure, cross‑account, cross‑region, multilingual, multi‑modal Bedrock pipeline is only the foundation. The next challenge is turning this architecture into an intelligent, language‑aware analysis engine that can process real enterprise documents at scale.

In my next article, I’ll go deeper into the Lambda Python function that powers this capability.

About the Author
Jonathan Wong is an IT and AI consultant with 20+ years of experience leading engineering teams across Vancouver and Hong Kong. He specializes in modernizing legacy platforms, cloud security, and building AI-ready systems for startups and large enterprises while advising leadership on using strategic technology to drive business growth. 
Connect with me on LinkedIn

Categorized in:

AI, AWS, Cybersecurity, Zero Trust,

Tagged in:

, , ,