DEV Community: Tanseer

Who Wins the Variable Fight in Terraform?

Tanseer — Wed, 24 Jun 2026 11:02:27 +0000

A beginner friendly guide to understanding which value Terraform actually picks when the same variable is set in many places

Introduction

When you start writing Terraform, you quickly learn that you can set the same variable in many different ways. You can give it a default value, you can put it in a file, you can pass it on the command line, and you can even set it through your computer's environment.

This is great for flexibility, but it also raises a confusing question. If the same variable gets a value from five different places, which value does Terraform actually use?

This is called variable precedence. Precedence simply means the order of priority. It is the set of rules Terraform follows to decide who wins when there is a conflict.

In this post we will walk through every way you can set a variable, then look at the exact order Terraform uses to pick a winner. We will use small, repeatable examples so you can try each one yourself.

Quick note on the words we will use. A variable is just a named value you can reuse, like a name tag on a box. A value is what is inside that box. Precedence is the priority order Terraform uses when two boxes have the same name tag but different contents.

First, the ways you can set a variable

Before we talk about who wins, let us list all the players in the game. There are six common ways to give a variable a value in Terraform.

The first is a default value. You write this directly inside the variable block in your code.

variable "region" {
  type    = string
  default = "us-east-1"
}

The second is an environment variable. An environment variable is a value stored in your computer's shell, outside of Terraform. Terraform reads any environment variable that starts with TF_VAR_ followed by the variable name.

export TF_VAR_region="us-west-2"

The third is a file called terraform.tfvars. A tfvars file is a plain file where you list variable names and the values you want to give them. Terraform loads this file automatically without you doing anything.

region = "ap-south-1"

The fourth is a file called terraform.tfvars.json. This is the same idea as above, but written in JSON format instead. JSON is just another way of writing structured data using curly braces and quotes.

{
  "region": "eu-west-1"
}

The fifth is any file ending in .auto.tfvars or .auto.tfvars.json. The word auto here means automatic. Terraform loads these files for you automatically too, just like the standard tfvars file. A common example name is prod.auto.tfvars.

region = "ca-central-1"

The sixth is a command line flag. A flag is an extra instruction you type when running a command. You can pass a value directly with -var, or point to a specific file with -var-file.

terraform apply -var="region=sa-east-1"

The order that decides the winner

Here is the part everyone wants to know. Terraform checks these sources in a fixed order, from lowest priority to highest priority. A source that comes later in the list overrides anything set earlier.

Here is the order from weakest to strongest.

The default value inside the variable block. This is the fallback that is used only when nothing else provides a value.
Environment variables that start with TF_VAR_.
The terraform.tfvars file.
The terraform.tfvars.json file.
Any files ending in .auto.tfvars or .auto.tfvars.json, loaded in alphabetical order of their file names.
The -var and -var-file flags on the command line, applied in the exact order you type them. The simplest way to remember this is that the command line always wins, and the default value always loses. Everything else sits in the middle.

A full example you can run

Let us prove the rules with a tiny project. Create a folder and add the following files.

First the variable declaration in a file called variables.tf.

variable "region" {
  type    = string
  default = "us-east-1"
}

Next a file called main.tf that just prints the value back to us using an output. An output is simply a way for Terraform to show you a value after it runs.

output "selected_region" {
  value = var.region
}

Now run this command to see the result.

terraform apply

At this point only the default exists, so Terraform will show us-east-1. The default wins because nobody else is competing.

Now add a file called terraform.tfvars with this line.

region = "ap-south-1"

Run apply again. This time Terraform shows ap-south-1. The tfvars file beat the default because it has higher priority.

Now add a file called prod.auto.tfvars with this line.

region = "ca-central-1"

Run apply once more. Now the answer becomes ca-central-1. The auto tfvars file sits higher than the standard tfvars file, so it takes over.

Finally, run apply with a command line flag.

terraform apply -var="region=sa-east-1"

The result is now sa-east-1. The command line beats every file, so it has the final say.

What happens with two auto tfvars files

A common question is what happens when you have more than one auto tfvars file and both set the same variable. The answer is alphabetical order.

Imagine you have two files named a.auto.tfvars and b.auto.tfvars, and both set the region. Terraform loads a.auto.tfvars first and b.auto.tfvars second. Because the later one overrides the earlier one, the value inside b.auto.tfvars wins.

So the file whose name comes later in the alphabet has the higher priority. This is easy to forget, so name your files carefully if order matters to you.

Command line order also matters

There is one more detail worth knowing. When you pass several flags on the command line, Terraform applies them left to right, and the rightmost one wins.

terraform apply -var="region=us-east-1" -var="region=us-west-2"

In this case the final value is us-west-2, because it appears last. The same rule applies when you mix -var and -var-file. Whatever comes last on the line takes priority.

A quick warning about missing values

If a variable has no default and you never give it a value through any source, Terraform will stop and ask you to type the value in. This is a safety feature so you never accidentally run with a blank value.

If you want a variable to be optional, give it a sensible default. If you want it to be required on purpose, leave the default out so Terraform forces someone to provide it.

Conclusion

Variable precedence in Terraform looks confusing at first, but it follows one calm and predictable rule. Lower priority sources set the value, and higher priority sources override it.

The order, from weakest to strongest, is the default value, then environment variables, then the standard tfvars file, then the JSON tfvars file, then the auto tfvars files in alphabetical order, and finally the command line flags which always win.

Once this clicks, you gain real control over your setup. You can keep safe defaults in your code, store normal settings in tfvars files, and override anything on the fly from the command line when you need to. That is the whole point of precedence, giving you layers you can trust.

Try the small example above and watch the value change with each step. Seeing it happen is the fastest way to make this stick.

Get in touch

If you have questions or want me to cover another Terraform topic, reach out at khantanseer43@gmail.com. I am always happy to help fellow builders.

The Bucket That Must Exist Before Everything Else

Tanseer — Tue, 23 Jun 2026 10:31:31 +0000

How I created a dedicated S3 bucket to hold my Terraform remote backend, and every small lesson I learned along the way

Introduction

When you start working with Terraform, one of the first real puzzles you hit is a classic chicken and egg situation.

Terraform needs a safe place to store its state file. The state file is a record of everything Terraform has created for you, like a memory of your infrastructure. The most common safe place to keep this file is an S3 bucket on AWS. S3 stands for Simple Storage Service, and a bucket is just a container where you store files in the cloud.

Here is the puzzle. Terraform wants to store its state in an S3 bucket, but that bucket does not exist yet. So how do you create the very bucket that Terraform itself needs in order to remember what it created?

The answer is a small, separate Terraform setup called a bootstrap. You run it once, it creates the bucket, and then you never touch it again. In this post I will walk you through exactly how I built mine for my project, and I will explain every piece of jargon the first time it shows up. This is written for developers who are new to AWS, so nothing here assumes prior cloud knowledge.

What a Bootstrap Actually Is

A bootstrap is a tiny Terraform project whose only job is to create the foundation that the main project depends on. In our case the foundation is a single S3 bucket that will store the remote backend.

A backend is simply where Terraform keeps its state. A local backend keeps the state on your own computer. A remote backend keeps the state in the cloud, which is much safer and lets a whole team share it. We want a remote backend, and to have a remote backend we first need the bucket to hold it.

The golden rule of a bootstrap is this. Run it once, before anything else, then leave it alone forever.

The Folder Structure

I kept the bootstrap deliberately small. Here is the entire layout.

bootstrap/
├── main.tf        # everything in one file
├── variables.tf
└── README.md

That is it. Three files. A lot of beginners expect more files because larger Terraform projects have many. But a bootstrap is special, and the missing files are missing on purpose. Let me explain why, because the reasoning here taught me a lot.

Why there is no backend.tf

A file called backend.tf is where you would normally tell Terraform to use a remote backend. We do not have one here, and that is intentional. The bucket does not exist yet, so we cannot point Terraform at it. Instead the bootstrap uses local state, meaning the state file sits on our machine for now. This is the one time local state is the correct choice.

Why there is no outputs.tf

An output in Terraform is a value you ask Terraform to print or pass along after it runs, like the name of something it just created. You might think we need to output the bucket name so the main project can read it. We do not. The bucket name is already known from our variables, and the backend.tf file in the main project is static. Static means it is fixed text that cannot read or react to outputs. So an output here would serve no purpose.

Why there is no providers.tf

A provider is the plugin that lets Terraform talk to a specific cloud, in this case AWS. In big projects people split the provider setup into its own providers.tf file for tidiness. Our bootstrap is so small that everything fits comfortably in main.tf, so there is no need to split it.

The Order of Blocks Inside main.tf

Inside main.tf the order of things matters for readability. I followed this order from top to bottom.

terraform block → provider block → data source → resources

The terraform block holds settings about Terraform itself, such as which version to use. The provider block configures AWS. A data source reads information that already exists rather than creating anything new. Resources are the things Terraform actually creates for you.

The Four Resources, and Nothing More

The bootstrap creates exactly four resources. Each one has a clear reason to exist.

The first is aws_s3_bucket. This is the bucket itself. I named it this in the code, which is a common Terraform convention when there is only one of something.

The second is aws_s3_bucket_versioning. Versioning means S3 keeps old copies of a file whenever it changes. This matters a lot for a state file. If the state ever gets corrupted, versioning lets you roll back to a healthy earlier copy. It is your safety net.

The third is aws_s3_bucket_public_access_block. This shuts the bucket off from the public internet. It has four separate arguments, and I set all four to true. The reason I did this explicitly, rather than trusting AWS to do it for me, leads to one of the biggest lessons in this whole project, which I will come back to shortly.

The fourth is aws_s3_bucket_server_side_encryption_configuration. Encryption scrambles the stored data so that only authorized access can read it. I chose AES256, which is a strong and standard encryption method. Again I set this explicitly rather than relying on any default.

Here is the complete main.tf so you can see how all four resources fit together with the terraform block, the provider, and the data source.

# Add AWS Provider
terraform {
  required_version = "~> 1.15.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

# Configure the AWS Provider
provider "aws" {
  region = var.region
}

# AWS account id
data "aws_caller_identity" "current" {}

# Create s3 bucket
resource "aws_s3_bucket" "this" {
  bucket = "${var.project}-statefile-${data.aws_caller_identity.current.account_id}"
}

# Versioning bucket
resource "aws_s3_bucket_versioning" "this" {
  bucket = aws_s3_bucket.this.id
  versioning_configuration {
    status = "Enabled"
  }
}

# Block public access
resource "aws_s3_bucket_public_access_block" "this" {
  bucket = aws_s3_bucket.this.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# Encryption
resource "aws_s3_bucket_server_side_encryption_configuration" "this" {
  bucket = aws_s3_bucket.this.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

Notice the small detail inside each resource. The line bucket = aws_s3_bucket.this.id is how Terraform links resources together. It tells the versioning, public access, and encryption resources to attach themselves to the exact bucket we just created, rather than to some other bucket. This linking is how Terraform understands the order to build things in.

Reference image placeholder: a screenshot of the four resources listed in main.tf.

The Variables File

A variable is a named value you can reuse and change in one place. Here is the full variables.tf.

variable "region" {
  type        = string
  description = "AWS region where the statefile must exists"
  default     = "ap-south-1"
}

variable "project" {
  type        = string
  description = "Name of the project"
  default     = "todo-app"
}

The first variable is region. A region is the geographic location of your AWS data center. Mine is a string with a default of ap-south-1, which is the Mumbai region. A string simply means text.

The second variable is project. This is the name of the project, with a default of todo-app. A nice improvement you can add later is validation, which is a rule Terraform checks before running. A validation rule could force the name to use lowercase letters and hyphens only, which keeps bucket names clean and valid. I left it simple here, but it is worth knowing the option exists.

Notice what is missing. There is no account_id variable. Your account ID is the unique number that identifies your AWS account. Instead of typing it in by hand as a variable, where you could easily make a mistake, I read it automatically using a data source called data "aws_caller_identity". This always returns the correct account, so it can never be wrong.

How the Bucket Gets Its Name

S3 bucket names must be unique across all of AWS, not just within your account. So I built the name out of pieces that are guaranteed to be unique together.

${var.project}-statefile-${data.aws_caller_identity.current.account_id}

This combines the project name, the word statefile, and the account ID. Because the account ID is unique to me, the resulting name will not clash with anyone else.

One choice worth pointing out. I did not put the environment, such as dev or prod, into the name. One bucket serves all environments. This keeps things simple, and the different environments are separated inside the bucket by their file paths instead.

Version Constraints, and Why the Tiny Symbols Matter

In the terraform block I pinned the Terraform version like this.

required_version = "~> 1.15.0"

The little ~> symbol is called the pessimistic constraint operator. It controls how much Terraform is allowed to upgrade itself automatically. The exact form you write changes the meaning in a way that is easy to miss.

Writing ~> 1.15.0 allows only patch releases, meaning small bug fix updates like 1.15.1 or 1.15.2, but not 1.16.

Writing ~> 1.15 would also allow minor versions, meaning larger feature updates like 1.16 or 1.17.

These are very different. Patch only is cautious and safe. Minor allowed is more relaxed. The point is to pick one consciously rather than copying a symbol without understanding it.

A Small Rule About String Interpolation

Interpolation is the way Terraform inserts a variable value into a piece of text, using the ${...} syntax. There is a simple rule I learned to keep code clean.

Use the wrapped form "${var.region}" only when you are combining the variable with other text, like inside the bucket name above.

Use the plain form var.region when you are referring to a single variable on its own, with no surrounding text.

Wrapping a lone variable in ${...} for no reason just adds clutter, so I stopped doing it.

Problems I Hit, and What They Taught Me

This is the part I find most valuable, because every one of these came from getting something wrong first.

I tried to use a data source as the default value for a variable. This does not work. A default must be a static literal, meaning a fixed value typed directly in, not something that has to be looked up while Terraform runs.

I learned the account_id must be treated as a string, not a number. Account IDs can begin with a zero, and numbers drop leading zeros, which would silently break the value. Storing it as text keeps it intact.

I confirmed that backend.tf is static and is read during the init phase, which is the very first setup step when you run Terraform. Because it runs so early, it cannot use variables or outputs at all. That is exactly why the bootstrap uses local state instead.

I learned that providers.tf is also static and read at the same early init phase, for the same reason.

I learned never to rely on AWS defaults for security. AWS settings can change over time, and assuming a default protects you is risky. I now set encryption and public access blocking explicitly every single time, so the protection is written down and guaranteed.

And one more lesson that applies to everything, including advice from me. Always verify information. At one point I had a wrong belief about which Terraform version existed, and checking it directly set me straight. Trust, but confirm.

Git Rules

Git is the tool that tracks changes to your code. When using it, some files should be saved and shared, while others must never leave your machine because they contain secrets or local state. Here is how I split them.

# commit
*.tf
.terraform.lock.hcl
*.tfvars.example

# ignore
.terraform/
*.tfstate
*.tfstate.backup
*.tfvars

The files under commit are safe to share. The lock file pins the exact provider versions so everyone uses the same ones. The example file shows the shape of variable values without revealing real ones.

The files under ignore must stay private. The state files describe your live infrastructure and can hold sensitive details. The .tfvars files often contain real secret values. The .terraform folder is just local cache that does not belong in version control.

The Run Order

Finally, here is the exact order to run everything. The bootstrap goes first, the main project follows.

cd bootstrap → terraform init → terraform apply
cd environments/dev → terraform init → terraform apply

The command terraform init prepares the working folder and downloads what Terraform needs. The command terraform apply actually builds the resources. You run them in the bootstrap folder once to create the bucket, then move into your real environment and run them again to build the rest of your infrastructure, now safely backed by the remote state bucket you just made.

Reference image placeholder: a terminal screenshot showing terraform apply finishing successfully in the bootstrap folder.

Conclusion

The bootstrap is small, but it solves a real problem that confuses almost everyone at the start. You cannot store Terraform state in a bucket that does not exist, so you build that bucket once with a tiny standalone setup that uses local state, and then you never look back.

Along the way I learned that the missing files in a bootstrap are missing on purpose, that security should always be explicit rather than assumed, that tiny version symbols carry real meaning, and that even confident advice should be checked. None of these are hard once you see the reasoning, and together they make your foundation solid.

If you are new to AWS and Terraform, I hope walking through my journey makes your own first bootstrap far less mysterious than mine was.

Contact

If you have questions or want to share your own setup, feel free to reach out at khantanseer43@gmail.com.

Stop Hardcoding Passwords: A Beginner's Guide to AWS Secrets Manager

Tanseer — Tue, 23 Jun 2026 05:26:44 +0000

How to keep your database passwords and API keys safe, and why rotating them doesn't break your app the way you think it will

If you are new to AWS, there is a good chance you have done something like this at least once. You needed your app to connect to a database, so you took the database password and pasted it straight into your code, or into a Lambda environment variable, and moved on. It worked, so why worry?

The problem is that a password sitting in plain view is a password waiting to leak. In this tutorial we will walk through AWS Secrets Manager, a service built to store exactly these kinds of sensitive values safely. We will cover what it is, why environment variables are a weak place to keep secrets, what a KMS key actually does, and the one topic that confuses almost every beginner: automatic rotation. By the end you will understand why rotation does not break your application, even though it changes your password while the app is running.

Let us start from the beginning.

Jargon check before we go further: a secret just means any sensitive string your app needs but should never be public. Think database passwords, API keys, and access tokens. An API key is a long secret string that proves your app is allowed to use some service. A token is similar, usually a temporary one.

What Is AWS Secrets Manager?

AWS Secrets Manager is an encrypted vault for your secrets. Instead of writing your database password directly into your code, you store it inside Secrets Manager, and your app asks for it at runtime (meaning while the app is actually running, not while you are writing it).

A simple way to picture it is a hotel room safe. You do not tape your passport to the wall. You lock it in the safe, and only someone with the right key can open it. The hotel also keeps a log of every time the safe is opened. Secrets Manager works the same way.

It gives you three main benefits.

The first is encryption at rest. "At rest" means while the data is sitting in storage, as opposed to while it is travelling over the network. Your secret is scrambled so that even someone who somehow gets to the raw storage cannot read it.

The second is IAM controlled access. IAM stands for Identity and Access Management, which is the AWS system that decides who is allowed to do what. With Secrets Manager you can say "only my application is allowed to read this database password" and nothing else can touch it.

The third is automatic rotation, which means AWS can change your password on a schedule for you. This is the feature we will spend the most time on, because it is the most useful and the most misunderstood.

Why Not Just Use a Lambda Environment Variable?

An environment variable is a setting you attach to your app from the outside, so the value lives next to the app rather than inside your code. In AWS Lambda (the service that runs your backend code without you managing a server) you can set these in the function configuration. It works, and plenty of people do it. So what is wrong with it for secrets?

There are four real problems.

First, the value sits in plain text inside your function configuration. Anyone who can open the AWS console and view your Lambda can simply read the password. There is no lock on it.

Second, the value tends to leak into places you did not expect. If you manage your infrastructure with a tool like Terraform, the password ends up written into your Terraform state file, which is the record Terraform keeps of everything it created. It can also show up in deployment logs. So one password quietly becomes several copies scattered around.

Third, changing the value means redeploying or updating the function. There is no clean way to swap it on the fly.

Fourth, there is no audit trail. You cannot answer the question "who read this secret and when," because nothing was recorded.

Environment variables are perfectly fine for values that are not sensitive, like which region your app runs in or a feature toggle. They are just a weak place to keep real secrets.

What Is a KMS Key?

When we said Secrets Manager encrypts your data, something has to do the actual encrypting. That something is a KMS key.

KMS stands for Key Management Service. A KMS key is the cryptographic key used to scramble (encrypt) and unscramble (decrypt) your secret. Encryption is just the process of turning readable text into unreadable text so that only someone with the key can read it again.

Here is the clever part. You never see or hold the raw key yourself. It lives inside tamper resistant hardware, meaning special equipment built so the key cannot be copied out or stolen. You simply ask KMS "please decrypt this for me," and KMS checks your IAM permission before doing it.

Think of KMS as the master key to a building, locked inside a vault that you personally cannot open. You do not get to carry the master key around. Instead you hand your locked box to the security desk and say "open this please," and they check your badge first. Because the key never leaves the vault, nobody can walk off with it.

When Secrets Manager stores your password, it quietly uses a KMS key to encrypt it. AWS gives you a default key for free, so as a beginner you usually do not need to create your own.

Automatic Rotation: The Part Everyone Misunderstands

Rotation means automatically changing a password to a new one on a schedule. Here is the worry almost every beginner has, and it is a reasonable one:

"If Secrets Manager changes my password, but my database still has the old one, won't my app stop being able to connect?"

The answer is no, and understanding why is the heart of this whole topic.

Rotation does not change the password in only one place. It changes it in both the database and the secret, as a single coordinated operation. Here is the exact sequence the rotation process runs.

It generates a brand new random password.
It connects to the database using the current password (which still works at this point) and runs the command ALTER USER, which is the SQL instruction that sets a new password on the database account. Now the database expects the new password.
It stores that new password back into Secrets Manager as the current value.
It connects once more using the new value to confirm everything works. Because both sides are updated together, they are never out of sync in a way that locks you out.

But there is a second condition you must meet for this to stay smooth. Your app has to fetch the secret fresh from Secrets Manager at runtime, rather than holding its own permanent copy. If your code reads the current value when it needs it, then after rotation it simply reads the new value next time and carries on.

There is one trap here worth naming. To avoid asking Secrets Manager for the password on every single request (which costs a little money and adds delay), developers often cache it, meaning they keep a copy in memory for reuse. That is good practice, but if you cache the password forever and never refresh it, then after rotation your app is holding a stale password and will fail to connect. The fix is a cache with a TTL, which stands for Time To Live, a setting that tells the cache to throw the value away and fetch a fresh one after a few minutes.

So the rule is simple. Rotation does not break your app, as long as your app reads the secret fresh and does not cling to an old cached copy.

Versioning: Why the Old Password Sticks Around for a Moment

A secret in Secrets Manager does not hold just one value. It holds versions, and each version carries a label that tells you what it is for. Three labels matter.

AWSCURRENT is the value you get by default when you ask for the secret. This is the live, in use password.

AWSPREVIOUS is the value from just before the last change. Secrets Manager keeps it valid for a short window on purpose. Picture rotation happening at the exact moment a request is already in flight, meaning a request that started a split second before the change. That request may have grabbed the old value already. Keeping AWSPREVIOUS alive briefly lets that in flight request finish successfully instead of erroring out. It smooths over the handover.

AWSPENDING is the new value during rotation, after it has been created but before it has been promoted to current. It is the password in waiting.

You rarely need to think about these directly, because asking for the secret gives you AWSCURRENT automatically. But knowing the labels exist helps you understand why rotation is so smooth and why the brief overlap does not cause failures.

Cross Region Replication: A Feature for Later

By default, a secret lives in a single AWS region. A region is a geographic location where AWS runs its data centers, such as Mumbai (named ap-south-1) or Singapore.

Cross region replication keeps an automatically synced copy of your secret in other regions you choose. If you store a secret in Mumbai and replicate it to Singapore, then any change in Mumbai is copied across to the Singapore version on its own.

You would want this in two situations. One is disaster recovery, so that if an entire region has an outage, an app running in your backup region can still read the secret locally. The other is when your app runs in several regions at once and you want each one to read the secret nearby instead of reaching across the world every time.

As a beginner running a single region project, you almost certainly do not need this yet. File it away as a "when I grow into multiple regions" feature.

Conclusion

If you take away one idea from this tutorial, let it be this. Secrets stay in sync because rotation changes both sides at once, the database and the stored secret, in a single coordinated operation. And your application stays connected because it reads the current value fresh from Secrets Manager whenever it needs it, rather than holding a hardcoded copy that goes stale.

Everything else builds on that. Environment variables are weak for secrets because they sit in plain text and leak into your state files and logs. A KMS key does the encrypting behind the scenes without ever letting you touch the raw key. Versioning with AWSCURRENT and AWSPREVIOUS keeps a brief safety net so in flight requests survive a rotation. And cross region replication is there for the day you outgrow a single region.

So the next time you are tempted to paste a password into an environment variable, reach for Secrets Manager instead. Your future self, and anyone who inherits your code, will thank you.

Get in Touch

Found this helpful, or stuck on something? I would love to hear from you. Reach out at khantanseer43@gmail.com and I will do my best to help.

Terraform outputs.tf Explained: What It Is, When to Use It, and When to Skip It

Tanseer — Tue, 23 Jun 2026 04:53:47 +0000

Who This Is For

If you are learning Terraform and have come across outputs.tf in project structures or tutorials but are not fully clear on what it actually does or why it exists, this blog is for you.

We will start from the basics and build up to how outputs work across modules, what they look like in practice, and the rules around where they can and cannot be used. Every term will be explained along the way.

What Is an Output in Terraform?

When Terraform creates infrastructure, it stores everything it knows about that infrastructure in a file called the state file. The state file is Terraform's database. It tracks every resource, every attribute, every ID — everything.

But the state file is not something you read directly. It is large, it is internal, and most of the values in it are not things you care about day to day.

Outputs are a way to surface specific values from that state file — the ones you actually need. You decide what gets exposed. Everything else stays internal.

A good way to think about it:

State file = the entire database.

Outputs = a view on top of that database that exposes only what you chose to make visible.

Outputs do not add new information. They do not change what Terraform tracks. They simply choose what to surface from what already exists.

The Three Contexts Where Outputs Are Used

Outputs are not just for one purpose. They serve three distinct purposes depending on where you use them. Understanding the difference between these three will make the entire concept click.

Context 1: Passing Values Between Modules in the Same Project

This is the most common use case, and the one you will use in almost every real Terraform project.

Imagine your project has two modules: a database module and a backend module. The database module creates an RDS instance and stores credentials in AWS Secrets Manager. The backend module is a Lambda function that needs to connect to that database. To do that, it needs the ARN (unique identifier) of the secret.

But here is the problem. Module internals are private. A resource defined inside modules/database/main.tf is not visible anywhere outside that module. It is intentionally hidden. You cannot just reference it from another module directly.

This is where outputs.tf comes in. The database module uses outputs.tf to explicitly expose the values it wants to share. The backend module then receives those values as input variables.

The wiring between them happens in your environment file, for example environments/dev/main.tf. That file is the connection layer. It takes what one module exposes and passes it as input to another.

The flow looks like this:

modules/database/outputs.tf
        |
        v
environments/dev/main.tf   (the wiring layer)
        |
        v
modules/backend/variables.tf

Here is what that looks like in code:

# modules/database/outputs.tf
output "secret_arn" {
  value = aws_secretsmanager_secret.db_credentials.arn
}

output "secret_name" {
  value = aws_secretsmanager_secret.db_credentials.name
}

# environments/dev/main.tf
module "database" {
  source = "../../modules/database"
}

module "backend" {
  source     = "../../modules/backend"
  secret_arn  = module.database.secret_arn
  secret_name = module.database.secret_name
}

# modules/backend/variables.tf
variable "secret_arn" {}
variable "secret_name" {}

The database module is a black box. variables.tf is what it accepts as input. main.tf is its internal implementation. outputs.tf is what it hands back out. Nothing inside the module leaks out unless you explicitly put it in outputs.tf.

Context 2: Displaying Values in the Terminal After Apply

Outputs defined in the root module, meaning the environment folder like environments/dev, are printed to the terminal after terraform apply completes.

This is purely for you as the person running the deployment. It is a convenience feature so you do not have to go hunting through the AWS console for values you commonly need.

Good candidates for terminal outputs are things like:

The API Gateway URL your backend is reachable at.

The Amplify URL where your frontend is deployed.

The RDS endpoint for your database.

# environments/dev/outputs.tf
output "api_gateway_url" {
  value = module.backend.api_url
}

output "amplify_url" {
  value = module.frontend.app_url
}

After apply, these print cleanly to your terminal:

Outputs:

api_gateway_url = "https://abc123.execute-api.ap-south-1.amazonaws.com/dev"
amplify_url     = "https://main.abc123.amplifyapp.com"

No digging through the console. The values are right there.

Context 3: Sharing Values Across Completely Separate Terraform Projects

Sometimes infrastructure is split across multiple completely separate Terraform projects, each with their own state file. A networking team might manage VPCs in one project. An application team might manage Lambda functions in another. The application team needs the VPC ID from the networking project.

This is handled using something called terraform_remote_state. It is a data source (a way to read information from outside the current project) that reads another project's state file and exposes its outputs.

data "terraform_remote_state" "networking" {
  backend = "s3"
  config = {
    bucket = "company-tfstate"
    key    = "networking/terraform.tfstate"
    region = "ap-south-1"
  }
}

# Now you can use:
data.terraform_remote_state.networking.outputs.vpc_id

One important detail here: terraform_remote_state can only access values that were explicitly defined as outputs in the other project. It cannot reach into the raw state and pull arbitrary values. If the networking team did not put the VPC ID in their outputs.tf, you cannot get it from here.

This reinforces the same rule: outputs are the only gateway for values to leave a Terraform boundary, whether that boundary is a module or an entire separate project.

This pattern does not apply if your entire infrastructure lives in one root, which is the case for smaller projects. But it is a real and widely used pattern in team environments.

Where Outputs Cannot Be Used

This is important. Outputs work during the plan and apply phase, when Terraform is evaluating your configuration and building infrastructure. But not every file in your project is evaluated at that phase.

Two files are evaluated earlier, during the init phase, before any HCL evaluation happens:

backend.tf — This is where you configure where Terraform stores its state file, for example an S3 bucket. Terraform reads this file during terraform init, before it knows anything about your resources or variables. Everything here must be a hardcoded string. You cannot reference an output, a variable, or a local.

providers.tf — This is where you configure your cloud provider, for example the AWS region and profile. This is also read during init. Same restriction. Hardcode everything here.

Trying to use a variable or output in either of these files will cause Terraform to throw an error, and the reason is always the same: those values are not available yet at init time.

Here is a simple way to remember the two phases:

Init phase reads backend.tf and providers.tf statically. Downloads providers. Sets up the backend. No HCL logic allowed.

Plan and Apply phase evaluates everything else. Outputs, variables, locals, data sources, resource references — all of this works here.

Why You Cannot Just Skip outputs.tf and Read the State Directly

A common question when learning this is: the state file already has all the values, why do I need outputs at all?

There are two reasons.

Within a module, resources are private by design. Terraform intentionally encapsulates module internals so that modules are independent and reusable. You cannot reach into modules/database/main.tf from environments/dev/main.tf and reference a resource directly. The module must explicitly hand that value out through outputs.tf. This is the same reason functions in a programming language return values instead of letting callers read internal variables directly.

Across separate roots, terraform_remote_state only exposes outputs. There is no mechanism to read arbitrary resource attributes from another project's state file. Outputs are the only thing that crosses that boundary.

When outputs.tf Is Optional

Not every module needs an outputs.tf. The rule is straightforward.

If nothing downstream needs a value from your module, there is nothing to expose. The outputs file is optional.

A common example is a frontend module in a project. If the frontend module deploys an Amplify app and no other module needs the Amplify URL as an input, then outputs.tf in the frontend module is not needed. The URL might still be shown in the terminal via the root module's outputs, but the frontend module itself does not need to expose anything.

The question to ask before adding any output is:

Who is the consumer of this value, and how will they read it?

If the answer is nobody, the output does not belong. Adding outputs that nothing consumes is just noise in your codebase.

A Quick Reference

Here is everything in one place:

Outputs between modules: use outputs.tf in the source module, wire it in the environment's main.tf, receive it in the destination module's variables.tf.

Outputs in the terminal: define them in the root module's outputs.tf. They print after terraform apply.

Outputs across separate roots: use terraform_remote_state to read another project's outputs from its remote state file.

Outputs do not work in backend.tf or providers.tf because those are read during init before HCL evaluation.

You cannot skip outputs.tf because module internals are private and remote state only exposes outputs.

outputs.tf is optional when nothing downstream needs the module's values.

Conclusion

Outputs are one of those concepts in Terraform that seem small but are actually the backbone of how information flows through your infrastructure code. Once you understand that modules are black boxes and outputs are the only thing that leaves them, the entire system starts to make sense.

Before adding any output, always ask who the consumer is. That one question will keep your outputs intentional, your modules clean, and your project easy to follow.

Need Help?

If you are learning Terraform and have questions about project structure, modules, state management, or anything else, feel free to reach out.

Email me at khantanseer43@gmail.com

How to Add a Custom Domain to AWS Cognito Google Login (And the Errors Nobody Warns You About)

Tanseer — Tue, 02 Jun 2026 04:39:24 +0000

Who This Is For

If you are using AWS Cognito to handle user authentication in your app and you have added Google as a social login option, you may have noticed something uncomfortable. When a user clicks "Sign in with Google", the URL in the browser does not say your domain. It says something like:

https://yourapp.auth.us-east-1.amazoncognito.com

That is the default Cognito hosted UI URL. It works, but it looks like your users are leaving your app to sign in somewhere else. It does not look professional, and for security conscious users, it can feel suspicious.

The fix is to set up a custom domain so the login page shows your own URL, something like:

https://auth.yourdomain.com

This guide walks through the full setup step by step, and more importantly, it covers the three errors you will likely hit along the way.

Before You Start

Here is what you need to have in place before following this guide:

A Cognito User Pool already created with Google set up as a social identity provider. If you have not done that yet, set that up first and come back here.

A domain you own, managed in Route 53 (AWS's domain and DNS service). The subdomain you will be using for the login page, something like auth.yourdomain.com, should not be pointing anywhere yet.

Access to the Google Cloud Console where your OAuth app is configured.

Step 1: Create an ACM Certificate — But Only in us-east-1

This is the first place most developers go wrong, and it is the most confusing one because nothing in the Cognito console tells you about it until you are already stuck.

ACM stands for AWS Certificate Manager. It is the service AWS uses to create and manage SSL certificates. An SSL certificate is what makes your domain load over HTTPS (the secure version of HTTP) and shows the padlock icon in the browser.

You need to create a certificate for your custom domain, like auth.yourdomain.com. That part is straightforward. The gotcha is the region.

Even if your Cognito User Pool is in a different region, say ap-south-1 or eu-west-1, the ACM certificate must be created in us-east-1. No exceptions.

The reason is that Cognito uses CloudFront behind the scenes to serve the hosted UI. CloudFront is a global content delivery service, and it only accepts SSL certificates from the us-east-1 region. Your Cognito User Pool can be anywhere, but the certificate must always be in us-east-1.

Here is how to create it:

Go to the AWS Console and switch your region to US East (N. Virginia) which is us-east-1. You can change the region from the top right dropdown in the console.
Search for "Certificate Manager" and open ACM.
Click "Request a certificate".
Choose "Request a public certificate" and click Next.
Enter your domain name. Use the subdomain you want for login, for example auth.yourdomain.com.
Choose "DNS validation" as the validation method. This is the recommended option.
Click "Request". After requesting, ACM will give you a CNAME record that you need to add to your DNS to prove you own the domain. Go to Route 53, open your hosted zone, and add that CNAME record exactly as ACM shows it.

Once the record is in place, ACM will automatically verify it and mark the certificate as "Issued". This usually takes a few minutes but can take up to 30 minutes.

Do not move to the next step until the certificate status shows "Issued".

Step 2: Add the Custom Domain in Cognito

Now that the certificate is ready, go back to your Cognito User Pool. Make sure you are in the correct region where your User Pool lives, not us-east-1 unless that is where your pool is.

Open your User Pool in the Cognito console.
Go to the "App integration" tab.
Scroll down to "Domain" and click "Actions", then "Create custom domain".
Enter your custom domain, for example auth.yourdomain.com.
In the SSL certificate dropdown, select the ACM certificate you just created. It will only appear if the certificate is in us-east-1 and has a status of Issued.
Click "Create". After saving, Cognito will provision a CloudFront distribution for your domain. This can take anywhere from 15 to 40 minutes. You will see a CloudFront domain name appear once it is ready, something like d1234abcde.cloudfront.net. Copy this value. You will need it in the next step.

Step 3: Add the DNS Record in Route 53

This is the second place where things can go wrong.

Once Cognito gives you the CloudFront domain, you need to create a DNS record so that when someone visits auth.yourdomain.com, they are pointed to that CloudFront distribution.

The record type to use here is an Alias record, not a CNAME. Route 53 has a special Alias record type that is designed to point to AWS services like CloudFront. Using a regular CNAME at the root level of a subdomain can cause issues, so always use Alias when pointing to a CloudFront domain in Route 53.

Here is how to add it:

Open Route 53 in the AWS Console.
Go to "Hosted zones" and open your domain.
Click "Create record".
Set the record name to auth (Route 53 will append your domain automatically).
Set the record type to "A".
Toggle on "Alias".
In the "Route traffic to" dropdown, choose "Alias to CloudFront distribution".
Paste the CloudFront domain that Cognito gave you.
Click "Create records". DNS changes can take a few minutes to a few hours to fully propagate. You can check the status using a tool like MXToolbox or WhatsMyDNS by looking up your subdomain.

Step 4: Update the Redirect URI in Google Cloud Console

This is the third gotcha, and it is easy to miss because everything might look like it is working until a user actually tries to sign in with Google and gets an error.

When Google handles the OAuth login flow (OAuth is the protocol that lets users sign in with their Google account), it redirects the user back to a specific URL after they authenticate. That URL is called the redirect URI.

Before you set up the custom domain, Cognito's redirect URI was something like:

https://yourapp.auth.us-east-1.amazoncognito.com/oauth2/idpresponse

Now that you have a custom domain, the redirect URI has changed to:

https://auth.yourdomain.com/oauth2/idpresponse

Google will reject any redirect to a URI that is not explicitly listed as an authorized redirect URI in your OAuth app settings. If you do not update this, users will see a Google error page saying the redirect URI is not authorized.

Here is how to update it:

Go to the Google Cloud Console at console.cloud.google.com.
Open your project and navigate to "APIs and Services", then "Credentials".
Click on the OAuth 2.0 Client ID you created for Cognito.
Under "Authorized redirect URIs", click "Add URI".
Add your new redirect URI: https://auth.yourdomain.com/oauth2/idpresponse
Also update "Authorized JavaScript origins" if it was set to the old Cognito domain. Add https://auth.yourdomain.com.
Click "Save". You do not need to remove the old Cognito URI right away. Keep both for now while you test the new setup, and remove the old one once everything is confirmed working.

Step 5: Test the Full Flow

Once all the above steps are done and DNS has propagated, test the complete sign in flow from your app.

Open your app and trigger the Google login. The URL in the browser should now show auth.yourdomain.com instead of the Cognito domain. The user should be able to complete the Google sign in and land back in your app without any errors.

If you see a Google error about redirect URI mismatch, double check Step 4. If you see an SSL error, double check that the ACM certificate is in us-east-1 and is fully issued. If the DNS is not resolving, give it more time or check your Route 53 record.

Quick Summary of the Three Errors to Avoid

The ACM certificate must be in us-east-1 no matter what region your Cognito User Pool is in. Creating it in the wrong region means it will not appear in the Cognito domain setup and you will waste time wondering why.

The DNS record in Route 53 should be an Alias A record pointing to the CloudFront domain, not a plain CNAME. Using the wrong record type can cause resolution issues.

The redirect URI in Google Cloud Console must be updated to the new custom domain. Forgetting this means Google will block the login flow and your users will see an error.

Conclusion

Adding a custom domain to your Cognito login page is a small change that makes a big difference in how professional and trustworthy your app feels. The steps themselves are not complicated, but the three gotchas around the ACM region, DNS record type, and Google redirect URI are not obvious and not well documented in one place.

If you follow this guide in order and do not skip steps, you should have your custom domain up and running without the frustration of debugging silent failures.

Need Help?

If you are stuck at any of these steps or running into an error not covered here, feel free to reach out. Happy to help.

Email me at khantanseer43@gmail.com

Lambda Execution Roles Are Quietly Breaking Your Least Privilege Policy

Tanseer — Thu, 21 May 2026 05:26:38 +0000

Who This Is For

If you are using AWS Lambda to build serverless applications and you have never stopped to look closely at the IAM roles attached to your functions, this blog is for you.

We are going to talk about what a Lambda execution role is, why the way most people set them up creates a security problem, and exactly what you should do instead. Every term will be explained along the way.

A Quick Refresher: What Is an Execution Role?

When a Lambda function runs, it needs permission to interact with other AWS services. For example, if your function reads data from a database or writes a file to S3 (AWS's file storage service), AWS needs to know whether your function is allowed to do that.

This permission is controlled by something called an IAM execution role. IAM stands for Identity and Access Management. It is the system AWS uses to control who or what can access which resources.

Every Lambda function has an execution role attached to it. When the function runs, it automatically assumes that role and gets whatever permissions the role has. Think of it like a staff ID card. The card determines which rooms in the building you are allowed to enter.

What Is the Least Privilege Principle?

The principle of least privilege is a security concept that says: every user, system, or service should have only the minimum permissions it needs to do its job, and nothing more.

If a Lambda function only needs to read from one specific DynamoDB table (a type of AWS database), it should have permission to read from that one table. It should not have permission to read from all tables, write to tables, delete tables, or access any other AWS service.

This sounds obvious. But in practice, it is almost never what happens.

How Execution Roles Are Usually Set Up

When you create a Lambda function for the first time, AWS creates a basic execution role for you automatically. This default role usually includes permission to write logs to CloudWatch (AWS's logging service), which is fine.

But here is where the problem starts.

As you build your function and it needs to access more services, the easiest thing to do is go to the role and add more permissions. Need to read from S3? Add s3:GetObject. Actually, to save time, just add s3:* which gives the function permission to do everything in S3. Need to write to DynamoDB? Add dynamodb:*. Need to send messages? Add sns:*.

Within a few iterations, your Lambda function has a role that can read, write, and delete across half your AWS account.

And then there is the even worse pattern: one shared role for all Lambda functions. Instead of creating a separate role for each function, many developers just reuse the same role across every function in the project. It is faster to set up. But now every single function has every permission that any function ever needed.

Why This Is a Real Problem

You might be thinking: my app is not a high value target, nobody is going to attack my Lambda function.

That thinking is what attackers rely on.

Lambda functions are often triggered by external events. An API Gateway request, an S3 file upload, an SNS message. Any of these entry points can potentially be exploited if there is a vulnerability in your code, a dependency with a known security issue, or even a misconfigured trigger.

If an attacker gains control of one Lambda function that has an overly permissive role, they do not just have access to what that function was supposed to do. They have access to everything that role allows. That could mean reading sensitive data from your database, writing files to your storage, sending messages to your users, or even modifying other parts of your infrastructure.

One compromised function becomes a key to your entire account.

The Three Most Common Mistakes

Mistake 1: Using wildcard permissions

A wildcard in IAM policy looks like this:

{
  "Effect": "Allow",
  "Action": "dynamodb:*",
  "Resource": "*"
}

The dynamodb:* means allow all DynamoDB actions. The "Resource": "*" means on all resources. So this one policy line gives your Lambda function full DynamoDB access across your entire account. If your function only needed to read from one table, this is massively over-permissioned.

Mistake 2: Sharing one role across multiple Lambda functions

Every function has different responsibilities. A function that sends a password reset email should not have the same permissions as a function that processes payments. When you share a role, you are taking the maximum permissions needed by any one function and giving them to all functions.

Mistake 3: Never revisiting the role after initial setup

During development, it is common to grant broad permissions just to get things working. The problem is that most developers never go back to tighten those permissions before going live. The overly permissive development role becomes the production role.

How to Fix It

Fix 1: One role per Lambda function

Each Lambda function should have its own dedicated execution role. Yes, this means more roles to manage. But it means a compromised function can only access what it specifically needs, not what any other function needs.

Fix 2: Scope permissions to specific actions and resources

Instead of dynamodb:* on *, write out exactly what the function needs:

{
  "Effect": "Allow",
  "Action": [
    "dynamodb:GetItem",
    "dynamodb:PutItem"
  ],
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MySpecificTable"
}

This gives permission only to read and write items, and only on one specific table. Nothing more.

The arn in the resource field is a unique identifier for a specific AWS resource. Every resource in AWS has one. Using it in your policy means you are granting access to that one resource, not everything in the service.

Fix 3: Use IAM Access Analyzer to generate policies from actual usage

IAM Access Analyzer is a free AWS tool that can look at your CloudTrail logs (the record of every action taken in your AWS account) and tell you exactly which permissions your Lambda function actually used over a given time period.

Instead of guessing what permissions a function needs, you can run it for a while, then use Access Analyzer to generate a policy based on real usage. This is one of the most accurate ways to arrive at a least privilege policy.

To use it, go to IAM in the AWS console, find the role attached to your Lambda function, and look for the "Generate policy" option under Access Analyzer.

Fix 4: Use permission boundaries as a safety net

A permission boundary is a policy that sets a ceiling on what permissions a role can ever have. Even if someone attaches a broad policy to the role later, the boundary limits the effective permissions.

This is especially useful in team environments where multiple developers are creating and modifying Lambda functions. It acts as a guardrail so that even if someone makes a mistake, the damage is contained.

A Simple Checklist Before You Deploy

Before your Lambda function goes live, go through these:

Does this function have its own dedicated execution role, not shared with any other function?

Does the role use specific actions like dynamodb:GetItem instead of dynamodb:*?

Does the role point to specific resource ARNs instead of *?

Have you removed any permissions that were added during development and are no longer needed?

If you are working in a team, is there a permission boundary in place?

Conclusion

Least privilege is one of the most talked about security principles in cloud development. But it is also one of the most commonly ignored in practice, not because developers do not care, but because the default path leads away from it.

AWS makes it easy to create broad roles. It is faster to write dynamodb:* than to list out every specific action. It is more convenient to reuse one role across all your functions. But each of those shortcuts quietly widens the blast radius if something goes wrong.

Fixing this does not require rebuilding anything. It just requires going back to your Lambda functions one by one, looking at their execution roles, and asking: does this function actually need all of this?

Most of the time, the answer will be no.

Need Help?

If you want help auditing your Lambda execution roles or figuring out what permissions your functions actually need, feel free to reach out.

Email me at khantanseer43@gmail.com

AWS Amplify Looks Simple, Until It Is Not

Tanseer — Tue, 12 May 2026 05:22:47 +0000

Who This Is For

If you are new to AWS and thinking of using Amplify to deploy your app, this blog is for you.

Amplify is marketed as an easy, all-in-one deployment platform. And for simple use cases, it is. But once you start pushing it a little : different package managers, larger projects, custom configurations : you start running into walls that are not mentioned anywhere in the getting started guides.

I have spent a lot of time deploying different kinds of applications on Amplify. I have hit these walls firsthand. This blog is a collection of the things I discovered the hard way, explained simply, so you do not have to go through the same debugging sessions.

A Quick Intro to AWS Amplify for Beginners

Before we get into the issues, here is a quick explanation of what Amplify actually is.

AWS Amplify is a hosting and deployment platform from Amazon Web Services. You connect your GitHub repository to Amplify, and every time you push code, Amplify automatically builds and deploys your app. It handles the servers, the CDN (Content Delivery Network : the system that delivers your app quickly to users around the world), and the deployment pipeline for you.

It sounds perfect. And for many projects, it works well. But here are the things you need to know before you go all in.

Issue 1: The Cache Feature Does Not Actually Help

The Problem

Amplify has a built-in caching feature. In theory, it saves folders like node_modules (the folder where all your app's dependencies or packages live) between builds. The idea is that on the next build, those packages are already there and do not need to be downloaded again, making the build faster.

In practice, the opposite happens.

Amplify's cache works by zipping up the folder and uploading it to storage after a build, then downloading and unzipping it before the next build. This zip and unzip process itself takes significant time — in my experience, around 3 minutes to restore and 3 minutes to save.

Now here is the deeper problem. The two most common commands used to install packages are:

npm ci : This is the recommended command for automated deployments. It deletes node_modules completely and reinstalls everything from scratch every single time. It does not matter that Amplify just spent 3 minutes restoring that folder. npm ci will delete it immediately.

npm install: This one does not always delete node_modules, but it re-evaluates your packages and may reinstall parts of it anyway.

In both cases, the cache Amplify restored is either deleted immediately or partially ignored.

I ran experiments on both large projects and minimal ones. The result was consistent — removing the cache made builds faster, not slower.

The Solution

Remove the cache section from your amplify.yml file entirely. Here is what a clean build config looks like without cache:

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

No cache block. Cleaner, faster, simpler.

Issue 2: The 220MB Artifact Size Limit

The Problem

Amplify has a hard limit on the size of your build artifacts. Artifacts are the files produced after your build, things like your compiled JavaScript, CSS, images, and in some cases the node_modules folder if your app needs it at runtime.

The limit is 220MB.

This sounds like a lot until you are building a Next.js app (a popular React framework) with server-side features. Next.js SSR (Server-Side Rendering — where pages are generated on the server instead of the browser) requires parts of node_modules to be bundled with the output. A medium-sized project can easily exceed 220MB once all those dependencies are included.

When you hit this limit, the build fails with a vague error. If you are not aware of this constraint, you will spend a long time looking in the wrong places.

The Solution

There are a few ways to handle this:

The first option is to use output: 'standalone' in your next.config.js file if you are using Next.js. Standalone mode bundles only the exact files needed to run the app, which significantly reduces the output size.

// next.config.js
const nextConfig = {
  output: 'standalone',
};

module.exports = nextConfig;

The second option is to audit your dependencies. Tools like npm-analyze or the --why flag in pnpm can help you find packages that are large and may not be needed at runtime.

The third option, if you are consistently hitting this limit, is to consider moving to a different deployment setup such as running your app in a container on ECS (Elastic Container Service) or using a different hosting provider that does not have this constraint.

Issue 3: pnpm's Symlink Structure Breaks at Runtime

The Problem

pnpm is a modern, faster alternative to npm for managing packages. It is popular because it saves disk space and installs faster. However, pnpm uses a unique approach to storing packages : it uses symlinks (think of them as shortcuts that point to where a file actually lives) instead of copying files directly into your node_modules folder.

Amplify's build and runtime environment does not handle these symlinks well.

What typically happens is this: your build completes successfully. Everything looks fine. But when your app actually runs, it throws a Cannot find module error : meaning it cannot locate a package that is clearly installed. The app is broken at runtime even though the build passed.

This is a known issue that has been reported by multiple developers and is documented in Amplify's GitHub issues.

The Solution

The fix is to force pnpm to use a "hoisted" install mode, which makes it behave more like npm by copying packages directly instead of using symlinks. Add this to your amplify.yml in the preBuild section:

preBuild:
  commands:
    - echo "node-linker=hoisted" >> .npmrc
    - corepack enable
    - pnpm install --shamefully-hoist

The --shamefully-hoist flag tells pnpm to put all packages directly in node_modules the traditional way. The name sounds alarming but it is a well-known workaround specifically for environments that do not support symlinks.

Alternatively, if you are not tied to pnpm, switching to npm for your Amplify builds is the simplest fix. You can keep pnpm locally for development and use npm in the Amplify build config.

A Note on These Constraints

None of these limitations are front and center in Amplify's documentation. Most of them are buried in GitHub issue threads, Stack Overflow answers, or AWS re:Post forums. As a beginner, you would have no reason to look for them until something breaks.

That is the pattern with Amplify, it works smoothly for straightforward use cases, but the moment you step slightly outside the default path, you hit constraints that are hard to debug without prior knowledge.

This is not to say Amplify is bad. For small to medium projects, it is genuinely convenient. But going in with eyes open about these limitations will save you real time.

Quick Reference

Here is a summary of everything covered:

Cache, remove it entirely. It adds time instead of saving it because npm ci and npm install both ignore or delete the cached node_modules anyway.

220MB artifact limit plan for it. Use Next.js standalone output mode and audit your dependencies if you are close to the limit.

pnpm symlinks, use hoisted mode. Add node-linker=hoisted to your .npmrc and use --shamefully-hoist when installing, or switch to npm for Amplify builds.

Have You Hit Other Amplify Limitations?

This list is based on my own experience. Amplify has more quirks than these three, and I am sure other developers have hit walls I have not encountered yet.

If you have run into something that is not covered here, I would love to hear about it. Drop a comment or reach out directly, let us build a more complete picture of what Amplify can and cannot do, so the next developer does not have to figure it out the hard way.

Need Help?

If you are stuck on any of these issues or running into something else with your Amplify setup, feel free to reach out. I am happy to help.

Email me at khantanseer43@gmail.com

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

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