AWS Just Moved 21 Services Into Maintenance Mode: What the July 30 Cutoff Means for Your Next AWS Account

On 30 June 2026, AWS published a routine-looking page called AWS Service Availability Updates. It reads like housekeeping. It is not. Twenty-one services and features moved into Maintenance, four entered Sunset, and two reached End of Support. Buried in that list are Amazon Kendra, Amazon Q Business, Amazon Bedrock Agents, and AWS Directory Service Simple AD. If your business runs any of them, the door closes on 30 July 2026, and it closes in a way most engineering teams will not notice until it breaks something expensive.

The short answer is simple: AWS Maintenance Mode does not mean your existing workloads will stop running. If you’re already using these services, AWS will continue to operate and support them by providing bug fixes, security patches, and ongoing reliability improvements. However, no new features or enhancements will be introduced.

The biggest change with AWS Maintenance Mode affects new resource creation. Starting July 30, 2026, AWS accounts that have never used these services before will no longer be able to provision new resources in them. While this may seem like a minor policy update, it has significant implications because the restriction applies to individual AWS accounts, not your entire AWS Organization.

For example, your existing production account may already be allowlisted and continue operating without interruption. But if you create a new AWS account next quarter for a new region, a newly acquired business, or a disaster recovery environment that account will not have the same access. This account-level limitation is the hidden risk organizations need to plan for before the July 30 deadline.

The Numbers Behind the July 30 Cutoff

We pulled the figures directly from the AWS lifecycle announcement and each service’s own migration documentation. Every number below traces to a primary AWS source.

The single most useful figure in that table is 32 versus 7. Amazon Kendra shipped with more than thirty native connectors. Its recommended replacement, Bedrock Managed Knowledge Base, ships with seven, namely S3, Confluence, SharePoint, Web Crawler, Google Drive, OneDrive, and a custom connector. If your enterprise search index pulls from Salesforce, ServiceNow, Jira, or a database, the migration is not a configuration change. It is a data pipeline you now own and operate.

Maintenance Mode Is Not Deprecation, and That Is the Problem

AWS defines three states in its lifecycle framework. Maintenance means no new customers and no new features, but continued operation and support. Sunset means AWS has announced a date on which it will end operations, typically twelve months out. Full Shutdown means the service is gone. Only Sunset carries a countdown clock.

Because Maintenance carries no deadline, it generates no urgency, and that is exactly why it hurts. A deprecation notice with a date lands in someone’s calendar. A maintenance notice lands nowhere. Bedrock Agents Classic is the clearest example. AWS states plainly that there is no migration deadline and no planned end-of-life date, then states equally plainly that the model catalog available in Bedrock Agents Classic is frozen as of 30 July 2026, and that models released after that date will only appear in AgentCore. So the service will keep running your agents indefinitely, on a model catalog that stops advancing on a fixed date. That is not a cliff. It is a slow slide, and the slide is invisible on any dashboard you currently look at.

The Account Boundary Is Where Teams Get Caught

Read the Bedrock Agents Classic FAQ carefully and a specific operational risk appears. Allowlisting is determined automatically by whether an account has called CreateAgent or InvokeInlineAgent in the previous twelve months. It applies per account. There is no exception process after 30 July, and AWS says so explicitly.

Now picture a normal scale-up. Production sits in one account. Staging sits in another. A third account was created eight months ago for the EU region and has never called CreateAgent because the agent workload has not shipped there yet. On 31 July, your Terraform plan for the EU account runs, calls CreateAgent, and returns AccessDeniedException with HTTP 403. Your infrastructure as code is correct. Your template is unchanged. AWS confirms existing IaC templates continue to work for allowlisted accounts, which is precisely the sentence that tells you the unallowlisted ones will fail. The failure surfaces in a pipeline, at the worst possible moment, in the account nobody was watching.

The same shape of problem applies to Simple AD. AWS is clear that existing Simple AD customers retain full functionality and can continue to create new directories. But a brand new account cannot onboard. If your account vending machine bakes Simple AD into every new landing zone, that pattern has a shelf life measured in weeks.

Kendra to Bedrock Knowledge Bases Is a Rewrite, Not a Lift

AWS calls the Kendra path a migration. Reading its own guide, it is closer to a rebuild. The Retrieve API changes shape, with query text moving from a top level parameter into a nested retrievalQuery object, and AttributeFilter becoming a filter inside managedSearchConfiguration. Metadata filter operators mostly map across, but startsWith and stringContains have no equivalent, so any application relying on substring matching needs its metadata schema restructured.

Then come the feature gaps. Query suggestions, faceted search, custom synonyms, spell checking, incremental learning, and custom document enrichment all have no direct replacement. AWS supplies workarounds for each, and every single workaround is a component your team builds and runs. Faceted search becomes metadata filtering plus a hand-maintained UI. Spell checking becomes a Lambda function. Custom synonyms become a query rewriting service in front of your retrieval call. Document enrichment becomes a Step Functions pipeline. None of that is unreasonable engineering. All of it is engineering you were not doing last quarter.

Amazon Q Business tells a similar story with a friendlier entry point. The Bring Your Own Index capability lets you attach an existing Q Business index to Amazon Quick without reingesting anything, which is a genuinely low-risk first step. But you can connect only two Q Business indexes per region, and AWS states the quota cannot be increased. Q Apps, Actions, and Q Business chat guardrails are excluded from BYOI entirely. In non-IDC deployments, every Quick user automatically receives access to every connected index, which quietly dissolves the per-user and per-group access boundaries Q Business enforced. If you run Q Business in a regulated environment, that sentence is a compliance finding waiting to happen.

What This Says About Building on Managed AI Services

There is a broader lesson here, and it is not that AWS is unreliable. It is that the managed AI layer is moving faster than the infrastructure layer beneath it. EC2 instance families get deprecated on multi-year timelines with loud warnings. Kendra launched in 2019 and entered maintenance in 2026. Bedrock Agents launched in November 2023 and became Bedrock Agents Classic in June 2026, a working life of roughly thirty-one months.

For a founder deciding where to place a bet, the practical implication is about coupling, not vendor choice. Anything that talks to a managed AI service should sit behind an interface you own. If your application calls kendra.retrieve directly from business logic scattered across a codebase, the migration cost is proportional to the number of call sites. If it calls your own SearchProvider that happens to wrap Kendra, the migration is one class. That abstraction cost you an afternoon when you wrote it. It just saved you a quarter.

The same holds for identity, for directory services, and for anything AWS ships as a convenience wrapper over a primitive. Simple AD was always a Samba-based convenience over Active Directory. AWS Managed Microsoft AD is the primitive. Convenience wrappers age faster than primitives, every time.

What to Do About It

Start with an inventory, not a migration. Query CloudTrail across every account in your organisation for calls to the affected APIs over the last twelve months. That single query tells you two things at once, namely which services you actually depend on and which accounts are allowlisted. Anything showing usage in production but no usage in your disaster recovery or newer regional accounts is an immediate action item, because those accounts will fail on 30 July.

Next, close the account gap before the deadline rather than after. If you know you will need Bedrock Agents Classic in an account that has never called CreateAgent, calling it once before 30 July puts that account on the allowlist permanently. That is not a hack. It is the documented mechanism, and there is no exception process afterwards.

Then sequence the real migrations by blast radius rather than by deadline, because Maintenance services have no deadline. Simple AD to AWS Managed Microsoft AD or AD Connector is well trodden and should be scheduled into a normal quarter. Bedrock Agents Classic to AgentCore takes hours for a straightforward agent and considerably longer if you built custom orchestration or multi-agent supervisor patterns, because routing-mode multi-agent collaboration is not straightforward on AgentCore today. Kendra to Bedrock Managed Knowledge Base is the one to start now, run in parallel, and validate with a golden query set measured on NDCG or MRR before you cut traffic over. AWS recommends running both side by side and comparing top-ten result overlap, and that is exactly the right amount of paranoia.

Finally, put the AWS Product Lifecycle RSS feed into the same channel that receives your production alerts. These announcements arrive quarterly, they arrive without fanfare, and the cost of reading them late is measured in unplanned engineering quarters.

At HAZERCLOUD we spend our days inside AWS accounts that grew faster than the governance around them, and the July 2026 lifecycle changes are the kind of thing that quietly reshapes a roadmap. If you want a clear picture of which of these twenty-one services you actually depend on, which of your accounts are allowlisted, and what a sensible migration sequence looks like for your architecture, we offer a free consultation and migration assessment. Get in touch with HAZERCLOUD and we will run the inventory with you before the 30 July cutoff, not after it.

Jobin Joseph

View all posts by Jobin Joseph

hazercloud.com