Amazon Bedrock AgentCore Memory now supports cross-account access
Share a single AgentCore Memory resource across AWS accounts using resource-based policies—no more duplicating memory stores per account.
View original announcement →Visual Summary
graph TD
A{{AgentCore Memory Cross-Account}}:::announced
B((Account A - Owner)):::external
C((Account B - Consumer)):::external
D([Resource-Based Policy]):::feature
E([Semantic Search]):::feature
F(Amazon S3):::storage
G(Amazon SNS):::compute
H(Amazon Kinesis):::storage
I([Dual-Policy Evaluation]):::feature
B ==>|"owns memory"| A
C ==>|"references full ARN"| A
A -->|"configured via"| D
D -->|"grants access to"| C
A -->|"enables"| E
A -.->|"delivers to"| F
A -.->|"delivers to"| G
A -.->|"streams to"| H
A -->|"enforces"| I
classDef announced fill:#ff9900,stroke:#ec7211,color:#fff,font-weight:bold
classDef compute fill:#e3f2fd,stroke:#1565c0,color:#1565c0
classDef storage fill:#e8f5e9,stroke:#2e7d32,color:#2e7d32
classDef feature fill:#fff3e0,stroke:#e65100,color:#e65100
classDef external fill:#f5f5f5,stroke:#616161,color:#616161
What's New
Amazon Bedrock AgentCore Memory now supports cross-account access, enabling multi-account architectures where memory resources in one AWS account can be accessed and consumed by agents running in separate accounts. Organizations can grant cross-account principals permission to call memory data plane APIs—including creating events, writing records, retrieving records, and performing semantic search—via resource-based policies. Additionally, memory delivery destinations such as Amazon S3 buckets, SNS topics, and Kinesis Data Streams can now reside in a different account from the memory resource itself.
How It Works
- Resource-based policy attachment: Account A (resource owner) attaches a resource-based policy to the memory resource using the
PutResourcePolicyAPI, explicitly granting specific data plane actions to a principal (IAM role or user) in Account B. - Cross-account data plane operations: Once the policy is in place, principals in Account B reference the full memory ARN (e.g.,
arn:aws:bedrock-agentcore:us-east-1:<account-id>:memory/<memory-id>) in their API calls; AWS evaluates both the resource-based policy and the caller's identity-based policy before granting access. - Supported data plane actions: Cross-account principals can create events, write memory records, retrieve records, and perform semantic search against the remote memory resource.
- Cross-account delivery destinations: Account A creates a memory execution role with permissions to write to target resources in Account B; the target S3 bucket, SNS topic, or Kinesis Data Stream in Account B must have a resource-based policy allowing the execution role from Account A.
- Memory creation with cross-account destinations: The memory resource in Account A is created referencing the execution role and the cross-account resource ARNs, establishing the delivery pipeline at creation time.
- Dual-policy evaluation: AWS enforces both the resource-based policy on the memory and the identity-based policy of the consuming principal, ensuring least-privilege access across account boundaries.
Why It's Important
- Enables enterprise multi-account strategies: Large organizations that follow AWS multi-account best practices (e.g., separate accounts per team, environment, or business unit) can now share a centralized memory store without collapsing their account boundaries.
- Centralized memory governance: A single memory resource can serve agents distributed across many accounts, simplifying lifecycle management, auditing, and cost attribution for persistent agent memory.
- Decoupled data pipelines: Cross-account delivery to S3, SNS, and Kinesis allows data engineering and analytics teams to own their ingestion infrastructure in dedicated accounts while agent teams operate independently.
- Reduced operational overhead: Teams no longer need to replicate or synchronize memory data across accounts; a single authoritative source is accessible wherever agents run.
- Improved security posture: Resource-based policies provide fine-grained, auditable access control, keeping memory data in a governed account while still allowing controlled sharing.
- Unlocks agentic platform patterns: Platform teams can build shared memory services as internal products, exposing them to application teams via policy without granting broad account-level access.
How It's Different
- Resource-based policy model vs. role assumption: Unlike patterns that require cross-account role assumption (STS AssumeRole) for every call, this approach lets consuming principals call memory APIs directly using their own identity, with access governed by the resource policy on the memory—reducing credential management complexity.
- Native ARN-based referencing: Consuming agents reference the memory by its full ARN directly in API calls, making cross-account access transparent and consistent with same-account usage patterns.
- Delivery destination flexibility: Unlike many managed services that restrict delivery targets to same-account resources, AgentCore Memory explicitly supports cross-account S3, SNS, and Kinesis destinations configured at memory creation time.
- Integrated with AgentCore execution role model: Cross-account delivery leverages the existing memory execution role construct, fitting naturally into the AgentCore security model rather than requiring a separate integration pattern.
- Semantic search across accounts: Cross-account principals can perform semantic (vector) search against the remote memory, not just raw record retrieval—preserving the full intelligence of the memory service across account boundaries.
When to Prefer It
- Centralized agent memory platform: When a platform engineering team manages a shared memory service in a dedicated "platform" account and multiple application teams operate agents in their own accounts.
- Environment isolation with shared memory: When development, staging, and production agents live in separate accounts but need to share or migrate memory records (e.g., promoting learned context from staging to production).
- Regulated workloads with data residency requirements: When memory data must reside in a specific, tightly controlled account (e.g., a security or data account) while compute and agent logic run elsewhere.
- Cross-team agentic workflows: When agents owned by different business units need to read from or contribute to a shared memory store without merging their AWS accounts or IAM boundaries.
- Analytics and observability pipelines in dedicated accounts: When a data engineering team owns S3 buckets or Kinesis streams in a logging/analytics account and needs agent memory events delivered there without granting the agent account broad access.
- ISV or SaaS multi-tenant architectures: When a software vendor hosts memory resources in their account and needs to expose memory capabilities to customer accounts in a controlled, policy-driven manner.
Availability
- GA status: Generally available; this is a production feature, not a preview.
- Supported regions: Available in all AWS Regions where AgentCore Memory is supported, which includes US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt, Ireland, London, Paris, Stockholm), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo, Seoul), Canada (Central), and South America (São Paulo). Note: AWS GovCloud (US-West) is listed as supporting AgentCore Memory per the regional table.
- Configuration entry point: Cross-account data plane access is configured via the
PutResourcePolicyAPI on the memory resource; cross-account delivery destinations are configured at memory creation time using the execution role and target resource ARNs. - Pricing: No separate charge is announced for cross-account access; standard Amazon Bedrock AgentCore Memory pricing applies for API calls and storage.
- Limitation — delivery destination timing: Cross-account delivery destinations must be specified at memory creation time and cannot be added retroactively without recreating the memory resource.
- Prerequisite: The memory resource must already exist in the resource owner account, and target destination resources (S3, SNS, Kinesis) must be pre-created in the consuming account before configuring cross-account delivery.
