Beware of Next.js on AWS Amplify

Deployments have never been harder

A few months ago, I was tasked with deploying some Next.js applications on AWS Amplify. I knew that it wouldn’t be quite as easy as with Vercel, but I was interested in trying something different. But the challenge proved far too great, and a few days later I was back to Vercel with no intention of ever using Amplify again.

Most of the challenges I faced were because my applications used server-side rendering (SSR) — which is extremely common with Next.js. SSR causes Amplify to really struggle because it requires additional AWS resources like Lambda@Edge functions and CloudFrontend distributions.

Filtering the amplify-hosting repo issues with the “SSR” label highlights this struggle:

Most of these issues were open when I was working with Amplify months ago, and it doesn’t look like they’ll be resolved soon. Many of them are significant blockers to a working deployment. Three of the most exhausting issues I dealt with are still there:

1. Access denied errors(#2192 above)
2. Painfully slow deployments (#2127 above)
3. Next.js version support (#2343 above)

Access Denied

If you try to deploy Next.js on Amplify, there’s a good chance you’ll come across the infamous error message:

Starting SSR Build… ERROR: AccessDenied

The fix for this seems to be different for each person that comes across it, and for some people, the fix has never been found. In my case, it was first because the recommended Amplify service role didn’t actually have enough permissions to deploy all the required resources. Giving full Administrator access got me one step closer, although providing full access on AWS is rarely a good idea.

The next part of the problem was even more frustrating: the AWS account I was using did not have S3 Bucket Transfer Acceleration enabled. Figuring this out wasn’t easy — the Amplify deployment didn’t tell me which resources were failing to deploy, but through a process of…