In the journey of setting up WordPress on AWS using Terraform, we’ve covered crucial aspects like VPC, subnets, security groups, and more. Now, let’s dive into Elastic File System (EFS), a scalable and fully managed file storage service in AWS. EFS provides a shared storage solution that can be easily accessed by multiple instances, making it an excellent choice for applications that require shared file storage. We will use EFS to share our WordPress files across our ec2 instance. To understand more about EFS checkout https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html

What is EFS?

Amazon Elastic File System (EFS) is a scalable file storage service that can grow and shrink based on demand. It provides a simple interface that allows you to create and configure file systems quickly. EFS supports the Network File System version 4 (NFSv4) protocol, making it compatible with Linux-based instances.

Key Features of AWS EFS

  1. Scalability: EFS can grow and shrink automatically based on your storage needs. Whether you have a small application or a large-scale system, EFS scales seamlessly to accommodate your data.
  2. Elasticity: With EFS, you pay only for the storage you use. There are no pre-allocated sizes, and the file system automatically adjusts to the amount of data stored.
  3. Shared Access: EFS supports concurrent access by multiple EC2 instances. This makes it suitable for applications that require shared access to files, such as content management systems, development environments, and data analytics workloads.
  4. High Availability: EFS is designed for high availability, with data stored across multiple Availability Zones within a region. This ensures durability and fault tolerance for your files.

Terraform Configuration

Now, let’s modify out terraform code in main.tf, add the snippet to create an EFS instance along with backup policies and network access:

# EFS
resource "aws_efs_file_system" "dev-efs" {
  creation_token   = "development"
  performance_mode = "generalPurpose"
  throughput_mode  = "elastic"

  lifecycle_policy {
    transition_to_ia = "AFTER_30_DAYS"
  }

  tags = {
    Name = "dev-efs"
    env  = "dev"
  }
}

#  back up policy
resource "aws_efs_backup_policy" "policy" {
  file_system_id = aws_efs_file_system.dev-efs.id

  backup_policy {
    status = "ENABLED"
  }
}

# Network access and Mount targets
resource "aws_efs_mount_target" "dev_efs_mount_target_AZ1" {
  file_system_id  = aws_efs_file_system.dev-efs.id
  subnet_id       = aws_subnet.dev-private-data-subnet-AZ1.id
  security_groups = [aws_security_group.dev-efs_security_group.id]
}

resource "aws_efs_mount_target" "dev_efs_mount_target_AZ2" {
  file_system_id  = aws_efs_file_system.dev-efs.id
  subnet_id       = aws_subnet.dev-private-data-subnet-AZ2.id
  security_groups = [aws_security_group.dev-efs_security_group.id]
}

Breakdown of the Terraform Code:

  • EFS File System: The aws_efs_file_system resource creates an EFS file system with specified configurations such as the creation token, performance mode, throughput mode, and lifecycle policy.
  • Backup Policy: The aws_efs_backup_policy resource defines a backup policy for the EFS file system, enabling regular backups.
  • Mount Targets: Two aws_efs_mount_target resources create mount targets in different subnets, providing network access to the EFS file system. Each mount target is associated with a specific subnet in specify Availability Zone (AZ) and security group, security group from previous post (dev-efs_security_group).

Apply changes:

terraform apply

Check AWS Console.

Current architecture

Remember to destroy resources at the end of the tutorial..

terraform destroy

Categorized in: