AWS Agent Registry Goes GA—Five Regions Define the First Rollout

AWS’s August 31 launch notice places AWS Agent Registry in general availability in US West (Oregon), US East (N. Virginia), Europe (Ireland), Asia Pacific (Tokyo) and Asia Pacific (Sydney). The release adds cross-account sharing through AWS Resource Access Manager, infrastructure-as-code support and organization-wide detection for agents on AgentCore Runtime and AgentCore Gateway.
A September 1 independent technical review also identifies the five-Region GA footprint and the boundary between the full governed inventory and the approved discovery plane. That distinction matters for platform teams: production availability does not make every registered resource immediately discoverable.
The deployment-readiness matrix

The GA release opens the service for production use, but readiness still depends on several separately configured dimensions. A registry can satisfy one dimension while remaining blocked by another.
- Regional availability: deployments are limited to Oregon, Northern Virginia, Ireland, Tokyo and Sydney in the initial rollout. Cross-account sharing does not add another deployment Region.
- Supported record types: the AWS Agent Registry workflow defines MCP, Agent, Skills and Custom as its four semantic record types. Records can be created manually, while compatible MCP and Agent endpoints can supply metadata through synchronization.
- Cross-account scope: AWS RAM can share a registry with other accounts and support an organization-wide catalog. Sharing expands who can access the regional resource; it does not make that resource global.
- Infrastructure as code: AWS CloudFormation, Terraform and the AWS CDK can provision and manage registries. Registries and records also support tags for organization, cost allocation and access control.
- Publication state: a completed new record begins in Draft. Submission sends it to Pending approval under manual review or directly to Approved when automatic approval is enabled.
The result can be a registry that is deployed, shared and managed through code while its consumer-facing directory remains empty. Availability of the service, existence of a record and publication of that record are separate conditions.
Registration, approval and discovery are separate events

Registration creates governed metadata for an agent, tool, skill or custom resource. After asynchronous creation finishes, the record is in Draft and can be edited without appearing in the discovery surface.
Submission begins the publication decision. With automatic approval disabled, the record moves to Pending approval until a curator accepts or rejects it. With automatic approval enabled, submission still remains necessary, but it moves the record directly to Approved.
Approved is the discovery boundary. Draft, Pending approval, Rejected and Deprecated records do not appear in the Record directory or discoverable-data APIs. An approved record may therefore exist alongside a broader management inventory that consumers cannot search.
Editing an approved record creates a new draft revision, but the currently approved revision remains discoverable while the replacement is reviewed. Once the new revision is approved, discovery switches to that version; this avoids withdrawing a working catalog entry merely because an update is pending.
Approval carries registry-local meaning. It places a particular record revision inside that registry’s approved discovery set; it is not a separate AWS certification of the underlying resource’s security, runtime permissions, reliability or regulatory compliance.
Cross-account sharing expands access, not geography
A central platform account can share a registry through AWS RAM instead of requiring every participating account to maintain an isolated catalog. This can provide an organization-wide discovery layer, but the registry remains tied to the Region in which it was created.
Sharing and publishing also govern different questions. Resource sharing determines which accounts can access the registry under the permissions granted to them, while the approval configuration determines which records enter discovery. Access to an approved entry does not by itself grant authority to approve drafts.
Organization-wide detection addresses inventory through another path. Its GA scope covers agents on AgentCore Runtime and AgentCore Gateway across connected organizational accounts; it does not establish automatic detection for every AWS service or for arbitrary external runtimes. Detected resources enter the governed inventory as drafts rather than bypassing publication control.
Infrastructure-as-code support follows the same separation. A CloudFormation, Terraform or CDK deployment can create and configure the registry, including its policy boundaries, but it does not implicitly approve records added later. Platform configuration and catalog publication remain distinct governance layers.
The five-Region footprint remains the planning limit
The initial footprint provides two US Regions, two Asia-Pacific Regions and one European Region. Platform teams can centralize access across accounts, but deployment location must still be selected from those five options based on their own latency, continuity and data-location requirements.
The registry is accessible through its console, AWS CLI and AWS SDK, and it can expose an MCP endpoint to compatible clients. Approved resources can also be discovered from Amazon Bedrock AgentCore, Amazon Quick and Kiro IDE, subject to the registry’s authorization and publication settings.
As of September 10, the release details contain no timetable for expansion beyond the initial footprint. AWS Agent Registry is generally available with shared catalogs, code-managed provisioning and approval-gated discovery, while broader regional coverage remains the principal unresolved deployment boundary.
Also read:
Subscribe to our newsletter
Get the latest Web3, AI, and crypto news delivered straight to your inbox.