AWS Config Just Added 30 Resource Types. The Bedrock AgentCore Ones Matter Most.
- Stephen Jones
- Aws , Ai , Security
- March 3, 2026
Table of Contents
AWS quietly announced support for 30 new resource types in AWS Config on March 2, 2026. If you’re the kind of person who skims these announcements and moves on, I get it. Most Config resource type expansions are incremental. This one isn’t.
Buried in the list of DataBrew datasets and GameLift fleets are two resource types that should make anyone deploying AI agents sit up straight: AWS::BedrockAgentCore::Gateway and AWS::BedrockAgentCore::Memory.
If you’ve been following my writing on Config, you know I think it’s one of the most underused services in AWS. And if you’ve been following my coverage of Bedrock AgentCore and the governance gap in AI agent deployments, this is the announcement that ties those two threads together.
Why AgentCore in Config Changes the Game
Let’s be direct about what these two new resource types mean.
AWS::BedrockAgentCore::Gateway
AgentCore Gateways are the front door to your AI agents. They handle request routing, authentication, and traffic management for agent deployments. Until now, if you wanted to know whether someone had modified a gateway configuration, added a new route, or changed authentication settings, you were relying on CloudTrail events and hoping you’d written the right EventBridge rules to catch changes.
Now Config tracks gateway state continuously. That means:
- Configuration drift detection — You can write Config rules that alert when a gateway’s authentication settings deviate from your baseline. If someone disables auth on a production gateway, you’ll know.
- Historical configuration — Config’s timeline view lets you see exactly what a gateway looked like at any point in time. When an agent starts behaving unexpectedly after a deployment, you can compare the current gateway config against the version that was working.
- Cross-account aggregation — If you’re running AgentCore across multiple accounts (and you should be separating production from development), Config Aggregators now give you a single pane of glass across all your agent gateways.
AWS::BedrockAgentCore::Memory
This is the one that really matters for governance. AgentCore Memory is how agents maintain context across sessions — conversation history, user preferences, retrieved knowledge, tool execution results. It’s the component that makes agents feel “intelligent” rather than stateless.
It’s also the component that, if misconfigured, could expose sensitive data across sessions, persist PII longer than your retention policies allow, or leak context between users.
Having Memory tracked in Config means you can now:
- Audit memory configuration changes — Who changed the retention policy? When? What was it before?
- Enforce compliance rules — Write custom Config rules that flag any Memory configuration without encryption at rest, or with retention periods exceeding your data governance requirements.
- Inventory at scale — How many Memory configurations exist across your organisation? Which accounts are running agents with persistent memory? Config Aggregators answer this in seconds.
I wrote about the policy and evaluation controls that AgentCore introduced in December. Those were the “what should agents be allowed to do” controls. Config support is the “can we prove they’re configured correctly” control. They’re complementary, and you need both.
The Full List
Here are all 30 new resource types, grouped by service:
AI & Machine Learning
| Resource Type | What It Tracks |
|---|---|
AWS::Bedrock::DataSource | Knowledge base data source configurations — where your agents pull their context from |
AWS::BedrockAgentCore::Gateway | Agent gateway routing, auth, and traffic configuration |
AWS::BedrockAgentCore::Memory | Agent session memory and context persistence settings |
Identity & Access
| Resource Type | What It Tracks |
|---|---|
AWS::Cognito::IdentityPoolRoleAttachment | Which IAM roles are mapped to identity pool auth/unauth users |
AWS::Cognito::LogDeliveryConfiguration | Where Cognito sends its logs (or whether it’s logging at all) |
AWS::Cognito::UserPoolUICustomizationAttachment | Custom branding on hosted UI — less critical for security, but useful for config drift |
AWS::VerifiedPermissions::IdentitySource | Cedar policy identity sources — the bridge between Cognito and fine-grained authorization |
Data & Analytics
| Resource Type | What It Tracks |
|---|---|
AWS::AppSync::DataSource | GraphQL API data source connections |
AWS::DataBrew::Dataset | Data preparation dataset definitions |
AWS::DataBrew::Job | Data transformation job configurations |
AWS::DataBrew::Project | DataBrew project settings |
AWS::DataBrew::Recipe | Data transformation recipes |
AWS::DataBrew::Ruleset | Data quality rule definitions |
AWS::DataBrew::Schedule | Automated job schedules |
AWS::Omics::ReferenceStore | Genomic reference data store configurations |
Infrastructure & Compute
| Resource Type | What It Tracks |
|---|---|
AWS::Batch::ConsumableResource | Batch compute consumable resource definitions |
AWS::GameLift::ContainerFleet | Container-based game server fleet configurations |
AWS::GameLift::ContainerGroupDefinition | Container group settings for GameLift |
AWS::GameLift::GameServerGroup | Game server group auto-scaling settings |
AWS::GameLift::Location | Custom GameLift location definitions |
AWS::Deadline::LicenseEndpoint | Render farm license server endpoints |
AWS::Deadline::QueueEnvironment | Render queue environment configurations |
Networking & IoT
| Resource Type | What It Tracks |
|---|---|
AWS::Connect::RoutingProfile | Contact center agent routing configurations |
AWS::IoT::TopicRule | IoT message routing rules |
Security & Governance
| Resource Type | What It Tracks |
|---|---|
AWS::Detective::OrganizationAdmin | Delegated admin for Detective across the organisation |
AWS::PCAConnectorAD::Template | Private CA certificate templates for Active Directory |
AWS::PCAConnectorSCEP::Challenge | SCEP challenge configurations for device certificates |
AWS::ResourceExplorer2::View | Resource Explorer saved views and filters |
AWS::ResourceGroups::Group | Resource group membership and tag-based groupings |
AWS::Scheduler::ScheduleGroup | EventBridge Scheduler group configurations |
What I’d Do With This
If you’re running Bedrock AgentCore in any capacity, here’s the immediate action list:
Enable Config recording for the three Bedrock resource types if you haven’t already. Config should be recording all supported resource types by default, but if you’re using selective recording, add these explicitly.
Write a custom Config rule that checks
AWS::BedrockAgentCore::Memoryfor encryption-at-rest and maximum retention period. If you’ve been following the Config + cfn-guard approach I covered previously, you already have the pattern for this.Add these to your Config Aggregator queries. If you’re using advanced queries (and you should be — I wrote about why Config’s query capability is so underrated), you can now run SQL-like queries across all your agent infrastructure in seconds.
Set up a Security Hub integration. Security Hub’s support for custom Config rules means you can feed AgentCore compliance findings directly into your security dashboard alongside everything else.
The Cognito additions are also worth calling out. If you’re using Cognito for user authentication (and a lot of AWS shops are), having IdentityPoolRoleAttachment in Config means you can finally track when someone changes which IAM roles get attached to your identity pools. That’s been a blind spot for a while.
The Bigger Picture
AWS has been steadily expanding Config’s resource coverage, but the addition of AI service resource types signals something important: the compliance and governance tooling is catching up with the pace of AI service adoption.
Six months ago, you could deploy an AgentCore gateway and memory configuration with essentially no configuration management visibility. Now you have the same continuous compliance controls you’d expect for an EC2 instance or an S3 bucket.
That’s how it should work. The infrastructure governance story shouldn’t have gaps just because the technology is new. If you’ve been following the Config Conundrum I wrote about years ago, you’ll know this has been a recurring theme — the gap between what AWS ships and what Config can actually track.
That gap just got 30 resource types smaller.
