Forem: Tanseer

AWS Amplify Cache Is Useless — And Here Is the Data to Prove It

Tanseer — Wed, 29 Apr 2026 06:47:04 +0000

Who This Is For

If you are deploying a frontend or full-stack app on AWS Amplify and your builds feel slower than they should be, this blog is worth reading. We are going to talk about Amplify's caching system — what it is supposed to do, what it actually does, and why in my experience it makes things worse, not better.

No deep AWS knowledge is required. If you know what a build pipeline is and have used Amplify at least once, you will follow this completely.

The Problem I Ran Into

I was deploying an app on AWS Amplify. The build had two phases: install packages and build the app. Pretty standard setup.

The total build time was sitting at around 9 minutes. That felt too long. So I opened the build logs and started looking at where the time was actually going.

Here is what I found:

3 minutes to restore cache (fetch previously stored files)
3 minutes to install packages and build the app
3 minutes to save cache (store files for the next build) So out of 9 minutes, the actual work — installing and building — was only 3 minutes. The other 6 minutes were spent entirely on cache operations.

That immediately felt wrong. Cache is supposed to speed things up. If it is consuming twice the time of the actual build, something is broken.

The First Experiment: Disable Cache Entirely

My first instinct was simple. What if I just removed the cache configuration completely and let Amplify install everything fresh every time?

I removed the cache settings from my amplify.yml build config and triggered a new build.

The result: 3 minutes and 30 seconds.

The build went from 9 minutes to 3 minutes 30 seconds just by removing cache. Yes, it took an extra 30 seconds to download packages compared to the ideal cached scenario. But it saved 6 full minutes of cache overhead.

This alone should raise a flag. The cache was not saving time. It was adding time.

What Is Amplify Cache, Exactly?

Before going further, let me explain how Amplify's caching works, because understanding the mechanism is key to understanding why it fails.

When Amplify runs a build, it can be configured to save certain folders — most commonly node_modules — by zipping them up and storing them in S3 (AWS's file storage service). On the next build, it fetches that zip, unzips it into the build environment, and in theory your packages are already there so the install step is faster.

The key operation here is: zip and upload after a build, download and unzip before the next build.

This is how Amplify's cache model works. It is essentially just copying folders in and out of storage between builds.

The Second Experiment: Maybe It Is My Project

After the first result, I thought maybe the problem was specific to my project. I had a reasonably large dependency tree. Maybe the node_modules folder was so big that zipping and unzipping it was always going to take longer than just reinstalling.

So I created a minimal test project — a simple website with almost no packages. Just enough to have a package.json and a basic build step. The kind of project where node_modules is tiny and cache should be trivially fast.

I deployed it on Amplify with cache enabled.

Same result. Amplify spent time fetching the cache, and then installed all dependencies from scratch anyway. The cache folder it had stored from the previous build was essentially ignored from a practical standpoint.

The Root Cause: Cache and npm Are Fundamentally Incompatible

After these experiments, I did some digging and found the real reason this does not work. It comes down to how npm (the package manager) behaves versus how Amplify's cache model works.

Amplify caches folders. That is it. It saves a folder, restores a folder.

But here is the problem:

If you use npm ci (which is the recommended command for CI/CD pipelines because it gives you clean, reproducible installs), it deletes node_modules entirely before installing. Every single time. It does not matter that Amplify just spent 3 minutes restoring that folder. npm ci will delete it and start over.

If you use npm install (the more common development command), it does not always delete node_modules, but it re-evaluates the dependency tree and may reinstall or update packages depending on what it finds. So even here, the cache is not reliably used.

In both cases, the cached node_modules folder is either deleted outright or partially ignored.

Amplify's own documentation recommends using npm ci for builds. But npm ci by design destroys exactly what Amplify's cache tries to preserve. These two things directly contradict each other.

The cache model and the install command are working against each other.

A Simple Way to Think About It

Imagine you spend 10 minutes carefully organizing your desk every night before bed so it is ready for tomorrow. But every morning, the first thing you do is clear everything off the desk and start fresh. The organizing you did the night before is completely wasted.

That is exactly what is happening here. Amplify organizes the node_modules folder into cache. npm wipes the desk clean every build.

What the Numbers Look Like Side by Side

To make this concrete, here is a comparison of what I observed:

With cache enabled:

Restore cache: ~3 minutes
Install and build: ~3 minutes
Save cache: ~3 minutes
Total: ~9 minutes With cache disabled:
Install and build: ~3 minutes 30 seconds
Total: ~3 minutes 30 seconds The "optimized" build with cache took more than twice as long as the build with no cache at all.

What You Should Do Instead

Based on everything above, my recommendation is straightforward: disable Amplify cache unless you have a very specific reason to use it and have verified it is actually helping.

To disable it, remove or empty the cache section from your amplify.yml. Here is what a build config without cache looks like:

version: 1
frontend:
  phases:
    preBuild:
      commands:
        - npm ci
    build:
      commands:
        - npm run build
  artifacts:
    baseDirectory: build
    files:
      - '**/*'

No cache block. Clean and simple.

If your builds are still slow after removing cache, the bottleneck is likely somewhere else — large dependencies, slow build tools, or the build machine itself. Those are worth investigating separately, but at least you will not be wasting time on a cache that is not working.

My Conclusion

AWS Amplify's cache feature is built on a model that zips and unzips folders between builds. That model does not account for how npm actually works. npm ci deletes node_modules before every install. npm install may partially reinstall anyway. The result is that the cache restore step costs real time — in my case, 3 minutes per build — and delivers no actual benefit.

I tested this on a large app and a minimal app. I tried npm ci and npm install. I made sure cache folders were correctly configured and permissions were in place. In every scenario, disabling cache made builds faster.

This feels like a fundamental design mismatch between Amplify's caching mechanism and how modern package managers work.

Has This Happened to You?

I am genuinely curious whether other developers have experienced this. Have you found a way to make Amplify cache actually work? Did you measure a real improvement? Or did you hit the same wall?

Drop a comment or reach out — I would love to hear if someone has cracked this or if this is a widely shared frustration in the community.

Need Help With Your Amplify Setup?

If you are running into build time issues or anything else with your Amplify deployment, feel free to reach out. Happy to help.

Email me at khantanseer43@gmail.com

Your AWS Cognito Emails Are Going to Spam — Here Is How to Fix It Step by Step

Tanseer — Wed, 29 Apr 2026 06:28:10 +0000

A beginner-friendly guide to setting up SPF, DKIM, DMARC, Amazon SES, and custom email templates so your emails actually reach the inbox

Who This Guide Is For
If you are building an app on AWS and using Cognito to handle user sign-up and login, you have probably noticed that Cognito sends emails automatically — a verification email when someone signs up, and a password reset email when they forget their password.
But if those emails are landing in spam, or not arriving at all, this guide is for you.
We are going to fix that problem from scratch. No prior knowledge of email infrastructure is assumed. Every term will be explained.

What Is the Problem, Exactly?
When your app sends an email from something like no-reply@yourdomain.com, the email does not go directly from your laptop to the user's inbox. It travels through mail servers, and along the way, the receiving server (Gmail, Outlook, etc.) checks a simple question:
"Can I trust that this email actually came from this domain?"
If the answer is unclear or no, the email gets flagged as spam — or silently dropped.
To answer that question, three things need to be in place on your domain: SPF, DKIM, and DMARC. These are DNS records (small pieces of configuration stored on your domain) that prove your emails are legitimate.
We will set all of them up in this guide.

The Stack We Are Working With
Here is what this guide assumes:

You have an AWS account
You have a Cognito User Pool set up (or are planning to set one up)
Your domain is managed in Route 53 (AWS's DNS service)
You want Cognito to send emails from your custom domain, like no-reply@yourdomain.com

If your domain is with GoDaddy, Namecheap, or another provider, the DNS steps will look slightly different in their interface, but the records you need to add are identical.

Step 1: Understand What Amazon SES Is
Before we do anything, let us understand a key service: Amazon SES.
SES stands for Simple Email Service. It is AWS's service for sending emails. By default, Cognito uses its own basic email system, which has very low sending limits and no support for custom domains. That is why emails look generic and often end up in spam.
The fix is to connect Cognito to SES, and configure SES properly with your domain. SES is free for low volumes, and the setup is a one-time thing.

Step 2: Verify Your Domain in Amazon SES
Before SES can send emails on behalf of your domain, it needs to confirm that you actually own it. This is called domain verification.
Here is how to do it:

Log in to the AWS Console and search for "Amazon SES" in the top search bar.
In the left sidebar, click "Verified identities".
Click "Create identity".
Choose "Domain" and type your domain name (for example, mydomain.com).
If your domain is in Route 53, check the option that says "Use Route 53 to publish DNS records automatically." AWS will handle the DNS setup for you.
Click "Create identity".

If you are not using Route 53, SES will show you a CNAME record that you need to manually add in your DNS provider's dashboard. Copy it exactly as shown and add it there.
Once AWS detects the record, the status will change to "Verified". This can take anywhere from a few minutes to a couple of hours.

Step 3: Set Up DKIM
DKIM stands for DomainKeys Identified Mail. Think of it like a wax seal on a letter — it proves the email came from you and was not tampered with in transit.
Every email sent through SES gets a digital signature. The receiving server checks that signature against a public key stored in your DNS. If they match, the email is trusted.
When you verified your domain in the previous step, SES automatically generated DKIM keys for you. You just need to add the DNS records.
SES will show you three CNAME records under the "DKIM signatures" section of your verified identity. If you used Route 53 automatic publishing, these are already added. If not, copy all three and add them as CNAME records in your DNS provider.
Once AWS confirms the records are live, DKIM status will show "Verified."

Step 4: Set Up SPF
SPF stands for Sender Policy Framework. It is a DNS record that tells the world which servers are allowed to send email from your domain.
Without SPF, anyone could send an email claiming to be from your domain. Receiving servers know this, which is why they check for it.
Here is how to add it:

Go to Route 53 in the AWS Console.
Click "Hosted zones" and open your domain.
Click "Create record".
Set the record type to "TXT".
Leave the record name empty (or use @ if required).
In the value field, paste this exactly:

"v=spf1 include:amazonses.com ~all"

Click "Create records".

What this record says: emails from this domain are allowed to come from Amazon SES servers. The ~all at the end means "treat anything else with suspicion but do not block it outright." This is the safe starting point.

Step 5: Set Up DMARC
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is the policy that ties SPF and DKIM together.
DMARC tells receiving servers: "Here is what to do if my emails fail the SPF or DKIM check." Without DMARC, servers make their own decisions, and those decisions often mean spam folder.
Here is how to add it:

In Route 53, go to your hosted zone again.
Create another TXT record.
Set the record name to _dmarc (Route 53 will automatically append your domain, making it _dmarc.yourdomain.com).
In the value field, paste this:

"v=DMARC1; p=quarantine; rua=mailto:youremail@yourdomain.com"

Replace the email address with one you actually check.
Click "Create records".

What each part means:

v=DMARC1 — this is a DMARC record
p=quarantine — if authentication fails, send the email to spam (safer than p=reject when you are just starting, which would block emails entirely)
rua=mailto:... — where AWS should send weekly reports about your email activity

Once you are confident your setup is working correctly, you can upgrade to p=reject to fully block unauthenticated emails.

Step 6: Exit the SES Sandbox
Every new AWS account starts in something called the SES sandbox. In sandbox mode, you can only send emails to addresses you have manually verified. This is a security measure AWS uses to prevent spam from new accounts.
The problem is, your real users have not verified their emails with AWS. So if you are still in sandbox mode, your emails will fail silently.
To exit the sandbox:

Go to Amazon SES in the AWS Console.
Click "Account dashboard" in the left sidebar.
Under "Sending limits", you will see a message about sandbox mode. Click "Request production access".
Fill in the short form. Select "Transactional" as the mail type (since you are sending verification and password reset emails, not marketing).
Describe your use case clearly: something like "Sending user verification and password reset emails for a web application."
Submit the request.

AWS typically approves this within a few hours to one business day. You will get an email confirmation once approved.

Step 7: Connect Cognito to SES
Now that SES is properly configured, you need to tell Cognito to use it instead of its default email system.

Go to the AWS Console and open "Amazon Cognito".
Click on your User Pool.
Go to the "Messaging" tab.
Under "Email", click "Edit".
Change the "Email provider" from "Send email with Cognito" to "Send email with Amazon SES".
Under "SES Region", choose the same region where you set up your SES identity.
Under "FROM email address", enter no-reply@yourdomain.com (or whatever address you want to send from, as long as the domain is verified in SES).
Optionally, set a "FROM sender name" like "MyApp Support". This is what appears as the sender name in the user's inbox.
Save the changes.

From this point on, all Cognito emails — verifications and password resets — will go through your verified SES identity with proper authentication.

Step 8: Customize Your Email Templates
This step is optional but strongly recommended, especially for beginner projects. Cognito's default email messages are very generic, and a branded email builds trust with users (and also looks less like spam to mail filters).
In the same "Messaging" section of your Cognito User Pool:

Click on "Message templates".
You will see options for "Verification message" and "Password reset message".
Click edit on each one.
You can write a plain text or HTML message. Here is a simple example for the verification email:

Subject: Verify your email for MyApp

Hi,

Thank you for signing up. Please verify your email address by entering the code below in the app:

Your verification code: {####}

If you did not sign up for MyApp, you can ignore this email.

Regards,
The MyApp Team
The {####} placeholder is automatically replaced by Cognito with the actual verification code or link.
Keep the message clear, short, and professional. Avoid using words like "free", "click here", or excessive capitalization, as these can trigger spam filters even when authentication is correct.

How to Confirm Everything Is Working
After setting everything up, use a free tool called MXToolbox to verify your DNS records:

Go to MXToolbox and run an "SPF Lookup" for your domain. You should see the SES include statement in the result.
Run a "DMARC Lookup" for your domain. You should see your DMARC policy.
For DKIM, you can run a "DKIM Lookup" using the selector that SES provided.

To test the full email delivery, use Mail Tester. It gives you a temporary email address. Trigger a verification email from your Cognito signup flow to that address, then check your score. A score of 8 or higher means your setup is solid.

Quick Checklist Before You Go Live
Before launching your app to real users, confirm the following:

Domain is verified in Amazon SES
DKIM records (3 CNAMEs) are added and verified
SPF TXT record is added to your domain
DMARC TXT record is added to _dmarc.yourdomain.com
SES sandbox mode has been exited (production access approved)
Cognito is configured to use SES as the email provider
Custom email templates are set up with a clear sender name and message

Conclusion
Email deliverability is one of those things that most developers only think about after something breaks. Verification emails going to spam, users not completing sign-up, support tickets about missing password reset emails — these are all symptoms of the same root cause: an unauthenticated domain.
The good news is that fixing it is straightforward. SPF, DKIM, and DMARC are one-time DNS configurations. Connecting Cognito to SES takes less than ten minutes. And once it is done, your emails will reliably reach inboxes.
If you are building something on AWS and handling user authentication, getting this right early will save you a lot of headaches later.

Need Help?
If you run into any issues with the setup — whether it is a DNS record that does not verify, SES sandbox approval, or connecting things in Cognito — feel free to reach out. I am happy to walk you through it.
Email me at khantanseer43@gmail.com

Hey everyone! Just published a blog on a problem I ran into recently. If you are using AWS Cognito for auth and your verification or password reset emails are going to spam, this one is for you.

Tanseer — Tue, 28 Apr 2026 04:50:04 +0000

Tanseer

Apr 28

Your AWS Cognito Emails Are Going to Spam — Here Is How to Fix It Step by Step

#aws #serverless

Comments

8 min read

Your AWS Cognito Emails Are Going to Spam — Here Is How to Fix It Step by Step

Tanseer — Tue, 28 Apr 2026 04:31:04 +0000

A beginner-friendly guide to setting up SPF, DKIM, DMARC, Amazon SES, and custom email templates so your emails actually reach the inbox

Who This Guide Is For

If you are building an app on AWS and using Cognito to handle user sign-up and login, you have probably noticed that Cognito sends emails automatically — a verification email when someone signs up, and a password reset email when they forget their password.

But if those emails are landing in spam, or not arriving at all, this guide is for you.

We are going to fix that problem from scratch. No prior knowledge of email infrastructure is assumed. Every term will be explained.

What Is the Problem, Exactly?

When your app sends an email from something like no-reply@yourdomain.com, the email does not go directly from your laptop to the user's inbox. It travels through mail servers, and along the way, the receiving server (Gmail, Outlook, etc.) checks a simple question:

"Can I trust that this email actually came from this domain?"

If the answer is unclear or no, the email gets flagged as spam — or silently dropped.

To answer that question, three things need to be in place on your domain: SPF, DKIM, and DMARC. These are DNS records (small pieces of configuration stored on your domain) that prove your emails are legitimate.

We will set all of them up in this guide.

The Stack We Are Working With

Here is what this guide assumes:

You have an AWS account
You have a Cognito User Pool set up (or are planning to set one up)
Your domain is managed in Route 53 (AWS's DNS service)
You want Cognito to send emails from your custom domain, like no-reply@yourdomain.com

If your domain is with GoDaddy, Namecheap, or another provider, the DNS steps will look slightly different in their interface, but the records you need to add are identical.

Step 1: Understand What Amazon SES Is

Before we do anything, let us understand a key service: Amazon SES.

SES stands for Simple Email Service. It is AWS's service for sending emails. By default, Cognito uses its own basic email system, which has very low sending limits and no support for custom domains. That is why emails look generic and often end up in spam.

The fix is to connect Cognito to SES, and configure SES properly with your domain. SES is free for low volumes, and the setup is a one-time thing.

Step 2: Verify Your Domain in Amazon SES

Before SES can send emails on behalf of your domain, it needs to confirm that you actually own it. This is called domain verification.

Here is how to do it:

Log in to the AWS Console and search for "Amazon SES" in the top search bar.
In the left sidebar, click "Verified identities".
Click "Create identity".
Choose "Domain" and type your domain name (for example, mydomain.com).
If your domain is in Route 53, check the option that says "Use Route 53 to publish DNS records automatically." AWS will handle the DNS setup for you.
Click "Create identity".

If you are not using Route 53, SES will show you a CNAME record that you need to manually add in your DNS provider's dashboard. Copy it exactly as shown and add it there.

Once AWS detects the record, the status will change to "Verified". This can take anywhere from a few minutes to a couple of hours.

Step 3: Set Up DKIM

DKIM stands for DomainKeys Identified Mail. Think of it like a wax seal on a letter — it proves the email came from you and was not tampered with in transit.

Every email sent through SES gets a digital signature. The receiving server checks that signature against a public key stored in your DNS. If they match, the email is trusted.

When you verified your domain in the previous step, SES automatically generated DKIM keys for you. You just need to add the DNS records.

SES will show you three CNAME records under the "DKIM signatures" section of your verified identity. If you used Route 53 automatic publishing, these are already added. If not, copy all three and add them as CNAME records in your DNS provider.

Once AWS confirms the records are live, DKIM status will show "Verified."

Step 4: Set Up SPF

SPF stands for Sender Policy Framework. It is a DNS record that tells the world which servers are allowed to send email from your domain.

Without SPF, anyone could send an email claiming to be from your domain. Receiving servers know this, which is why they check for it.

Here is how to add it:

Go to Route 53 in the AWS Console.
Click "Hosted zones" and open your domain.
Click "Create record".
Set the record type to "TXT".
Leave the record name empty (or use @ if required).
In the value field, paste this exactly:

"v=spf1 include:amazonses.com ~all"

Click "Create records".

What this record says: emails from this domain are allowed to come from Amazon SES servers. The ~all at the end means "treat anything else with suspicion but do not block it outright." This is the safe starting point.

Step 5: Set Up DMARC

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is the policy that ties SPF and DKIM together.

DMARC tells receiving servers: "Here is what to do if my emails fail the SPF or DKIM check." Without DMARC, servers make their own decisions, and those decisions often mean spam folder.

Here is how to add it:

In Route 53, go to your hosted zone again.
Create another TXT record.
Set the record name to _dmarc (Route 53 will automatically append your domain, making it _dmarc.yourdomain.com).
In the value field, paste this:

"v=DMARC1; p=quarantine; rua=mailto:youremail@yourdomain.com"

Replace the email address with one you actually check.
Click "Create records".

What each part means:

v=DMARC1 — this is a DMARC record
p=quarantine — if authentication fails, send the email to spam (safer than p=reject when you are just starting, which would block emails entirely)
rua=mailto:... — where AWS should send weekly reports about your email activity

Once you are confident your setup is working correctly, you can upgrade to p=reject to fully block unauthenticated emails.

Step 6: Exit the SES Sandbox

Every new AWS account starts in something called the SES sandbox. In sandbox mode, you can only send emails to addresses you have manually verified. This is a security measure AWS uses to prevent spam from new accounts.

The problem is, your real users have not verified their emails with AWS. So if you are still in sandbox mode, your emails will fail silently.

To exit the sandbox:

Go to Amazon SES in the AWS Console.
Click "Account dashboard" in the left sidebar.
Under "Sending limits", you will see a message about sandbox mode. Click "Request production access".
Fill in the short form. Select "Transactional" as the mail type (since you are sending verification and password reset emails, not marketing).
Describe your use case clearly: something like "Sending user verification and password reset emails for a web application."
Submit the request.

AWS typically approves this within a few hours to one business day. You will get an email confirmation once approved.

Step 7: Connect Cognito to SES

Now that SES is properly configured, you need to tell Cognito to use it instead of its default email system.

Go to the AWS Console and open "Amazon Cognito".
Click on your User Pool.
Go to the "Messaging" tab.
Under "Email", click "Edit".
Change the "Email provider" from "Send email with Cognito" to "Send email with Amazon SES".
Under "SES Region", choose the same region where you set up your SES identity.
Under "FROM email address", enter no-reply@yourdomain.com (or whatever address you want to send from, as long as the domain is verified in SES).
Optionally, set a "FROM sender name" like "MyApp Support". This is what appears as the sender name in the user's inbox.
Save the changes.

From this point on, all Cognito emails — verifications and password resets — will go through your verified SES identity with proper authentication.

Step 8: Customize Your Email Templates

This step is optional but strongly recommended, especially for beginner projects. Cognito's default email messages are very generic, and a branded email builds trust with users (and also looks less like spam to mail filters).

In the same "Messaging" section of your Cognito User Pool:

Click on "Message templates".
You will see options for "Verification message" and "Password reset message".
Click edit on each one.
You can write a plain text or HTML message. Here is a simple example for the verification email:

Subject: Verify your email for MyApp

Hi,

Thank you for signing up. Please verify your email address by entering the code below in the app:

Your verification code: {####}

If you did not sign up for MyApp, you can ignore this email.

Regards,
The MyApp Team

The {####} placeholder is automatically replaced by Cognito with the actual verification code or link.

Keep the message clear, short, and professional. Avoid using words like "free", "click here", or excessive capitalization, as these can trigger spam filters even when authentication is correct.

How to Confirm Everything Is Working

After setting everything up, use a free tool called MXToolbox to verify your DNS records:

Go to MXToolbox and run an "SPF Lookup" for your domain. You should see the SES include statement in the result.
Run a "DMARC Lookup" for your domain. You should see your DMARC policy.
For DKIM, you can run a "DKIM Lookup" using the selector that SES provided.

Quick Checklist Before You Go Live

Before launching your app to real users, confirm the following:

Domain is verified in Amazon SES
DKIM records (3 CNAMEs) are added and verified
SPF TXT record is added to your domain
DMARC TXT record is added to _dmarc.yourdomain.com
SES sandbox mode has been exited (production access approved)
Cognito is configured to use SES as the email provider
Custom email templates are set up with a clear sender name and message

Conclusion

Email deliverability is one of those things that most developers only think about after something breaks. Verification emails going to spam, users not completing sign-up, support tickets about missing password reset emails — these are all symptoms of the same root cause: an unauthenticated domain.

The good news is that fixing it is straightforward. SPF, DKIM, and DMARC are one-time DNS configurations. Connecting Cognito to SES takes less than ten minutes. And once it is done, your emails will reliably reach inboxes.

If you are building something on AWS and handling user authentication, getting this right early will save you a lot of headaches later.

Need Help?

If you run into any issues with the setup — whether it is a DNS record that does not verify, SES sandbox approval, or connecting things in Cognito — feel free to reach out. I am happy to walk you through it.

Email me at khantanseer43@gmail.com

AWS #AmazonSES #Cognito #EmailDeliverability #SPF #DKIM #DMARC #Route53 #Serverless #AWSCommunity #CloudComputing #BackendDevelopment #AWSBuilder #EmailAuthentication #LearnAWS #WebDevelopment