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:
Access denied errors(#2192 above)Painfully slow deployments (#2127 above)Next.js version support (#2343 above)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: AccessDeniedThe 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 elimination, I found that it was the S3 bucket. From there, I spent more hours to find out that it was the transfer acceleration, in particular, that was failing. I wasn’t able to enable/disable transfer acceleration myself meaning I had to rely on the AWS Support team to do it for me.
If you’ve used Vercel, then you’re in for a shock when using Amplify. Forget about 2–3 minute deployments, and get used to waiting 10–20 minutes. Apparently, it’s because of the CloudFront propagation, and that isn’t going to change. There doesn’t seem to be much hope here.
Scrolling through the GitHub issue reveals some terrifying deployment times:
Next.js moves fast, and so it’s expected that Amplify won’t be able to keep up with each new release. But Amplify needs to try harder. Upgrading to the latest Next.js version is always easy and always exciting; AWS can’t expect people to stay on Amplify if it means depriving them of these upgrades.
I was using Next.js version 11 which Amplify did support, but the support felt fragile. Next.js is now at version 12, but it seems that Amplify support is not even close.
I’ve picked three of the most memorable issues that I experienced, but I had many to choose from. For example, it was difficult to keep track of all the AWS resources that were being created for deployments, especially because they weren’t being automatically deleted when branches were merged, as you’d expect. Lambda@Edge functions are only ever deployed in the US East (N. Virginia) Region, not the Region where your app is deployed. This behavior is now documented, but it never used to be and it took me a while to figure it out on my own.
To end with a bold conclusion: deploying Next.js applications on Amplify is not possible in a way that’s acceptable for most development teams. You might get your application live, but your deployments will take forever, sometimes they won’t even work, you’ll be on an outdated version of Next.js, and you’ll waste time searching through the AWS console. Save yourself some time, use Vercel instead.
Share this on knowasiak.com to discuss with people on this topicSign up on Knowasiak.com now if you’re not registered yet.