Amazon Simple Queue Service is a fully managed message queuing service. This guide shows how to set up SQS using Terraform with a comprehensive Infrastructure as Code approach for standard queues, FIFO queues, dead letter queues, and queue policies.

Terraform is an open-source Infrastructure as Code tool developed by HashiCorp, that lets you build, change, and version cloud and on-prem resources safely and efficiently in human-readable configuration files that you can version, reuse, and share.

Prerequisites

Before deploying SQS with Terraform, the following prerequisites are required.

AWS CLI configured
Terraform installed
Basic understanding of message queues
Producer and consumer applications ready

For local credential setup workflows described in reference material, IAM user creation is used to provide programmatic access:

Click on create user
Enter the name and set password
Click on next button
Select attach policies directly
Tick on Amazon SQS Fullaccess
Click create user
Click Return to user list
Click on your username
Create access key
Select CLI
You will get a secret key and Access Key
If Download.csv file

Variable definitions for credentials in VS Code are created as:

variable "accesskey" {
description = "Access key to AWS console"
}
variable "secretkey" {
description = "Secret key to AWS console"
}
variable "region" {
description = "AWS region"
}

Project Structure

A typical aws-sqs-terraform project is organized to separate configuration, variables, and outputs.

aws-sqs-terraform/
├── main.tf
├── variables.tf
├── outputs.tf
└── terraform.tfvars

This structure supports reusable modules and clear separation of provider configuration, resource definitions, and variable inputs.

Provider Configuration

The provider block configures the authentication details and default settings for interacting with AWS.

resource "aws" configuration examples from reference material show two forms:

provider "aws" {
region = var.aws_region
}

provider "aws" {
region = "us-east-1" # Specify your desired AWS region
}

The provider block is the entry point for Terraform to authenticate to AWS and apply region defaults for all subsequent SQS resources.

Standard Queue Configuration

The standard SQS queue resource is defined with a set of configurable attributes.

resource "awssqsqueue" "standard" {
name = "${var.projectname}-queue"
visibilitytimeoutseconds = 30
messageretentionseconds = 345600 # 4 days
maxmessagesize = 262144 # 256 KB
delayseconds = 0
receivewaittime_seconds = 0
tags = {
Environment = var.environment
}
}

Key attributes for the standard queue:

| Attribute | Value | Notes |
| name | ${var.projectname}-queue | Queue name derived from project variable |
| visibilitytimeoutseconds | 30 | Seconds before message reappears |
| messageretentionseconds | 345600 | 4 days retention |
| maxmessagesize | 262144 | 256 KB |
| delayseconds | 0 | No delivery delay |
| receivewaittime_seconds | 0 | No long polling |
| tags.Environment | var.environment | Tagging |

Standard queues offer best-effort ordering and higher throughput. The name argument must match the real SQS queue name when importing existing infrastructure.

FIFO Queue Configuration

FIFO queues provide strict ordering and exactly-once processing.

resource "awssqsqueue" "fifo" {
name = "${var.projectname}-queue.fifo"
fifoqueue = true
contentbaseddeduplication = true
visibilitytimeoutseconds = 30
messageretentionseconds = 345600
maxmessagesize = 262144
delayseconds = 0
receivewaittimeseconds = 0
tags = {
Environment = var.environment
}
}

Comparison between queue types:

FIFO queues require a .fifo suffix in the name and enable content based deduplication to avoid duplicate messages.

Dead Letter Queue and Redrive

Dead letter queues capture messages that fail processing after a defined number of attempts.

resource "awssqsqueue" "dlq" {
name = "${var.project_name}-dlq"
tags = {
Environment = var.environment
}
}

When messages in a standard SQS queue fail to be processed successfully after a certain number of attempts, they can be automatically sent to a DLQ.

DLQs can also be monitored for metrics like the number of messages and errors, which can help you maintain the health of your messaging system.

The main queue with redrive policy references the DLQ to enable automatic dead lettering.

Queue Policy and Access Control

Queue policies are required for cross-account access or access from AWS services that require a queue policy, for example, SNS fan-out to SQS.

resource "awssqsqueuepolicy" "standard" {
queueurl = awssqsqueue.standard.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Effect = "Allow"
Principal = {
AWS = ""
}
Action = "SQS:"
Resource = awssqsqueue.standard.arn
Condition = {
ArnEquals = {
"aws:SourceArn": var.source_arn
}
}
}
]
})
}

Use awssqsqueue_policy when you need cross-account access or access from AWS services that require a queue policy.

Keep these policies minimal and explicit, granting access only to the required principals and actions.

Encryption and Permissions Alignment

If you use a customer managed KMS key for queue encryption, make sure:

The IAM role that accesses the queue also has kms:Encrypt, kms:Decrypt, and kms:GenerateDataKey* on the relevant KMS key
The KMS key policy allows the SQS service and your application roles to use the key

If you stay with the default AWS-managed key for SQS encryption, AWS handles most of the key policy for you, and you usually do not need extra KMS permissions.

Managing both queue and KMS permissions in Terraform keeps your security posture consistent and avoids subtle runtime failures when messages are encrypted.

Importing Existing Queues

Terraform can adopt existing SQS queues into state.

resource "awssqsqueue" "orders_queue" {
name = "orders-queue"

Optional: fill in settings to match the existing queue

visibilitytimeoutseconds = 60

messageretentionseconds = 345600

...

}

The resource name is internal to Terraform. The name argument must match the real SQS queue name.

Import workflow:

Use the resource awssqsqueue.orders_queue in the config
Link it to the existing SQS queue with that URL

Command example:

terraform import awssqsqueue.orders_queue https://sqs.eu-central-1.amazonaws.com/123456789012/orders-queue

If you use a newer Terraform version you can also define an import block in your configuration instead of running terraform import, but the command shown here is still supported and simple to use.

After the import completes run terraform plan to see any differences between your configuration and the actual queue.

You can run terraform state show awssqsqueue.orders_queue to see the full set of arguments and align your configuration. Only add arguments in your HCL that you actually want Terraform to manage and leave computed attributes out of the configuration.

Terraform Workflow Commands

After writing configuration, the standard Terraform workflow is:

Now initialize terraform by using following command
terraform init
Now execute terraform execution commands by using following commands
terraform fmt
terraform validate
terraform plan
Now execute terraform apply command by using following command
terraform apply --auto-approve

The following screenshot shows that we successfully created a sqs in aws using terraform

Create SQS topic resource definition:

resource "awssqsqueue" "my_queue" {
name = "my-sqs-topic"
}

Define the SQS topic resource in your Terraform configuration file, specifying the name for the topic.

VS Code Setup for SQS Terraform

Now, Create SQS in Terraform using VScode.

STEP 1: Navigate IAM and create Users.

STEP 7: Go to VScode select your folder and create variable.tf file.

STEP 8: Next, Create terraform.tf file.

region = "us-east-1"
accesskey = ""
secretkey = "

This pattern separates sensitive variables from main configuration and allows reuse across environments.

Conclusion

Amazon Simple Queue Service remains as an essential part inside the AWS environment, offering a scalable, reliable, and completely managed message queuing service for dispersed systems.

All through this conversation, we've explored SQS's capacity to work with asynchronous correspondence between various pieces of an application, empowering decoupling and consistent scaling of parts. By utilizing SQS, developers can ensure message reliability and availability, even notwithstanding system failures or spikes traffic.

Terraform provides declarative control over standard queues, FIFO queues, dead letter queues, and queue policies with explicit attribute management, import support for brownfield adoption, and consistent security alignment with KMS and IAM. Using Terraform for SQS ensures versioned, repeatable, and auditable queue infrastructure that matches production requirements for visibility timeout, retention, message size, delay, and long polling.

AWS SQS Terraform Deployment and Management