Déployer un cluster Amazon Aurora MySQL avec Terraform

Cette arborescence est pensée pour organiser et gérer efficacement le code Terraform nécessaire au déploiement d'un cluster Amazon Aurora MySQL avec un chiffrement assuré par AWS KMS.

Répertoire racine

Comprend main.tf, providers.tf, terraform.tfvars, variables.tf et outputs.tf.

• main.tf : contient la configuration principale qui appelle les modules.
• providers.tf : définit les paramètres du provider et les versions requises.
• variables.tf : déclare les variables utilisées dans l'ensemble des configurations.
• terraform.tfvars : définit les valeurs de remplacement pour les variables déclarées ailleurs.
• outputs.tf : définit les sorties de la configuration Terraform.

Répertoire des modules

Contient un sous-répertoire pour chaque module distinct du projet.

Module KMS : prend en charge la création et la gestion des clés AWS KMS qui chiffrent les données au repos.

• main.tf : contient les ressources de création des clés KMS.
• variables.tf : définit les variables d'entrée propres à KMS.
• outputs.tf : expose les attributs en sortie des ressources KMS.

Module Aurora Cluster : pilote le déploiement du cluster Aurora MySQL.

• main.tf : configure le cluster Aurora MySQL et ses ressources associées.
• variables.tf : recense les variables d'entrée propres au cluster Aurora MySQL.
• outputs.tf : expose des attributs comme l'endpoint de la base de données.

Cette structure garantit une base de code propre et bien organisée, tout en améliorant la réutilisabilité et la maintenabilité du code Terraform, pour une gestion plus efficace des ressources cloud.

Le chiffrement au repos est indispensable pour protéger les données. Le cluster Aurora MySQL s'appuie sur AWS KMS pour la gestion des clés et, plus précisément, sur une AWS Customer Managed Key (CMK) que vous créez, gérez et possédez pour chiffrer votre cluster Aurora. Gérer votre propre clé KMS pour le chiffrement de votre cluster Aurora présente plusieurs avantages par rapport à une clé KMS gérée par AWS : les CMK autorisent des politiques de contrôle d'accès très fines, avec la possibilité de désigner précisément qui peut les utiliser et les administrer ; chaque utilisation d'une CMK est consignée dans CloudTrail à des fins d'audit — un point déterminant pour la conformité réglementaire — et un contrôle géographique permet de restreindre l'usage des clés à certaines régions AWS. Les coûts liés aux CMK — facturés au stockage et à l'usage de l'API — sont également plus prévisibles et plus transparents, ce qui simplifie la budgétisation et la maîtrise des coûts par rapport aux clés gérées par AWS.

Le module KMS prend en charge la création et la gestion de ces clés. Le fichier outputs.tf du module fournit le nom de la clé KMS qui sera utilisée par le module Aurora.

# KMS Module - variables.tf
variable "rds" {
  description = "Enable customer managed KMS key for RDS"
  default     = true
  type        = bool
}

# KMS Module - main.tf
resource "aws_kms_key" "rds" {
  description             = "KMS key for RDS"
  enable_key_rotation     = true
  deletion_window_in_days = 30
}

Explications :

• Rotation des clés : la rotation automatique renforce la sécurité en renouvelant périodiquement la clé de chiffrement sous-jacente.
• Fenêtre de suppression : définit le délai avant qu'une clé supprimée ne soit définitivement détruite, ce qui laisse une marge de récupération si besoin.

Le module Aurora Cluster est au cœur de notre déploiement. Il met en place la base de données avec les paramètres voulus en matière de performance et de disponibilité. Il permet aussi bien de choisir le moteur de base de données à déployer que de spécifier le VPC et les Security Groups existants à associer, jusqu'à des options comme la prévention de la suppression accidentelle du cluster via Terraform — sauf si la clause lifecycle prevent_destroy = true est explicitement retirée du module :

# Aurora Cluster Module - variables.tf
variable "read_replica_count" {
  description = "Number of Read Replicas in addition to Writer instance"
  type        = number
}

# Aurora MySQL Cluster config
resource "aws_rds_cluster" "aurora_mysql_cluster" {
  cluster_identifier                    = var.name
  engine                                = var.engine
  engine_mode                           = var.engine_mode
  engine_version                        = var.aurora_mysql_cluster_engine_version
  database_name                         = var.database_name

  master_username                       = var.aurora_mysql_cluster_master_username

  # Create and store password in Secrets Manager
  manage_master_user_password           = true
  final_snapshot_identifier             = "${var.name}-snapshot"
  skip_final_snapshot                   = var.skip_final_snapshot
  deletion_protection                   = var.deletion_protection
  backup_retention_period               = var.backup_retention_period
  preferred_backup_window               = var.backup_window
  preferred_maintenance_window          = var.maintenance_window
  port                                  = var.port
  db_subnet_group_name                  = aws_db_subnet_group.db_subnet_group.name
  vpc_security_group_ids                = concat(var.security_group_ids, [aws_security_group.aurora_mysql_sg.id])

  apply_immediately                     = true
  iam_database_authentication_enabled   = false
  copy_tags_to_snapshot                 = true
  storage_encrypted                     = true
  kms_key_id                            = var.kms_key_id

  db_cluster_parameter_group_name       = aws_rds_cluster_parameter_group.cluster_param_group.name

  enabled_cloudwatch_logs_exports = var.engine_mode == "serverless" ? [] : var.enabled_cloudwatch_logs_exports

  tags = merge(var.tags, { "Name" = var.name })

  lifecycle {
    ignore_changes = [ engine_version, scaling_configuration, engine_mode ]
    prevent_destroy = true
  }
}

# Aurora MySQL Instances within Cluster - one Writer and "read_replica_count" Readers
resource "aws_rds_cluster_instance" "aurora_mysql_instance" {
  count                             = var.engine_mode == "serverless" ? 0 : (1 + var.read_replica_count)
  identifier                        = "${var.name}-${count.index}"
  cluster_identifier                = aws_rds_cluster.aurora_mysql_cluster.id
  engine                            = var.engine
  engine_version                    = var.aurora_mysql_cluster_engine_version
  instance_class                    = var.instance_type

  db_subnet_group_name              = aws_db_subnet_group.db_subnet_group.name
  db_parameter_group_name           = aws_db_parameter_group.db_param_group.name

  monitoring_role_arn               = var.create_monitoring_role && var.monitoring_interval > 0 ? aws_iam_role.rds_enhanced_monitoring[0].arn : null
  monitoring_interval               = var.create_monitoring_role && var.monitoring_interval > 0 ? var.monitoring_interval : null
  auto_minor_version_upgrade        = true

  performance_insights_enabled      = true

  tags                              = var.tags

  lifecycle {
    ignore_changes = [ engine_version ]
  }
}

Paramètres de configuration importants (à renseigner dans terraform.tfvars) :

• Identifiant du cluster : identifiant unique du cluster Aurora ; essentiel pour la gestion du cluster.
• Configuration du moteur : spécifie le moteur de base de données et sa version, ce qui garantit la compatibilité et la disponibilité des fonctionnalités. Aurora MySQL peut être en version 5.7.x ou 8.0.x, mais il est fortement recommandé d'utiliser la 8.0.x aujourd'hui : AWS a déprécié la 5.7.x et ne propose plus qu'un support étendu (payant).
• Nombre d'instances : définit le nombre d'instances de lecture créées en complément de l'instance d'écriture, pour faire évoluer la capacité de lecture.
• Sécurité et réseau : rattache le cluster à un VPC et à des Security Groups précis, afin qu'il s'exécute dans un environnement réseau sécurisé et isolé. Vous utiliserez les ID de sous-réseau et les autres valeurs associées d'un VPC existant dans lequel déployer votre nouveau cluster Aurora MySQL.
• Gestion des identifiants : s'appuie sur Secrets Manager pour stocker le nom d'utilisateur et le mot de passe de la base, conformément aux bonnes pratiques.

Les sorties sont indispensables pour récupérer les informations de connexion et administrer le cluster après son déploiement, mais aussi pour transmettre des valeurs d'exécution entre modules le cas échéant.

# Outputs - outputs.tf
output "aurora_cluster_endpoint" {
  description = "The endpoint at which the Aurora cluster is accessible"
  value       = aws_rds_cluster.aurora.endpoint
}

# Outputs - outputs.tf
output "aurora_cluster_reader_endpoint" {
  description = "The reader endpoint for the Aurora cluster"
  value       = aws_rds_cluster.aurora.reader_endpoint
}

Déployer des clusters Amazon Aurora MySQL avec Terraform simplifie le processus et assure cohérence et reproductibilité d'un environnement à l'autre. En s'appuyant sur des modules dédiés aux clés de chiffrement client KMS et à la configuration fine du cluster Aurora, le déploiement reste modulaire et facile à faire évoluer. Cette solution exploite les nouvelles fonctionnalités natives d'AWS pour créer et stocker directement votre mot de passe master MySQL dans Secrets Manager. Cette approche s'aligne sur les bonnes pratiques de l'architecture cloud : sécurité, scalabilité et reprise après sinistre. Qu'il s'agisse d'augmenter le nombre d'instances de lecture pour absorber une charge accrue ou de gérer les clés de chiffrement en toute sécurité, Terraform offre une solution robuste pour piloter aussi bien les configurations les plus simples que les plus complexes de cluster AWS Aurora MySQL, quels que soient les cas d'usage.

Vous avez encore des questions sur la mise en pratique de ces recommandations pour déployer un cluster Aurora MySQL adapté à votre cas d'usage dans votre environnement AWS avec Terraform ?

Contactez-nous chez DoiT International. Composées exclusivement d'ingénieurs seniors, nos équipes sont spécialisées dans le conseil cloud avancé : conception architecturale, aide au débogage et services de consulting.