Why Next.js On-Demand Revalidation Fails on Amplify Hosting

AWS states that Next.js on-demand revalidation will not work on Amplify Hosting. I still map each Amplify Data mutation to its article, indexes, and sitemap because that dependency map supports time-based freshness, rebuilds, or another host. The write and refresh remain separate stages, which prevents a failed cache operation from repeating the data mutation.

Map data to rendered surfaces

I start with one content type and list every surface that reads it. A blog mutation can affect the article, blog index, category, tag, sitemap, and feed. AWS documents managed Amplify SSR support through Next.js 15, so Next.js 16 cache behavior must be verified on the hosted branch.

I name one record tag and one collection tag. Routes that combine several content types declare each dependency, which makes a missing invalidation easier to find.

Choose a supported freshness behavior

The Next.js references for Next.js revalidateTag reference and Next.js updateTag reference describe framework semantics, but AWS lists on-demand ISR as unsupported and states that Next.js on-demand revalidation will not work on Amplify Hosting. I treat updateTag, revalidateTag, and revalidatePath as unsupported experiments on this host.

A production design needs direct request-time reads, supported time-based freshness, a controlled rebuild, or a host that supports these APIs.

Map paths even when the host cannot revalidate

A path map still identifies where a slug edit affects both the old and new routes and where a title edit changes a list. On a supporting host, that map can drive revalidatePath. On Amplify, it can drive a rebuild, time-based policy, or verification queue.

The mutation maps known content events to allowlisted routes. It does not accept an arbitrary path from a browser field or webhook payload.

Keep the write and refresh separate

Amplify Data must confirm the mutation before the application starts its supported freshness step. I capture a request or event ID across both stages. If a rebuild or verification step fails, the data stays committed and a worker can retry without repeating the mutation.

This separation also handles duplicate webhooks. Replaying a freshness check is safe; replaying a non-idempotent write may create another record.

Test the cases that change topology

I publish, update, rename, unpublish, and delete a synthetic record. The checks request the article, relevant lists, sitemap, and feed after each action. A slug change must remove or redirect the old route according to the site's policy.

I also force one supported freshness-step failure, such as a failed rebuild trigger or verification job, and confirm that monitoring records it. A successful editor toast cannot stand in for public-page verification.

Keep the cache plan small

Broad tag names such as content are easy to add and expensive to reason about. I prefer tags that identify a content domain and record. The resulting log can state which dependency changed without exposing the record body.

My Strapi hosting comparison covers the same ownership question for CMS-triggered invalidation and recovery.

Need a cache invalidation map?

I can trace an Amplify mutation to its affected routes and choose a freshness path the host supports. Send the content model and sanitized route list through the contact page, or see my Next.js services.