How to Deploy SQL Server with Read Replicas on AWS Using Terraform

Paulo Srulevitch
Oct 8
3 min read

TL;DR Deploying SQL Server with read replicas on AWS is complex due to edition, licensing, and provisioning limits. Teracloud built a Terraform module that makes the process reliable, production-ready, and scalable—so you can automate deployments, cut downtime risk, and gain full Infrastructure as Code control.

When your business relies on SQL Server, performance and scalability are not optional—they’re critical.

On AWS, the ability to set up read replicas quickly can protect you from downtime, keep costs predictable, and ensure your apps scale with demand. But for teams using Terraform, deploying SQL Server with read replicas hasn’t always been simple.

At Teracloud, we turned that challenge into a solution. We built a Terraform module that makes deploying SQL Server Enterprise Edition with read replicas reliable, reusable, and production-ready—saving engineering teams hours of trial and error.

Why is it so hard to deploy SQL Server with read replicas on AWS?

Unlike Aurora or PostgreSQL, SQL Server doesn’t support native read replicas in RDS. Instead, AWS offers a managed implementation that comes with strict conditions:

Only works with SQL Server Enterprise Edition
Requires the license-included model
Supported only on gp2 or gp3 storage

To make matters worse, provisioning can take over an hour, which often causes Terraform to timeout and lose track of the resource. This leaves engineers stuck reconciling the drift between their infrastructure and their code.

What does Teracloud’s Terraform module solve?

Our module extends the official AWS Terraform modules and adds what SQL Server users actually need:

Full support for replicate_source_db
Configurable replica_count
Optional multi-AZ deployment for resiliency
gp3 storage with custom IOPS and throughput

Best practice: deploy the primary instance first, confirm it’s available, and then re-run Terraform to add replicas. This prevents failures while AWS stabilizes the primary instance.

Example Usage

module "rds_sqlserver" {
  source = "../../modules/rds/sqlserver_w_rr" (gitsource here)

  name                 = "${local.project}-sqlserver"
  replica_count        = 1 #limit 14, set 0 for start db

  instance_class        = "db.r5.xlarge"
  allocated_storage     = 500
  max_allocated_storage = 1000
  storage_type          = "gp3"
  iops                  = 3000
  throughput            = 500

  username = "admin"
  password = aws_ssm_parameter.sqlserver_master_password.value

  vpc_id                 = module.vpc.vpc_id
  subnet_ids             = module.vpc.database_subnets
  create_db_subnet_group = true
  db_subnet_group_name   = "subnet-${local.project}-${local.environment}"
  vpc_security_group_ids = [aws_security_group.rds_sqlserver.id]

  kms_key_id = aws_kms_key.rds_sqlserver.arn

  multi_az            = true
  publicly_accessible = false

  monitoring_interval             = 60 #minimum interval
  monitoring_role_arn             = aws_iam_role.rds_enhanced_monitoring.arn
  performance_insights_enabled    = false
  enabled_cloudwatch_logs_exports = ["error"]

  backup_retention_period = 7
  backup_window           = "02:00-03:30"
  maintenance_window      = "Mon:00:00-Mon:01:30"

  deletion_protection = false
  skip_final_snapshot = true #in prod change to false

  tags = local.tags
}

What happens if Terraform times out?

If your Terraform apply fails due to a timeout but AWS still created the resource, recovery is straightforward:

terraform untaint "module.rds_sqlserver.module.rds.module.db_instance.aws_db_instance.this[0]"
terraform refresh
terraform apply

Terraform will then show:

 No changes. Your infrastructure matches the configuration.

This ensures your state file matches your actual infrastructure without manual cleanup.

Why should you use this module for production?

With this approach, teams can:

Deploy highly available SQL Server clusters on AWS
Add read replicas on demand
Avoid tedious console work and gain full Infrastructure as Code control

Whether you’re migrating from on-premise SQL Server or scaling existing workloads in AWS, this module gives you the flexibility and reliability to do it right.

What if I don’t need read replicas?

Not every SQL Server environment needs replicas—and not all editions support them. For those use cases, Teracloud also provides a generic Terraform module that:

Works with all AWS-supported SQL Server editions (Standard, Web, Express)
Supports both license-included and bring-your-own-license (BYOL)
Avoids replication complexity for dev, test, or legacy migrations

This way, you have a toolset that covers 100% of SQL Server use cases on AWS.

Final Thoughts: Scaling SQL Server on AWS doesn’t have to be painful

SQL Server may not be as cloud-native as Aurora or PostgreSQL, but with the right tooling, it can still be deployed at scale without headaches. Teracloud’s Terraform modules give you the flexibility to handle production workloads with replicas or keep it simple for non-replica environments.

That means less time fixing deployment errors and more time delivering value where it matters.

FAQ

Can I deploy SQL Server Standard Edition with read replicas on AWS RDS?

No. Read replicas are only supported on SQL Server Enterprise Edition with the license-included model.

How many read replicas can I create?

AWS allows up to 14 replicas per primary SQL Server Enterprise Edition instance.

Does deploying with Terraform guarantee zero downtime?

Not during the initial provisioning, which can take an hour or more. But with our two-step approach (primary first, replicas second), you significantly reduce the risk of failed deployments.

Is this the same as Always On Availability Groups?

No. AWS uses database mirroring under the hood, not Always On. That means replicas don’t support multi-writer or automated failover scenarios.

What’s the main benefit of using Teracloud’s module instead of the console?

Automation and repeatability. You avoid manual errors, enforce best practices, and gain consistent, production-ready deployments across environments.

Cloud Engineer

Silvio DePetri