Ravindra Singh
Ask any cloud engineer what “high availability” means and you will hear a dozen answers: redundancy, failover, load balancing, fault tolerance. The truth is, it is all of them working together, and that is what makes it complex.
AWS gives you every service you need to stay online. However, when configurations are handled manually, small inconsistencies accumulate, leading to a single change that breaks what worked the day before.
Terraform fixes that problem at the source. Instead of hoping environments match, you define everything once in code and deploy it reliably every time. It is the difference between “it works on my machine” and “it works everywhere.” But how do you actually achieve that level of consistency across a full production setup?
In this guide, we will explore exactly that. You will learn how to build a full-stack, high-availability AWS architecture using Terraform. From DNS to databases, each layer will be defined, secured, and managed as code to create a resilient production foundation.
1. Why Terraform for AWS High Availability
High availability is not about adding more servers. It is about building systems that adapt, recover, and stay consistent under pressure. That is where Terraform fits in.
AWS offers the raw power through Availability Zones, managed databases, scalable storage, and security services. Terraform brings structure to that foundation. Each resource is defined as code, giving you a single, repeatable blueprint for the entire environment.
That shift from manual setup to Infrastructure as Code is what makes high availability sustainable. Whether you deploy in New York, Toronto, or Dubai, the architecture behaves identically.
1.1 Why Enterprises Prefer This Combination
Reliability: Terraform ensures consistency across regions and accounts, reducing configuration drift and minimizing downtime resulting from manual changes.
Resilience: High availability features like Auto Scaling, RDS Multi-AZ, and Route 53 failover are defined as code, ensuring predictable recovery during disruptions.
Governance: All modifications are tracked through version control, providing full visibility and auditability for compliance and security teams.
Cost Efficiency: Terraform automates scaling and provisioning rules, adjusting infrastructure intelligently to demand and preventing over-provisioning.
Terraform’s modular approach also extends to containerized environments. To see how it applies to Kubernetes, explore our guide Building an EKS Cluster with Terraform: A Modern, Modular Approach.
2. Setting Up Your Environment
Before writing any code, you need a solid foundation. A well-prepared environment keeps your Terraform deployment consistent and error-free. Think of this step as setting up the scaffolding before constructing the building.
2.1 Required Tools
Make sure these tools are installed and configured correctly on your system:
Terraform: The core of your setup. It manages infrastructure as code and keeps every deployment consistent.
AWS CLI: The command-line bridge that connects Terraform to your AWS account for authentication and service communication.
Git: Used to clone the project repository and track configuration changes through version control.
A Code Editor: Any IDE or text editor that supports Terraform syntax highlighting, such as Visual Studio Code or IntelliJ.
2.2 Verify the Setup
Once installed, verify that everything works by running these commands in your terminal:
terraform -v aws --version git --version
Each command should return a valid version number. If it does, your environment is correctly configured.
Pro Tip: Test your AWS CLI authentication at this stage. Run:
aws sts get-caller-identity
To confirm that your credentials are linked to the correct AWS account.
3. Cloning and Initializing Your Project
With the environment set up, the next step is to bring your Terraform configuration to life. This connects your local setup to the repository that contains all the Terraform files for your AWS architecture.
3.1 Clone the Repository
Clone the repository that holds your Terraform code. Each file within it defines a core part of your AWS environment, encompassing networking and storage, load balancing, and monitoring.
git clone <your-repo-url> cd <repository-directory>
This directory now acts as your blueprint for the entire infrastructure.
Before making any changes, create a dedicated Terraform workspace to isolate environments and prevent overlaps between development, staging, and production environments.
terraform workspace new dev
3.2 Initialize and Plan the Deployment
Navigate to the project directory and initialize Terraform. This command downloads the required providers and modules from the Terraform registry.
terraform init
Next, preview the infrastructure changes Terraform will make. The plan command gives you full visibility before execution.
terraform plan
Finally, apply the plan to provision resources.
terraform apply
Always review the plan output before applying changes. It helps avoid accidental resource creation or deletion.
For collaborative setups, you can save and reuse a plan file to maintain consistency across team deployments.
terraform plan -out=tfplan terraform apply tfplan
4. Understanding the Terraform Components
Each Terraform file in your project represents a building block of the architecture. Together, they create a high-availability environment that can handle failures, distribute traffic efficiently, and scale in response to demand.
At a high level, incoming traffic passes through Route 53 and AWS WAF, reaches the Application Load Balancer, and then routes requests to EC2 instances deployed across Availability Zones.
These instances connect to EFS for shared file storage, while RDS ensures database reliability with multi-zone replication. CloudWatch monitors performance, and GitHub Actions automates deployments using Terraform as the single source of truth.
4.1 DNS Configuration with Route 53
Route 53 is the first point of contact for users. It maps your domain name to the Application Load Balancer and routes traffic to healthy endpoints, even during zone-level failures.
resource "aws_route53_record" "app_record" { zone_id = data.aws_route53_zone.primary.id name = "app.example.com" type = "A" alias { name = aws_lb.app_alb.dns_name zone_id = aws_lb.app_alb.zone_id evaluate_target_health = true } }
This configuration enables intelligent DNS routing and health checks for reliable availability.
Weighted routing policies can also be used for multi-region testing or phased rollouts.
4.2 Load Balancing with ALB and WAF
The Application Load Balancer distributes traffic evenly across EC2 instances in multiple Availability Zones. AWS WAF sits in front of it, filtering incoming requests and blocking malicious activity such as DDoS or SQL injection attempts.
module "alb" { source = "terraform-aws-modules/alb/aws" version = "8.6.0" name = "app-alb" internal = false load_balancer_type = "application" security_groups = [aws_security_group.alb_sg.id] subnets = var.public_subnets } module "waf" { source = "terraform-aws-modules/wafv2/aws" version = "3.5.0" name = "app-waf" scope = "REGIONAL" rule { name = "AWSManagedRulesCommonRuleSet" priority = 1 override_action { none {} } statement { managed_rule_group_statement { name = "AWSManagedRulesCommonRuleSet" vendor_name = "AWS" } } visibility_config { cloudwatch_metrics_enabled = true metric_name = "awswaf" sampled_requests_enabled = true } } }
This combination delivers two key layers of availability: load distribution and proactive security.
Attach WAF to the ALB instead of individual instances to simplify management and maintain centralized protection.
4.3 Securing Traffic with AWS Certificate Manager
AWS Certificate Manager (ACM) handles SSL certificate creation and validation, ensuring encrypted communication between users and the application.
module "acm" { source = "terraform-aws-modules/acm/aws" version = "4.0.1" domain_name = "example.com" validation_method = "DNS" }
ACM provisions and renews certificates automatically through Route 53, removing the need for manual renewal.
4.4 Elastic Compute with Auto Scaling Groups
Auto Scaling Groups (ASGs) form the backbone of compute availability. They deploy EC2 instances across multiple zones and adjust capacity dynamically based on traffic or performance thresholds.
module "asg" { source = "terraform-aws-modules/autoscaling/aws" version = "7.4.0" name = "app-asg" launch_template = aws_launch_template.app_lt.id vpc_zone_identifier = var.private_subnets min_size = 2 max_size = 5 }
These instances connect to a shared EFS volume for persistent storage. Integrating ASG with CloudWatch
alarms allow scaling decisions to be triggered by real-time performance metrics.
4.5 Persistent Storage with EFS
Amazon Elastic File System (EFS) provides shared, scalable storage accessible by all instances in your Auto Scaling Group.
resource "aws_efs_file_system" "app_efs" { creation_token = "app-efs" encrypted = true tags = { Name = "app-efs" } }
EFS ensures data remains available even when instances are replaced or rescheduled. IAM-based authorization adds an extra layer of access control and auditability.
4.6 Database Layer with Amazon RDS
Amazon RDS provides a managed, fault-tolerant database layer with multi-AZ replication.
module "rds" { source = "terraform-aws-modules/rds/aws" version = "6.3.0" identifier = "app-db" engine = "mysql" multi_az = true allocated_storage = 20 instance_class = "db.t3.medium" }
If the primary instance fails, RDS automatically fails over to a standby instance in a different Availability Zone.
Enable encryption at rest and automated backups for production workloads.
4.7 Monitoring and Alerting with CloudWatch
Amazon CloudWatch provides complete observability. It monitors metrics such as CPU utilization, request count, and network latency, then triggers alarms when thresholds are exceeded.
resource "aws_cloudwatch_metric_alarm" "cpu_alarm_high" { alarm_name = "cpu-utilization-high" comparison_operator = "GreaterThanThreshold" evaluation_periods = "2" metric_name = "CPUUtilization" namespace = "AWS/EC2" period = "120" statistic = "Average" threshold = "80" alarm_description = "Monitors high CPU usage" alarm_actions = [aws_sns_topic.alerts.arn] }
CloudWatch integrates directly with Auto Scaling and WAF, creating a feedback loop that helps your system self-adjust to load and threats.
4.8 Continuous Deployment with GitHub Actions
GitHub Actions automates deployments by running Terraform commands whenever changes are pushed to the repository.
# .github/workflows/deploy.yml name: Terraform Deployment on: push: branches: [ "main" ] jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Setup Terraform uses: hashicorp/setup-terraform@v3 - name: Terraform Init and Apply run: | terraform init terraform plan -out=tfplan terraform apply -auto-approve tfplan
This workflow validates, plans, and applies changes automatically, reducing human error and keeping your infrastructure continuously aligned with your codebase.
5. Configuring Environment Variables
Every environment has unique parameters. What changes is not the architecture itself but how it runs. Terraform simplifies this by allowing you to define environment-specific variables that can be reused across development, staging, and production setups.
This separation lets you test safely in one environment before promoting changes to another. It also ensures consistency, as all configurations originate from a single, structured system.
5.1 Using the terraform.tfvars File
The terraform.tfvars file stores key variables such as the environment name, region, subnets, and database configuration. It helps define values specific to each deployment while keeping the core code unchanged.
environment = "production" region = "us-east-1" public_subnets = ["subnet-xxxxxx", "subnet-yyyyyy"] private_subnets = ["subnet-zzzzzz", "subnet-aaaaaa"] db_instance_type = "db.t3.medium"
You can create multiple .tfvars files for different environments and switch between them using workspaces or command-line flags. Maintaining consistent variable names across these files reduces confusion and prevents deployment errors.
5.2 Managing Sensitive Data Securely
Sensitive data like credentials or database passwords should never be stored directly in .tfvars files. Use AWS Secrets Manager or Terraform Cloud variables to store them securely.
Here’s an example of referencing a secret dynamically:
data "aws_secretsmanager_secret_version" "db_password" { secret_id = "prod/db_password" } variable "db_password" { description = "Database password" default = data.aws_secretsmanager_secret_version.db_password.secret_string }
This method keeps sensitive information encrypted, audit-friendly, and compliant with enterprise security standards. Credentials should also be rotated periodically, with IAM policies restricted to the least privileges required.
6. Verifying and Accessing the Deployment
After applying your Terraform configuration, it’s essential to confirm that all components are working together as intended. Verification ensures that your high-availability setup isn’t just deployed but also resilient and production-ready.
6.1 DNS and Load Balancer Validation
Start by confirming that Route 53 correctly routes your domain to the Application Load Balancer. Run a DNS lookup to verify resolution:
dig app.example.com
If the ALB’s DNS name appears, your routing and records are configured correctly. You can also add Route 53 health checks to automatically detect endpoint failures and reroute traffic when needed.
6.2 Auto Scaling and Instance Health
Next, verify that your Auto Scaling Group is distributing EC2 instances evenly across Availability Zones. Each instance should appear as Healthy in the ALB target group.
If any instances fail health checks, review the startup scripts, security groups, and IAM roles attached to the instance profile. These are common sources of configuration drift.
Use CloudWatch alarms linked to Auto Scaling metrics to monitor instance health and detect replacements or anomalies early.
6.3 Database Availability
Open the RDS console and confirm that your database is configured for Multi-AZ deployment. The secondary instance should be available, and replication should be in sync. You can also validate this using the AWS CLI:
aws rds describe-db-instances \ --query "DBInstances[*].{Name:DBInstanceIdentifier,MultiAZ:MultiAZ,Status:DBInstanceStatus}"
For added reliability, test failover in a staging environment to ensure seamless recovery during actual downtime events.
6.4 Monitoring and Logs
Finally, check your CloudWatch dashboards to verify that all key metrics and alarms are active for EC2, RDS, and ALB. Logs should be streaming continuously, and alarms should remain in an OK state under normal conditions.
For long-term analysis or compliance, forward CloudWatch logs to Amazon S3 or OpenSearch. This makes it easier to troubleshoot incidents and maintain visibility across distributed systems.
7. Troubleshooting and Best Practices
Even with Terraform automating most of the setup, small configuration gaps can still affect performance or reliability. Knowing what to check and how to correct issues quickly helps maintain a stable, production-grade environment.
7.1 Common Issues
Unhealthy Instances
If EC2 instances remain in an unhealthy state, review Auto Scaling health checks and application startup scripts. Ensure ports are open in the security groups and that EFS mounts or app dependencies initialize correctly.
Certificate Validation Stuck
If your ACM certificate remains in Pending validation, check Route 53 to confirm that DNS validation records were created automatically and match the ACM validation domain.
Slow Database Failover
If RDS failover takes longer than expected, verify that Multi-AZ replication is synchronous and configured correctly. Check CloudWatch alarms to ensure they trigger promptly during downtime events.
Access Denied Errors
Access issues usually stem from missing IAM permissions. Review instance profiles, Lambda roles, or Terraform execution roles to confirm that required policies are attached and correctly scoped.
7.2 Best Practices
Plan Before You Apply
Always run terraform plan before terraform apply. Reviewing the plan helps you catch unwanted changes and maintain operational safety.
Use a Remote State Backend
Store Terraform state files in an S3 bucket with versioning enabled, and pair it with DynamoDB for state locking. This prevents concurrent updates and ensures consistency across the entire team.
Separate Environments
Use dedicated Terraform workspaces or directories for development, staging, and production. Isolation prevents unintentional cross-environment changes.
Tag Resources Consistently
Apply standardized tags to all resources. Tags simplify cost tracking, governance, and compliance reporting.
Enable Continuous Monitoring
Create CloudWatch dashboards and alarms to track CPU, latency, and error metrics. Early detection helps prevent small issues from escalating into outages.
8. Conclusion
Building a high-availability setup is not just about automation. It is about creating systems that stay consistent, recover quickly, and evolve seamlessly as demands grow. Terraform makes this possible by turning complex AWS architectures into predictable, code-defined frameworks that scale with your business.
With this approach, every layer from DNS to databases operates with the same reliability across regions. You gain the confidence to deploy, recover, and expand without disruption, knowing that your environment behaves exactly as designed.
At Coditas, we design and implement AWS architectures that combine performance, governance, and resilience to deliver optimal results. Our teams help enterprises move beyond manual configuration to infrastructure that is self-governing, auditable, and ready for continuous growth.
Interested in seeing this architecture as a complete Terraform module on GitHub? Let us know in the comments, and we will make it available.
References:
https://dev.to/aws-builders/-a-full-stack-aws-architecture-using-terraform-ensuring-high-availability-in-aws-5h31
