Terminologies & Use Cases:

• Amazon CloudFront: CloudFront optimizes WordPress performance by caching and delivering static content from edge locations, reducing latency and offloading traffic from origin servers. It enhances scalability, security, and user experience by serving content closer to end-users and supporting HTTPS encryption for data privacy. This is a free-tier project, so route53 was not configured.
• Amazon S3: Amazon S3 serves as a reliable storage solution for media content and Terraform state files. S3 efficiently stores and retrieves media assets such as images and videos, ensuring seamless delivery to users while reducing the load on the WordPress application servers. Additionally, S3 securely stores Terraform state files, enabling collaborative infrastructure management and ensuring consistency across deployments.
• Amazon DynamoDB: DynamoDB is used for Terraform state locking. It ensures exclusive access during infrastructure updates, enhancing reliability and preventing conflicts.
• NAT Gateway: A NAT Gateway is employed to facilitate outbound internet traffic from private subnets in the AWS environment. It acts as a central gateway for instances in private subnets to access resources outside the AWS network while maintaining security through Network Address Translation (NAT).
• Availability Zones: Availability Zones (AZs) are utilized for deploying resources across multiple isolated locations within an AWS region. By distributing resources across different AZs, the project ensures high availability and fault tolerance. In case of failure in one AZ, resources in other zones continue to function, minimizing downtime and ensuring uninterrupted service.
• VPC: A Virtual Private Cloud (VPC) is employed as the networking foundation within the AWS environment. The VPC enables the creation of isolated virtual networks, allowing fine-grained control over network configurations, including IP address ranges, subnets, route tables, and network gateways.
• Subnets: Public subnets facilitate internet-facing services, while private subnets ensure the confidentiality and integrity of internal resources.
• AutoScaling Groups: Autoscaling Groups are a critical component of this project, enabling automatic scaling of EC2 instances based on predefined conditions such as CPU utilization or traffic load. By configuring Autoscaling Groups, infrastructure can dynamically adjust to meet demand, scaling out during periods of high traffic and scaling in during quieter times.
• Application LoadBalancer: ALB operates at the application layer (Layer 7) of the OSI model, allowing it to route traffic based on content within the HTTP request, such as URL paths or hostnames. ALB seamlessly integrates with other AWS services like Autoscaling Groups and AWS Certificate Manager, enhancing the project’s overall infrastructure and security posture. Its built-in health checks monitor the health of backend instances, automatically routing traffic away from unhealthy instances to maintain optimal application availability.
• Amazon Elasticache (MemCached): Amazon ElastiCache for Memcached optimizes application performance by caching frequently accessed data in memory. It reduces latency, improves scalability by offloading database read operations, and ensures high availability with automatic cluster scaling.
• Amazon Aurora (MySQL): Amazon Aurora for MySQL serves as the relational database solution, offering high performance, scalability, and reliability for storing application data. Aurora’s distributed architecture enhances resilience and fault tolerance, ensuring continuous availability and data durability.
• Amazon Elastic FileSystem (EFS): Amazon Elastic File System (EFS) is utilized as a scalable and highly available file storage solution for the application. EFS provides a shared file system accessible by multiple EC2 instances, enabling data sharing and collaboration across the application infrastructure. By leveraging EFS, the project ensures data consistency and durability, with automatic scalability to accommodate growing storage needs.
• Amazon CloudWatch: Amazon CloudWatch is utilized to monitor the CPU utilization of the Autoscaling Groups. CloudWatch collects and tracks metrics related to CPU usage across the EC2 instances within the Autoscaling Group. By setting up CloudWatch alarms based on predefined thresholds for CPU utilization, the project ensures proactive monitoring of resource usage using CloudWatch alarms based on predefined thresholds for CPU utilization ensuring proactive monitoring of resource usage.
• Amazon SNS: In this project, Amazon Simple Notification Service (SNS) is used to notify subscribers based on the CloudWatch alarms triggered by CPU utilization metrics. When CloudWatch detects CPU utilization exceeding or falling below predefined thresholds for Autoscaling Groups, it sends notifications to the SNS topic which is then delivered to subscribers of the topic.
• AWS Systems Manager: In this project, AWS Systems Manager (SSM) manages instance profiles for EC2 instances, configures Amazon EFS mount points, and securely distributes credentials for accessing the Amazon S3 bucket containing media content.

Pre-requisites:

• Code Editor: Visual Studio Code (preferred)
• AWS CLI v2 configured with your IAM credentials for programmatic access
• Terraform CLI

File Structure:

.
├── modules
│   ├── aurora
│   │   ├── main.tf
│   │   ├── output.tf
│   │   ├── securitygroup.tf
│   │   └── variables.tf
│   ├── cloudfront
│   │   ├── main.tf
│   │   ├── output.tf
│   │   └── variables.tf
│   ├── efs
│   │   ├── main.tf
│   │   ├── output.tf
│   │   ├── securitygroup.tf
│   │   └── variables.tf
│   ├── elasticache
│   │   ├── main.tf
│   │   ├── output.tf
│   │   ├── securitygroup.tf
│   │   └── variables.tf
│   ├── loadbalancer
│   │   ├── main.tf
│   │   ├── output.tf
│   │   └── variables.tf
│   ├── securitygroup
│   │   ├── main.tf
│   │   ├── output.tf
│   │   └── variables.tf
│   ├── vpc
│   │   ├── main.tf
│   │   ├── output.tf
│   │   └── variables.tf
│   └── wordpress
│       ├── main.tf
│       ├── output.tf
│       └── variables.tf
├── scripts
│   └── init-aml2.sh
├── backend.tf
├── backend_resource.tf
├── buckets.tf
├── cloudwatch.tf
├── data.tf
├── iam.tf
├── main.tf
├── output.tf
├── providers.tf
├── sns.tf
├── terraform.tfvars
└── variables.tf

Terraform Deployment Procedures: The standard to deploy terraform configuration files include:

• Writing Configuration: Create Terraform configuration files (.tf) defining the desired infrastructure resources, including providers, resources, and configurations.
• Initializing Terraform: Run terraform init in the directory containing the configuration files. This command initializes the working directory, downloads provider plugins, and prepares the environment for Terraform operations.
• Planning Deployment: Run terraform plan to generate an execution plan. Terraform compares the desired state defined in the configuration files with the current state of the infrastructure and identifies the changes required to achieve the desired state.
• Applying Changes: Run terraform apply to apply the execution plan and provision or modify the infrastructure resources accordingly. Terraform interacts with the cloud provider's API to create, update, or delete resources as necessary.
• Review and Confirm: Terraform prompts for confirmation before making any changes to the infrastructure. Review the execution plan and confirm the changes to proceed with deployment.
• Monitor and Manage: After deployment, Terraform tracks the state of the infrastructure. Use commands like terraform show and terraform state to inspect the current state, and terraform destroy to remove the provisioned resources if needed.

Understanding the Code:

In the providers.tf configuration, the version, and the source of the required provider are defined within the Terraform block, specifying that the “hashicorp/aws” provider, version “~> 5.0,” is necessary. The provider block configures the AWS provider with the specified region dynamically set to the value of the “var.region” variable.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.region
}

The backend.tf configuration file is specified to use Amazon S3 as the storage backend. The configuration includes settings for the S3 bucket, the key within the bucket where state files are stored, the AWS region where the bucket resides, the DynamoDB table used for state locking, and enabling encryption for data at rest within the S3 bucket.

terraform {
  backend "s3" {
    bucket         = "terraform-state-demo-wp"
    key            = "wordpress-state/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "state-lock-db"
    encrypt        = true
  }
}

The backend_resource.tf configuration includes the creation of two essential resources. Firstly, it defines a DynamoDB table named “terraform_lock” to serve as a state lock mechanism, ensuring safe concurrent access to Terraform state files. This table is configured with attributes such as billing mode and hash key, and it’s set to prevent accidental deletion. Secondly, it establishes an S3 bucket named “terraform_state” for storing Terraform state files securely. This bucket’s configuration includes enabling server-side encryption and versioning to enhance data protection and facilitate version management.

resource "aws_dynamodb_table" "terraform_lock" {
  name         = var.dynamodb_table
  billing_mode = var.billing_mode
  hash_key     = var.hash_key
  attribute {
    name = var.attribute_name
    type = var.attribute_type
  }
  lifecycle {
    prevent_destroy = true
  }
}

resource "aws_s3_bucket" "terraform_state" {
  bucket        = var.backend_bucket
  force_destroy = true
  lifecycle {
    prevent_destroy = true
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "bucket_encryption" {
  bucket = aws_s3_bucket.terraform_state.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_s3_bucket_versioning" "bucket_version" {
  bucket = aws_s3_bucket.terraform_state.id
  versioning_configuration {
    status = "Enabled"
  }
}

The buckets.tf configuration creates an S3 bucket named “bucket” with the specified name from the “var.object_bucket” variable. The bucket’s configuration includes enabling force destroy to allow for deletion even if non-empty. It sets up bucket ACL (Access Control List) to “private” for restricted access, and it ensures bucket ownership controls are configured to “BucketOwnerPreferred.” Furthermore, the configuration encrypts the bucket’s contents using SSE-S3 (Server-Side Encryption) with AES256 encryption algorithm for enhanced security.

resource "aws_s3_bucket" "bucket" {
  bucket        = var.object_bucket
  force_destroy = true
}

resource "aws_s3_bucket_acl" "bucket_acl" {
  bucket = aws_s3_bucket.bucket.id
  acl    = "private"

  depends_on = [aws_s3_bucket_ownership_controls.ownership]
}

resource "aws_s3_bucket_ownership_controls" "ownership" {
  bucket = aws_s3_bucket.bucket.id
  rule {
    object_ownership = "BucketOwnerPreferred"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "encrypt" {
  bucket = aws_s3_bucket.bucket.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

The cloudwatch.tf configuration file defines a CloudWatch metric alarm named “ec2_cpu_alarm” to monitor CPU utilization of EC2 instances. The alarm is set to trigger when the CPU utilization exceeds or equals the threshold of 80% over a period of 2 evaluation periods, each lasting for 60 seconds. It uses the “Average” statistic to evaluate the metric. The alarm description provides information about its purpose, and it specifies that missing data should not be considered breaching. When triggered, the alarm sends notifications to an SNS topic defined in “aws_sns_topic.topic.arn”. The alarm is also associated with the Auto Scaling Group named “module.app.app_asg_name” to monitor CPU utilization across EC2 instances within the group.

resource "aws_cloudwatch_metric_alarm" "ec2_cpu_alarm" {

  comparison_operator = "GreaterThanOrEqualToThreshold"
  evaluation_periods  = "2"
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = "60"
  statistic           = "Average"
  threshold           = "80"
  alarm_description   = "This metric monitors ec2 cpu utilization"
  treat_missing_data  = "notBreaching"
  alarm_actions       = [aws_sns_topic.topic.arn]
  
  alarm_name = "cpu-utilization"
  dimensions = {
    AutoScalingGroupName = module.app.app_asg_name
  } 
}

The iam.tf configuration file sets up several AWS IAM (Identity and Access Management) resources to manage permissions for a WordPress application. Firstly, it defines an IAM role named “WordPressExecutionRole” with permissions to assume roles for EC2 instances. Then, it attaches policies to this role to allow actions related to Systems Manager (SSM), Amazon Elastic File System (EFS), Amazon S3, and Amazon CloudWatch Logs. These policies grant necessary permissions for the WordPress application to interact with AWS services securely. It also creates an IAM instance profile named “wordpress-instance-profile” associated with the WordPressExecutionRole, enabling EC2 instances to assume this role and access AWS resources based on defined policies.

resource "aws_iam_instance_profile" "instance_profile" {
  name = "wordpress-instance-profile"
  role = aws_iam_role.wordpress_execution_role.name
}

resource "aws_iam_role" "wordpress_execution_role" {
  name = "WordPressExecutionRole"

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

resource "aws_iam_role_policy" "efs_execution_role_policy" {
  name = "EFSFileSystemUtils"
  role = aws_iam_role.wordpress_execution_role.id
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Action = [
          "ssm:DescribeAssociation",
          "ssm:GetDeployablePatchSnapshotForInstance",
          "ssm:GetDocument",
          "ssm:DescribeDocument",
          "ssm:GetManifest",
          "ssm:GetParameter",
          "ssm:GetParameters",
          "ssm:ListAssociations",
          "ssm:ListInstanceAssociations",
          "ssm:PutInventory",
          "ssm:PutComplianceItems",
          "ssm:PutConfigurePackageResult",
          "ssm:UpdateAssociationStatus",
          "ssm:UpdateInstanceAssociationStatus",
          "ssm:UpdateInstanceInformation"
        ],
        Resource = "*"
      },
      {
        Effect = "Allow",
        Action = [
          "ssmmessages:CreateControlChannel",
          "ssmmessages:CreateDataChannel",
          "ssmmessages:OpenControlChannel",
          "ssmmessages:OpenDataChannel"
        ],
        Resource = "*"
      },
      {
        Effect = "Allow",
        Action = [
          "ec2messages:AcknowledgeMessage",
          "ec2messages:DeleteMessage",
          "ec2messages:FailMessage",
          "ec2messages:GetEndpoint",
          "ec2messages:GetMessages",
          "ec2messages:SendReply"
        ],
        Resource = "*"
      },
      {
        Effect = "Allow",
        Action = [
          "elasticfilesystem:DescribeMountTargets"
        ],
        Resource = "*"
      },
      {
        Effect = "Allow",
        Action = [
          "ec2:DescribeAvailabilityZones"
        ],
        Resource = "*"
      },
      {
        Effect = "Allow",
        Action = [
          "logs:PutLogEvents",
          "logs:DescribeLogStreams",
          "logs:DescribeLogGroups",
          "logs:CreateLogStream",
          "logs:CreateLogGroup",
          "logs:PutRetentionPolicy"
        ],
        Resource = "*"
      }
    ]
  })
}

resource "aws_iam_role_policy" "ssm_execution_role_policy" {
  name = "SSMManagedInstanceCore"
  role = aws_iam_role.wordpress_execution_role.id
  policy = jsonencode({

    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Action = [
          "ssm:DescribeAssociation",
          "ssm:GetDeployablePatchSnapshotForInstance",
          "ssm:GetDocument",
          "ssm:DescribeDocument",
          "ssm:GetManifest",
          "ssm:GetParameter",
          "ssm:GetParameters",
          "ssm:ListAssociations",
          "ssm:ListInstanceAssociations",
          "ssm:PutInventory",
          "ssm:PutComplianceItems",
          "ssm:PutConfigurePackageResult",
          "ssm:UpdateAssociationStatus",
          "ssm:UpdateInstanceAssociationStatus",
          "ssm:UpdateInstanceInformation"
        ],
        Resource = "*"
      },
      {
        Effect = "Allow",
        Action = [
          "ssmmessages:CreateControlChannel",
          "ssmmessages:CreateDataChannel",
          "ssmmessages:OpenControlChannel",
          "ssmmessages:OpenDataChannel"
        ],
        Resource = "*"
      },
      {
        Effect = "Allow",
        Action = [
          "ec2messages:AcknowledgeMessage",
          "ec2messages:DeleteMessage",
          "ec2messages:FailMessage",
          "ec2messages:GetEndpoint",
          "ec2messages:GetMessages",
          "ec2messages:SendReply"
        ],
        Resource = "*"
      }
    ]
  })
}

resource "aws_iam_role_policy" "s3_bucket_policy" {
  name = "S3FullAccess"
  role = aws_iam_role.wordpress_execution_role.id
  policy = jsonencode({

    Version = "2012-10-17",
    Statement = [{
      Effect = "Allow",
      Action = [
        "s3:*",
        "s3-object-lambda:*"
      ],
      Resource = "*"
    }]
  })
}

The sns.tf configuration file creates an AWS SNS (Simple Notification Service) topic named “CPUUtilizationAlarm” with the specified name and tags. Additionally, it defines an SNS topic subscription for email notifications, with the count determined by the length of the provided email addresses. The subscription associates each email address with the SNS topic, enabling email notifications to be sent to the specified recipients when events are published to the topic.

resource "aws_sns_topic" "topic" {
  name = "CPUUtilizationAlarm"
  tags = {
    Name = "TestAlarm"
  }
}

resource "aws_sns_topic_subscription" "email_subscription" {
  count     = length(var.email_address)
  topic_arn = aws_sns_topic.topic.arn
  protocol  = "email"
  endpoint  = var.email_address[count.index]
}

The main.tf configuration file defines the infrastructure deployment for the WordPress application on AWS, organized into modular components. Here’s the breakdown of the code below:

locals {
  availability_zone_a = data.aws_availability_zones.availability_zones.names[0]
  availability_zone_b = data.aws_availability_zones.availability_zones.names[1]
}

module "app" {
  source = "./modules/wordpress"

  instance_type          = var.app_instance_type
  image_id               = data.aws_ami.amazon_linux_2_latest.id
  vpc_security_group_ids = ["${module.app.app_security_group_id}"]
  user_data = base64encode("${templatefile("${path.module}/scripts/init-aml2.sh", {
    DB_HOST     = "${module.database.rds_endpoint}"
    DB_NAME     = "${module.database.rds_database_name}"
    DB_PASSWORD = "${module.database.rds_password}"
    DB_USER     = "${module.database.rds_username}"
    EFS_ID      = "${module.filesystem.efs_id}"
  })}")

  target_group_arns     = [module.loadbalancer.target_group_arn]
  vpc_zone_identifier   = [module.vpc.private_subnet_a, module.vpc.private_subnet_b]
  security_group_vpc_id = module.vpc.vpc_id
  iam_arn               = aws_iam_instance_profile.instance_profile.arn

  depends_on = [module.database.rds_cluster_instances, module.filesystem.efs_filesystem, module.cache.cache_cluster]
}

module "database" {
  source = "./modules/aurora"

  master_username          = var.db_username
  master_password          = var.db_password
  vpc_security_group_ids   = [module.database.db_security_group_id]
  source_security_group_id = module.app.app_security_group_id
  subnet_ids               = [module.vpc.private_subnet_c, module.vpc.private_subnet_d]
  availability_zones       = [local.availability_zone_a, local.availability_zone_b]
  vpc_id                   = module.vpc.vpc_id
  security_group_id        = module.database.db_security_group_id
}

module "cache" {
  source = "./modules/elasticache"

  security_group_id        = module.cache.cache_security_group_id
  source_security_group_id = module.app.app_security_group_id
  security_group_ids       = [module.cache.cache_security_group_id]
  cache_subnets            = [module.vpc.private_subnet_c, module.vpc.private_subnet_d]
  vpc_id                   = module.vpc.vpc_id
  availability_zones       = [local.availability_zone_a, local.availability_zone_b]
}

module "filesystem" {
  source = "./modules/efs"

  subnet_a                 = module.vpc.private_subnet_c
  subnet_b                 = module.vpc.private_subnet_d
  vpc_id                   = module.vpc.vpc_id
  security_group_id        = module.filesystem.fs_security_group_id
  source_security_group_id = module.app.app_security_group_id
  security_groups          = [module.filesystem.fs_security_group_id]
}

module "loadbalancer" {
  source = "./modules/loadbalancer"

  subnets               = [module.vpc.public_subnet_a, module.vpc.public_subnet_b]
  security_groups       = ["${module.loadbalancer.loadbalancer_security_group_id}"]
  vpc_id                = module.vpc.vpc_id
  security_group_vpc_id = module.vpc.vpc_id
}

module "cloudfront" {
  source = "./modules/cloudfront"

  domain_name = module.loadbalancer.loadbalancer_dns
  origin_id   = module.loadbalancer.loadbalancer_dns
}


module "vpc" {
  source = "./modules/vpc"

  az_a = local.availability_zone_a
  az_b = local.availability_zone_b
}

1. Locals Block: Defines local variables availability_zone_a and availability_zone_b representing the first two availability zones in the AWS region.

2. “app” Module: Deploys the WordPress application using a custom module located in ./modules/wordpress
 — Configures instance type, AMI image ID, security groups, user data for EC2 instances, target group ARNs, VPC subnets, and IAM role.

3. “database” Module: Deploys an Aurora database using a custom module located in ./modules/auora
 — Configures master username, password, security groups, subnets, availability zones, and VPC.

4. “cache” Module: Deploys an ElastiCache cluster using a custom module located in ./modules/elasticache
 — Configures security groups, subnets, availability zones, and VPC.

5. “filesystem” Module: Deploys an Amazon EFS filesystem using a custom module located in ./modules/efs
 — Configures subnets, security groups, and VPC.

6. “loadbalancer” Module: Deploys an Application Load Balancer using a custom module located in ./modules/loadbalancer
 — Configures subnets, security groups, and VPC.

7. “cloudfront” Module: Deploys an Amazon CloudFront distribution using a custom module located in ./modules/cloudfront
 — Configures the domain name and origin ID.

8. “vpc” Module: Deploys the VPC infrastructure using a custom module located in ./modules/vpc
 — Configures availability zones.

The data.tf configuration defines two data sources that are defined to retrieve information from AWS: “aws_availability_zones” and “aws_ami.” The “aws_availability_zones” data source fetches information about available availability zones, specifying the state as “available.” The “aws_ami” data source retrieves the latest Amazon Linux 2 AMI (Amazon Machine Image) owned by Amazon, filtering by name and architecture to match the specified criteria.

data "aws_availability_zones" "availability_zones" {
  state = "available"
}

data "aws_ami" "amazon_linux_2_latest" {
  owners = ["amazon"]

  most_recent = true

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }
}

In the output.tf configuration file we’ve set up two friendly outputs to make managing your deployment a breeze. The first output, the Load Balancer URL, serves as your website’s welcoming entrance, providing the DNS name where visitors can access your site. It’s like the front door to your online space! The second output, the CloudFront URL, acts as a magic carpet ride for your site, ensuring it’s lightning-fast and accessible worldwide.

output "loadbalancer" {
  value = module.loadbalancer.loadbalancer_dns
}

output "cloudfront_url" {
  value = module.cloudfront.cloudfront_url
}

The init-aml2.sh script helps in getting WordPress up and running smoothly on your Amazon Linux 2 EC2 instance. It takes care of everything from installing necessary packages to configuring Memcached for faster performance. Plus, it seamlessly integrates with Amazon EFS for shared storage and ensures your WordPress site is ready to shine with Apache and PHP. With just a few steps, your WordPress environment will be optimized and ready for action!

#!/bin/bash

# Assign environment variables to local variables
DB_HOST="${DB_HOST}"
DB_NAME="${DB_NAME}"
DB_PASSWORD="${DB_PASSWORD}"
DB_USER="${DB_USER}"
EFS_ID="${EFS_ID}"
FILE="/var/www/html/latest.tar.gz"

# Update the system and install necessary packages
sudo yum update -y
sudo yum install -y amazon-efs-utils
sudo yum install -y nfs-utils
sudo mkdir -p /var/www/html/
sudo mount -t efs -o tls $EFS_ID:/ /var/www/html

# Install and start Memcached
sudo yum install memcached -y
sudo systemctl start memcached
sudo systemctl enable memcached

# Install Apache, PHP, and related packages
sudo yum install -y httpd
sudo yum remove -y php*
sudo yum clean -y all
sudo amazon-linux-extras enable php8.0 memcached1.5
sudo yum clean -y metadata
sudo yum install -q -y php php-gd php-mysqli php-cli php-fpm php-opcache php-common
sudo yum install -y php-xml
sudo yum install -y gcc make php php-pear php-devel libmemcached libmemcached-devel zlib-devel memcached
sudo pecl update-channels
"echo n n n n n n y y" | sudo pecl install memcached

# Start Apache web server
sudo systemctl start httpd
sudo systemctl enable httpd

# Download and configure WordPress
if [[ -e $FILE ]]; then
    sleep 300
else  
    cd /var/www/html
    sudo wget https://wordpress.org/latest.tar.gz
    sudo tar -xzvf latest.tar.gz
    sudo cp -r wordpress/* .
    cd ..
    sudo chown -R apache:apache html
    cd ./html
    sudo rm -rf wordpress/
    sudo rm -rf latest.tar.gz
    sudo cp wp-config-sample.php wp-config.php
    sudo chown -R apache:apache wp-config.php
    cat <<EOT >> credfile.txt
define( 'AS3CF_SETTINGS', serialize( array (
    'provider' => 'aws',
    'use-server-roles' => true,
) ) );
EOT
    sudo sed -i "s/database_name_here/$DB_NAME/" wp-config.php
    sudo sed -i "s/username_here/$DB_USER/" wp-config.php
    sudo sed -i "s/password_here/$DB_PASSWORD/" wp-config.php
    sudo sed -i "s/localhost/$DB_HOST/" wp-config.php
    sudo sed -i "/define( 'WP_DEBUG', false );/r credfile.txt" wp-config.php
    sudo rm credfile.txt
fi

# Add Memcached extension to PHP configuration
echo extension=memcached.so | sudo tee -a /etc/php.ini

# Restart Apache to apply changes
sudo systemctl restart httpd

Results:

In this section, we will visually explore the outcome of the deployment of our infrastructure. Also, we will set up our WordPress deployment for caching with the “W3TC” plugin to improve database performance and offload static content from our EC2 instance storage(EBS) utilizing the high availability and redundancy of S3 using the “WP Offload Media Lite” plugin.

Conclusion: Incorporating Terraform into the process of building a highly available WordPress application on AWS further enhances efficiency and consistency. With Terraform’s infrastructure as code approach, developers can define and manage the entire AWS environment, including EC2 instances, RDS databases, CloudFront distributions, and Auto Scaling configurations, using simple and repeatable code. This enables rapid deployment, easy replication across multiple environments, and streamlined maintenance of the infrastructure. By abstracting away the manual configuration steps and automating the provisioning process, Terraform ensures that the infrastructure is consistently deployed in a highly available configuration, minimizing human error and enabling seamless scalability.

This code showcases a basic implementation of Terraform as an IaC tool. Terraform is powerful and to further improve this code, community modules and the DRY principle may be implemented.

Thank you for taking the time to read my blog! If you have any questions or comments, I would love to hear from you. Please feel free to reach out to me through any of the following channels:

Email: cloudsenseing@gmail.com
Social media: LinkedIn or Twitter

I am passionate about the topics I write about, and I am always eager to engage with my readers. If you have a suggestion for a future blog post, or if you would like to collaborate on a project, please do not hesitate to get in touch. I will do my best to respond to all inquiries as quickly as possible.

References:

• AWS Terraform Provider Guide: https://registry.terraform.io/providers/hashicorp/aws/latest/docs
• Reference Architecture — Best Practices for WordPress on AWS: https://docs.aws.amazon.com/whitepapers/latest/best-practices-wordpress/reference-architecture.html

Cloud Project 1: Deploying a Highly Available WordPress Architecture on AWS with Terraform was originally published in Towards AWS on Medium, where people are continuing the conversation by highlighting and responding to this story.