DEV Community: Prashant Bhatasana

Terraform — Deploying Multi-Region AWS RDS Cluster with Failover Setup using Terraform

Prashant Bhatasana — Wed, 21 May 2025 09:59:47 +0000

In this article, we will go through how to deploy a multi-region AWS RDS cluster with an automatic failover setup using Terraform. By leveraging AWS RDS (Relational Database Service) and Terraform, we can set up highly available, fault-tolerant database architectures across multiple regions. This ensures that your applications remain online even in the event of regional outages, providing resilience and scalability for critical applications.

Prerequisites

Before starting, ensure you have the following:

AWS Account: An active AWS account with the necessary permissions.
AWS CLI: AWS CLI should be configured with your AWS credentials.
Terraform Installed: Terraform must be installed on your local machine. You can download it from Terraform’s official site.

So, let’s start!

→ Create a ”provider.tf”

The provider file tells Terraform which provider you are using.

provider "aws" {
  region = local.region_0
  profile = "<profile-name>"

  default_tags {
    tags = {
      Owner       = "primary"
      Project     = "AWS Multi Region rds with active/active setup"
      Provisioner = "Terraform"
    }
  }
}

provider "aws" {
  alias  = "secondory"
  region = local.region_1
  profile = "<profile-name>"

  default_tags {
    tags = {
      Owner       = "secondory"
      Project     = "AWS Multi Region rds with active/active setup"
      Provisioner = "Terraform"
    }
  }
}

→ Create “data.tf”

Terraform data sources allow you to fetch information from your cloud provider and use it within your configuration. This can be particularly useful for validating inputs, such as checking the list of availability zones in a given region to see if a specific Amazon Machine Image (AMI) ID exists in that region before creating an EC2 instance.

data "aws_availability_zones" "region_0" {}
data "aws_availability_zones" "region_1" {
  provider = aws.secondory
}
data "aws_caller_identity" "this" {}
data "aws_kms_key" "rds_0" {
  key_id = "alias/aws/rds"
}
data "aws_kms_key" "rds_1" {
  provider = aws.secondory
  key_id   = "alias/aws/rds"
}

→ Create “locals.tf”

Terraform Locals are named values that can be assigned and used in your code. It mainly serves the purpose of reducing duplication within the Terraform code. When you use Locals in the code, since you are reducing duplication of the same value, you also increase the readability of the code.

locals {
environment = replace("${var.environment_input}", "_", "-")

availability_zones_0 = data.aws_availability_zones.region_0.names
  public_subnets_0 = [
    cidrsubnet(local.vpc_cidr_0, 6, 0),
    cidrsubnet(local.vpc_cidr_0, 6, 1),
    cidrsubnet(local.vpc_cidr_0, 6, 2),
  ]
  private_subnets_0 = [
    cidrsubnet(local.vpc_cidr_0, 6, 4),
    cidrsubnet(local.vpc_cidr_0, 6, 5),
    cidrsubnet(local.vpc_cidr_0, 6, 6),
  ]
  database_subnets_0 = [
    cidrsubnet(local.vpc_cidr_0, 6, 7),
    cidrsubnet(local.vpc_cidr_0, 6, 8),
    cidrsubnet(local.vpc_cidr_0, 6, 9),
  ]

  availability_zones_1 = data.aws_availability_zones.region_1.names
  public_subnets_1 = [
    cidrsubnet(local.vpc_cidr_1, 6, 0),
    cidrsubnet(local.vpc_cidr_1, 6, 1),
    cidrsubnet(local.vpc_cidr_1, 6, 2),
  ]
  private_subnets_1 = [
    cidrsubnet(local.vpc_cidr_1, 6, 4),
    cidrsubnet(local.vpc_cidr_1, 6, 5),
    cidrsubnet(local.vpc_cidr_1, 6, 6),
  ]
  database_subnets_1 = [
    cidrsubnet(local.vpc_cidr_1, 6, 7),
    cidrsubnet(local.vpc_cidr_1, 6, 8),
    cidrsubnet(local.vpc_cidr_1, 6, 9),
  ]

  database_username = "aurora_admin"
  database_password = "aurora_admin123"

  region_0 = "us-west-1"
  region_1 = "us-west-2"

  vpc_cidr_0 = "20.1.0.0/16"
  vpc_cidr_1 = "30.2.0.0/16"

  vpc_route_tables_0 = flatten([module.vpc_0.private_route_table_ids, module.vpc_0.public_route_table_ids])
  vpc_route_tables_1 = flatten([module.vpc_1.private_route_table_ids, module.vpc_1.public_route_table_ids])
}

Terraform Locals vs Variables

How does Terraform local differ from a Terraform variable?

The first difference can be pointed towards the scope. A Local is only accessible within the local module vs a Terraform variable, which can be scoped globally.

Another thing to note is that a local in Terraform doesn’t change its value once assigned. A variable value can be manipulated via expressions. This makes it easier to assign expression outputs to locals and use them throughout the code instead of using the expression itself at multiple places.

Note: For demonstration, I have used both locals and variables; however, you can modify them according to your use case.

→ Create “variables.tf”

All variables will be in this file.

variable "environment_input" {
  description = "Environment name we are building"
  default     = "aws_multi_region"
}

variable "tags" {
  description = "Default tags for this environment"
  default     = {}
}

If you are using terraform.tfvars, you need to add a description only.

→ Create a "terraform.tfvars

To persist variable values, create a file and assign variables within this file. Create a file named terraform.tfvars With the following contents:

environment = "aws_multi_region_aurora"
tags        = {}

For all files that match terraform.tfvars or *.auto.tfvars present in the current directory, Terraform automatically loads them to populate variables. If the file is named something else, you can use the -var-file flag directly to specify a file.

I don’t recommend saving usernames and passwords to version control, but you can create a local secret variables file and use -var-file to load it.

→ Create a “vpc.tf"

For this demo, I'm using different VPC modules to show how we can use external modules in Terraform, but you can follow this article and use my VPC module for this setup as well

Terraform — AWS VPC with Private, Public Subnets with NAT | by Prashant Bhatasana | AppGambit | Medium

Prashant Bhatasana ・ Oct 9, 2020 ・
Medium

data "aws_region" "current" {}

module "vpc_0" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.13.0"

  azs                                             = local.availability_zones_0
  cidr                                            = local.vpc_cidr_0
  create_database_subnet_group                    = true
  create_flow_log_cloudwatch_iam_role             = true
  create_flow_log_cloudwatch_log_group            = true
  # database_subnets                                = local.database_subnets_0
  database_subnets                                = local.database_subnets_0
  enable_dhcp_options                             = true
  enable_dns_hostnames                            = true
  enable_dns_support                              = true
  enable_flow_log                                 = true
  enable_ipv6                                     = false
  # enable_nat_gateway                              = true
  flow_log_cloudwatch_log_group_retention_in_days = 7
  flow_log_max_aggregation_interval               = 60
  name                                            = local.environment
  # one_nat_gateway_per_az                          = false
  private_subnet_suffix                           = "private"
  private_subnets                                 = local.private_subnets_0
  public_subnets                                  = local.public_subnets_0
  # single_nat_gateway                              = true
  tags                                            = var.tags
}

module "vpc_1" {
  providers = { aws = aws.secondory }
  source    = "terraform-aws-modules/vpc/aws"
  version   = "~> 5.13.0"

  azs                                             = local.availability_zones_1
  cidr                                            = local.vpc_cidr_1
  create_database_subnet_group                    = true
  create_flow_log_cloudwatch_iam_role             = true
  create_flow_log_cloudwatch_log_group            = true
  # database_subnets                                = local.database_subnets_1
  database_subnets                                = local.database_subnets_1
  enable_dhcp_options                             = true
  enable_dns_hostnames                            = true
  enable_dns_support                              = true
  enable_flow_log                                 = true
  enable_ipv6                                     = false
  # enable_nat_gateway                              = true
  flow_log_cloudwatch_log_group_retention_in_days = 7
  flow_log_max_aggregation_interval               = 60
  name                                            = local.environment
  # one_nat_gateway_per_az                          = false
  private_subnet_suffix                           = "private"
  private_subnets                                 = local.private_subnets_1
  public_subnets                                  = local.public_subnets_1
  # single_nat_gateway                              = true
  tags                                            = var.tags
}

→ Create a “rds.tf”
This file will contain the necessary Terraform configuration for the RDS Cluster setup.

resource "aws_rds_global_cluster" "this" {
  global_cluster_identifier = local.environment
  storage_encrypted         = true
  engine                    = "aurora-postgresql"
  engine_version            = "15.5"
  database_name             = "multiregion"
}

module "aurora_primary" {
  source = "terraform-aws-modules/rds-aurora/aws"

  name                      = "${local.environment}-${local.region_0}"
  database_name             = aws_rds_global_cluster.this.database_name
  engine                    = aws_rds_global_cluster.this.engine
  engine_version            = aws_rds_global_cluster.this.engine_version
  global_cluster_identifier = aws_rds_global_cluster.this.id
  instance_class            = "db.r6g.large"
  instances                 = { for i in range(2) : i => {} }

  kms_key_id = data.aws_kms_key.rds_0.arn

  publicly_accessible = true
  vpc_id               = module.vpc_0.vpc_id
  db_subnet_group_name = module.vpc_0.database_subnet_group_name
  security_group_rules = {
    vpc_ingress = {
      cidr_blocks = concat(
        module.vpc_0.public_subnets_cidr_blocks,
        module.vpc_1.public_subnets_cidr_blocks,
      )
    }
  }

  master_username = local.database_username
  master_password = local.database_password

  skip_final_snapshot = true

  tags = var.tags
}

module "aurora_secondary" {
  source = "terraform-aws-modules/rds-aurora/aws"

  providers = { aws = aws.secondory }

  is_primary_cluster = false

  name                      = "${local.environment}-${local.region_1}"
  engine                    = aws_rds_global_cluster.this.engine
  engine_version            = aws_rds_global_cluster.this.engine_version
  global_cluster_identifier = aws_rds_global_cluster.this.id
  source_region             = local.region_0
  instance_class            = "db.r6g.large"
  instances                 = { for i in range(2) : i => {} }

  kms_key_id = data.aws_kms_key.rds_1.arn

  publicly_accessible = true
  vpc_id               = module.vpc_1.vpc_id
  db_subnet_group_name = module.vpc_1.database_subnet_group_name
  security_group_rules = {
    vpc_ingress = {
      cidr_blocks = concat(
        module.vpc_0.public_subnets_cidr_blocks,
        module.vpc_1.public_subnets_cidr_blocks,
      )
    }
  }

  skip_final_snapshot = true

  depends_on = [
    module.aurora_primary
  ]

  tags = var.tags
}

resource "random_password" "master" {
  length  = 20
  special = false
}

resource "aws_secretsmanager_secret" "rds_credentials" {
  name                    = "${local.environment}-aurora-credentials-multi-region-0"
  description             = "${local.environment} aurora username and password"

  depends_on = [module.aurora_primary]
}

resource "aws_secretsmanager_secret_version" "rds_credentials" {
  secret_id = aws_secretsmanager_secret.rds_credentials.id
  secret_string = jsonencode(
    {
      username = module.aurora_primary.cluster_master_username
      password = module.aurora_primary.cluster_master_password
    }
  )

  depends_on = [module.aurora_primary]
}

Initialize, plan and Apply the Terraform Configuration

Initialize Terraform: This command initializes the project, downloads the necessary provider plugins, and sets up the backend for storing the state.

terraform init

Plan Terraform: This command creates an execution plan, showing what actions Terraform will take to reach the desired infrastructure state. It compares the current state with the configuration and highlights the resources to be created, modified, or destroyed, without making any actual changes.

terraform plan

Apply the Configuration: This command applies the changes required to reach the desired state of the configuration.

terraform apply

You’ll be prompted to confirm the changes. Type yes and hit Enter.

Verify the RDS Cluster Configuration

After applying the Terraform configuration, you can verify the multi-region database cluster.

Thank you for reading. If you have anything to add, please send a response or add a note!

This article was originally published here:

Terraform — Deploying Multi-Region AWS RDS Cluster with Failover Setup using Terraform | by Prashant Bhatasana | DevOps Pro | Medium

Prashant Bhatasana ・ May 5, 2025 ・
Medium

AWS Database Migration Service — Incremental Migration from RDS To S3

Prashant Bhatasana — Fri, 13 Sep 2024 09:39:43 +0000

Originally Posted on medium.com

Migrating data from relational databases to cloud-based data lakes is a common task in modern data architectures. Amazon Web Services (AWS) offers a robust solution called AWS Database Migration Service (DMS) that simplifies this process. This service is particularly useful for incremental migrations, allowing you to replicate ongoing changes in your source databases to a target destination like Amazon S3.

In this article, we’ll set up an incremental migration from an Amazon RDS database to an S3 bucket using Terraform.

Why Use AWS DMS?

AWS DMS provides several advantages:

Minimal Downtime: Supports continuous data replication, which is essential for reducing downtime during migrations.
Versatility: Supports various source and target database engines, making it flexible for different use cases.
Ease of Use: Simple to set up and monitor, with a pay-as-you-go pricing model.

Architecture Overview

The migration setup involves:

Source Database: An Amazon RDS instance (e.g., MySQL, PostgreSQL).
Target Data Store: An Amazon S3 bucket where the data will be stored.
AWS DMS: The service used to perform the migration, including replication instances, endpoints, and tasks.

Setting Up the Environment with Terraform
Terraform is an Infrastructure as Code (IaC) tool that allows you to define and provision infrastructure using a high-level configuration language. Here’s how to set up the environment:

Step 1: Define Provider and Variables

First, set up your provider and variables in a main.tf file:

provider "aws" {
  region = "us-west-2"
}

variable "rds_instance_id" {
  description = "The RDS instance identifier"
}

variable "s3_bucket_name" {
  description = "The name of the S3 bucket"
}

Step 2: Create the S3 Bucket

resource "aws_s3_bucket" "target_bucket" {
  bucket = var.s3_bucket_name
  acl    = "private"

  versioning {
    enabled = true
  }

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

Step 3: Define IAM Role for DMS

AWS DMS needs an IAM role with the necessary permissions to access the RDS instance and the S3 bucket:

resource "aws_iam_role" "dms_role" {
  name = "dms-access-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Action    = "sts:AssumeRole",
      Effect    = "Allow",
      Principal = {
        Service = "dms.amazonaws.com"
      }
    }]
  })
}

resource "aws_iam_policy" "dms_policy" {
  name   = "dms-access-policy"
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Action = [
        "s3:*",
        "rds:*",
        "dms:*"
      ],
      Effect   = "Allow",
      Resource = "*"
    }]
  })
}

resource "aws_iam_role_policy_attachment" "dms_attach_policy" {
  role       = aws_iam_role.dms_role.name
  policy_arn = aws_iam_policy.dms_policy.arn
}

Step 4: Define DMS Endpoints

Create the source and target endpoints for DMS:

resource "aws_dms_endpoint" "source_endpoint" {
  endpoint_id          = "rds-source-endpoint"
  endpoint_type        = "source"
  engine_name          = "mysql"
  username             = "your-db-username"
  password             = "your-db-password"
  server_name          = "your-db-endpoint"
  port                 = 3306
  database_name        = "your-database-name"
}

resource "aws_dms_endpoint" "target_endpoint" {
  endpoint_id          = "s3-target-endpoint"
  endpoint_type        = "target"
  engine_name          = "s3"
  s3_settings {
    bucket_name        = aws_s3_bucket.target_bucket.bucket
    bucket_folder      = "dms-data"
    compression_type   = "gzip"
  }
}

Step 5: Create a DMS Replication Instance

The replication instance handles the migration process:

resource "aws_dms_replication_instance" "replication_instance" {
  replication_instance_id   = "dms-replication-instance"
  replication_instance_class = "dms.t2.micro"
  allocated_storage         = 100
  publicly_accessible       = true
  apply_immediately         = true
}

Step 6: Create a DMS Replication Task

Define the task that will perform the migration:

resource "aws_dms_replication_task" "replication_task" {
  replication_task_id          = "rds-to-s3-task"
  migration_type               = "full-load-and-cdc"
  table_mappings               = file("table-mappings.json")
  replication_task_settings    = file("task-settings.json")
  source_endpoint_arn          = aws_dms_endpoint.source_endpoint.endpoint_arn
  target_endpoint_arn          = aws_dms_endpoint.target_endpoint.endpoint_arn
  replication_instance_arn     = aws_dms_replication_instance.replication_instance.replication_instance_arn
}

The table-mappings.json file defines which tables to migrate, and the task-settings.json file contains task-specific settings like logging and error handling.

Configuring the Incremental Migration

To enable incremental migration (also known as Change Data Capture or CDC), the DMS task must be configured to continuously capture changes from the source database after the initial full load. This is controlled by the migration_type parameter, set to "full-load-and-cdc" in the DMS replication task.

Ensure that the source database is configured to support CDC, which may involve enabling binary logging in MySQL or a similar mechanism in other database engines.

Monitoring and Managing the Migration

AWS DMS provides several metrics and logs that you can use to monitor the migration process. You can access these metrics in the AWS Management Console or set up CloudWatch alarms to notify you of any issues.

Thank you for reading, if you have anything to add please send a response or add a note!

Happy migrating! 🚀

Terraform — Deploy Nodejs Application with AWS AppRunner

Prashant Bhatasana — Tue, 17 Aug 2021 07:49:58 +0000

In this article, we are talking about How we can deploy Nodejs Application with AWS AppRunner service deployment using Terraform.

AWS App Runner is a fully managed service that makes it easy for developers to quickly deploy containerized web applications and APIs, at scale and with no prior infrastructure experience required. Start with your source code or a container image. App Runner automatically builds and deploys the web application and load balances traffic with encryption. App Runner also scales up or down automatically to meet your traffic needs. With App Runner, rather than thinking about servers or scaling, you have more time to focus on your applications.

Prerequisites

We require AWS IAM API keys (access key and secret key) for creating and deleting permissions for all AWS resources.
Github account and new repository.
Terraform should be installed on the machine. If Terraform does not exist you can download and install it from here.

Prepare a Demo NodeJS Application

Create a project directory named demo-application anywhere in your system and make it your current directory:

mkdir demo-application
cd demo-application

Execute the following command within the demo-application directory to initialize your Node.js project with default settings:

npm init -y

Set Up Express with Node.js

To use the Express framework in your application, install it as a project dependency:

npm i express

After that package.json look like below

{
  "name": "demo-application",
  "version": "1.0.0",
  "description": "demo-application",
  "main": "index.js",
  "scripts": {
    "start": "node index.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [
    "express",
    "hello-world"
  ],
  "author": "Prashant_B",
  "license": "MIT",
  "dependencies": {
    "express": "^4.15.0"
  }
}

Then, create the entry point of the application, a file named index.js:

touch index.js

Add following code in index.js file.

var express = require('express')
var app = express() 
app.get('/', function (req, res) {
  res.send('Hello World!')
}) 
app.listen(3000, function () {
  console.log('Listening on port 3000...')
})

This app starts a server and listens on port 3000 for connections. The app responds with “Hello World!” for requests to the root URL (/) or route. For every other path, it will respond with a 404 Not Found.

Our demo application was ready now goto GitHub, create new repository and push application source code to GitHub repository.
Let’s move to Terraform
version

To build AWS App Runner, you need to meet the following versions:

Terraform v0.12 or higher
Latest version of AWS provider (3.42.0) Configuring App Runner in the Terraform AWS Provider

This time I built it with the following version.

$ terraform version
Terraform v1.0.0
on linux_amd64

Amazon Resources Created Using Terraform

A Terraform module is a set of Terraform configuration files in a single directory. Even a simple configuration consisting of a single directory with one or more .tf files is a module. When you run Terraform commands directly from such a directory, it is considered the root module

IAM Module

IAM Role and policy

AppRunner Module

Auto scaling configuration
AWS Apprunner service
AWS Apprunner github connection

Create an IAM role to grant to App Runner

Following code create IAM role and policy for Build AWS App Runner service.

The key build.apprunner.amazonaws.com is tasks.apprunner.amazonaws.com to specify and for the service to which AssumeRole is assigned.

After that, AWS has prepared a policy for App Runner, so attach it to the IAM role.

resource "aws_iam_role" "role" {
   name = "test-role"
   assume_role_policy = <<EOF 
{
   "Version": "2012-10-17",
   "Statement": [
     {
       "Action": "sts:AssumeRole",
       "Principal": {
         "Service": [
           "build.apprunner.amazonaws.com",
           "tasks.apprunner.amazonaws.com"
         ]
       },
       "Effect": "Allow",
       "Sid": ""
     }
   ]
 } EOF 
}
resource "aws_iam_role_policy_attachment" "test-attach" {
   role       = aws_iam_role.role.name
   policy_arn = "arn:aws:iam::aws:policy/service-role/AWSAppRunnerServicePolicyForECRAccess"
 }

Create an App Runner

Finally, create an App Runner resource in Terraform.

There are some App Runner related resources, but they are the main resources for actually creating App Runner aws_apprunner_service,
source_configuration

We have 2 ways to deploy App Runner with ECR repository.

Deploy App Runner with ECR private repository
Deploy App Runner with ECR public repository

Deploy App Runner with ECR private repository

resource "aws_apprunner_auto_scaling_configuration_version" "ngnix-apprunner-autoscaling" {
  auto_scaling_configuration_name = "demo_auto_scalling"
  max_concurrency = 100
  max_size        = 5
  min_size        = 1

  tags = {
    Name = "demo_auto_scalling"
  }
}

resource "aws_apprunner_service" "ngnix-apprunner-service-ecr" {
  service_name = "demo_apprunner"

  source_configuration {
    image_repository {
      image_configuration {
        port = "80"
      }
      image_identifier      = "XXXXX.dkr.ecr.us-east-2.amazonaws.com/nginx-web:latest"
      image_repository_type = "ECR"
    }
    authentication_configuration{
      access_role_arn = aws_iam_role.role.arn
    }
    auto_deployments_enabled = true
  }

  auto_scaling_configuration_arn = aws_apprunner_auto_scaling_configuration_version.ngnix-apprunner-autoscaling.arn

  health_check_configuration {
          healthy_threshold   = 1
          interval            = 10
          path                = "/"
          protocol            = "TCP"
          timeout             = 5
          unhealthy_threshold = 5
        }

  tags = {
    Name = "demo_apprunner"
  }
}

Deploy App Runner with ECR public repository

Note: In this approach we don't need IAM role.

resource "aws_apprunner_auto_scaling_configuration_version" "ngnix-apprunner-autoscaling" {
  auto_scaling_configuration_name = "demo_auto_scalling"
  max_concurrency = 100
  max_size        = 5
  min_size        = 1

  tags = {
    Name = "demo_auto_scalling"
  }
}

resource "aws_apprunner_service" "ngnix-apprunner-service-ecr-public" {
  service_name = "demo_apprunner"

  source_configuration {
    image_repository {
      image_configuration {
        port = var.port
      }
      image_identifier      = "public.ecr.aws/nginx/nginx:latest"
      image_repository_type = "ECR_PUBLIC"
    }
    auto_deployments_enabled = false
  }

  auto_scaling_configuration_arn = aws_apprunner_auto_scaling_configuration_version.ngnix-apprunner-autoscaling.arn

  health_check_configuration {
          healthy_threshold   = 1
          interval            = 10
          path                = "/"
          protocol            = "TCP"
          timeout             = 5
          unhealthy_threshold = 5
        }

  tags = {
    Name = "demo_apprunner"
  }
}

Check the URL of App Runner created by applying

I want to check the URL of the created App Runner as the execution result of the apply command, so output set.

output "app_runner_url" {
  value = aws_apprunner_service.example.service_url
}

After that, just run the following commands.

terraform init
terraform plan
terraform apply

it will take 2 to 3 minutes to complete the execution.
When the execution is completed, the URL will be displayed as shown below, so let’s access it.

app_runner_url = "xxxxx.us-east-2.awsapprunner.com/"

Thank you for reading, if you have anything to add please send a response or add a note!

Terraform — Deploy docker image on AWS AppRunner from ECR Repository

Prashant Bhatasana — Wed, 21 Jul 2021 14:16:59 +0000

In this article, we are talking about How we can deploy docker image from ECR Repository on AWS AppRunner service using terraform.

AWS App Runner is a fully managed service that makes it easy for developers to quickly deploy containerized web applications and APIs, at scale and with no prior infrastructure experience required.

Start with your source code or a container image. App Runner automatically builds and deploys the web application and load balances traffic with encryption.

App Runner also scales up or down automatically to meet your traffic needs. With App Runner, rather than thinking about servers or scaling, you have more time to focus on your applications.

App Runner Features

AWS has put a lot of effort into making things easy for developers, especially for small-scale projects that don’t need beefy infrastructure. It has:

Simple auto scaling: instances are started and stopped as demand changes, between configurable min and max limits.
Load balancing: the service includes a transparent, non-configurable load balancer.
SSL enabled: you get HTTPS endpoints for all your applications with AWS-managed certificates. You don’t need to issue or renew certificates.
Build service: you can push your own images or let AWS build them for you from code.
Persistent URLs: the service assigns randomly-generated URLs for each environment. You can optionally map them to domains of your own.

App Runner can run in two modes.

In build mode, AWS pulls code from GitHub and builds the application on every change.
In container mode, it deploys Docker-compatible images from public or private AWS ECR registries.

In this article we will using ECR public as well as private repository with App Runner deployment which mean we are using container mode.

Prerequisites

We require AWS IAM API keys (access key and secret key) for creating and deleting permissions for all AWS resources.
ECR Repository and docker image pushed on it.
Terraform should be installed on the machine. If Terraform does not exist you can download and install it from here.

version

To build AWS App Runner, you need to meet the following versions:

Terraform v0.12 or higher *Latest version of AWS provider (3.42.0) Configuring App Runner in the Terraform AWS Provider

This time I built it with the following version.

$ terraform version
Terraform v1.0.0
on linux_amd64

Amazon Resources Created Using Terraform

IAM Module

IAM Role and policy

AppRunner Module

auto scaling configuration
aws apprunner service

Create an IAM role to grant to App Runner

Set up an IAM role to build AWS App Runner.
The key build.apprunner.amazonaws.com is tasks.apprunner.amazonaws.com to specify and for the service to which AssumeRole is assigned .
After that, AWS has prepared a policy for App Runner, so attach it to the IAM role.

resource "aws_iam_role" "role" {
   name = "test-role"
   assume_role_policy = <<EOF 
{
   "Version": "2012-10-17",
   "Statement": [
     {
       "Action": "sts:AssumeRole",
       "Principal": {
         "Service": [
           "build.apprunner.amazonaws.com",
           "tasks.apprunner.amazonaws.com"
         ]
       },
       "Effect": "Allow",
       "Sid": ""
     }
   ]
 } EOF 
}
resource "aws_iam_role_policy_attachment" "test-attach" {
   role       = aws_iam_role.role.name
   policy_arn = "arn:aws:iam::aws:policy/service-role/AWSAppRunnerServicePolicyForECRAccess"
 }

Create an App Runner

Finally, create an App Runner resource in Terraform.
There are some App Runner related resources, but they are the main resources for actually creating App Runner aws_apprunner_service,
source_configuration

We have 2 ways to deploy App Runner with ECR repository.

Deploy App Runner with ECR private repository
Deploy App Runner with ECR public repository

Deploy App Runner with ECR private repository

resource "aws_apprunner_auto_scaling_configuration_version" "ngnix-apprunner-autoscaling" {
  auto_scaling_configuration_name = "demo_auto_scalling"
  max_concurrency = 100
  max_size        = 5
  min_size        = 1

  tags = {
    Name = "demo_auto_scalling"
  }
}

resource "aws_apprunner_service" "ngnix-apprunner-service-ecr" {
  service_name = "demo_apprunner"

  source_configuration {
    image_repository {
      image_configuration {
        port = "80"
      }
      image_identifier      = "XXXXX.dkr.ecr.us-east-2.amazonaws.com/nginx-web:latest"
      image_repository_type = "ECR"
    }
    authentication_configuration{
      access_role_arn = aws_iam_role.role.arn
    }
    auto_deployments_enabled = true
  }

  auto_scaling_configuration_arn = aws_apprunner_auto_scaling_configuration_version.ngnix-apprunner-autoscaling.arn

  health_check_configuration {
          healthy_threshold   = 1
          interval            = 10
          path                = "/"
          protocol            = "TCP"
          timeout             = 5
          unhealthy_threshold = 5
        }

  tags = {
    Name = "demo_apprunner"
  }
}

Deploy App Runner with ECR public repository

Note: In this approach we don't need IAM role.

resource "aws_apprunner_auto_scaling_configuration_version" "ngnix-apprunner-autoscaling" {
  auto_scaling_configuration_name = "demo_auto_scalling"
  max_concurrency = 100
  max_size        = 5
  min_size        = 1

  tags = {
    Name = "demo_auto_scalling"
  }
}

resource "aws_apprunner_service" "ngnix-apprunner-service-ecr-public" {
  service_name = "demo_apprunner"

  source_configuration {
    image_repository {
      image_configuration {
        port = var.port
      }
      image_identifier      = "public.ecr.aws/nginx/nginx:latest"
      image_repository_type = "ECR_PUBLIC"
    }
    auto_deployments_enabled = false
  }

  auto_scaling_configuration_arn = aws_apprunner_auto_scaling_configuration_version.ngnix-apprunner-autoscaling.arn

  health_check_configuration {
          healthy_threshold   = 1
          interval            = 10
          path                = "/"
          protocol            = "TCP"
          timeout             = 5
          unhealthy_threshold = 5
        }

  tags = {
    Name = "demo_apprunner"
  }
}

Check the URL of App Runner created by applying

I want to check the URL of the created App Runner as the execution result of the apply command, so output set.

output "app_runner_url" {
  value = aws_apprunner_service.example.service_url
}

After that, just run the following commands.

terraform init
terraform plan
terraform apply

it will take 2 to 3 minutes to complete the execution.
When the execution is completed, the URL will be displayed as shown below, so let’s access it.

app_runner_url = "xxxxx.us-east-2.awsapprunner.com/"

Thank you for reading, if you have anything to add please send a response or add a note!

DEV Community: Prashant Bhatasana

Terraform — Deploying Multi-Region AWS RDS Cluster with Failover Setup using Terraform

Prerequisites

→ Create a ”provider.tf”

→ Create “data.tf”

→ Create “locals.tf”

Terraform Locals vs Variables

→ Create “variables.tf”

→ Create a "terraform.tfvars

→ Create a “vpc.tf"

Terraform — AWS VPC with Private, Public Subnets with NAT | by Prashant Bhatasana | AppGambit | Medium

Prashant Bhatasana ・ Oct 9, 2020 ・ Medium

Verify the RDS Cluster Configuration

Terraform — Deploying Multi-Region AWS RDS Cluster with Failover Setup using Terraform | by Prashant Bhatasana | DevOps Pro | Medium

Prashant Bhatasana ・ May 5, 2025 ・ Medium

AWS Database Migration Service — Incremental Migration from RDS To S3

Why Use AWS DMS?

Architecture Overview

Step 1: Define Provider and Variables

Step 2: Create the S3 Bucket

Step 3: Define IAM Role for DMS

Step 4: Define DMS Endpoints

Step 5: Create a DMS Replication Instance

Step 6: Create a DMS Replication Task

Configuring the Incremental Migration

Monitoring and Managing the Migration

Terraform — Deploy Nodejs Application with AWS AppRunner

Prerequisites

Prepare a Demo NodeJS Application

Set Up Express with Node.js

Create an App Runner

Deploy App Runner with ECR private repository

Deploy App Runner with ECR public repository

Check the URL of App Runner created by applying

Terraform — Deploy docker image on AWS AppRunner from ECR Repository

App Runner Features

Prerequisites

version

Amazon Resources Created Using Terraform

Create an IAM role to grant to App Runner

Create an App Runner

Deploy App Runner with ECR private repository

Deploy App Runner with ECR public repository

Check the URL of App Runner created by applying

Prashant Bhatasana ・ Oct 9, 2020 ・
Medium

Prashant Bhatasana ・ May 5, 2025 ・
Medium