## Highlights
- Upgrades Aurora from `terraform-aws-modules/rds-aurora/aws` `7.6.0` to
`9.16.1`
- Bumps the Terraform minimum version from `>= 1.3.8` to `>= 1.5.0`
- Adds CMK support across newly exposed RDS, Redis, VPC, ECS, and Fleet
surfaces
- Adds additive per-key `extra_kms_policies` support across the root ->
`byo-vpc` -> `byo-db` -> `byo-ecs` path
- Moves software-installers KMS policy ownership out of
`addons/cloudfront-software-installers` and back into `byo-ecs`
- Extends monitoring and ECS integration to work with CMK-encrypted DB
password secrets
- Adds migration tooling and docs for Aurora storage KMS replacement and
CloudWatch Logs KMS cutovers
## Aurora module upgrade: `7.6.0` -> `9.16.1`
This PR keeps a single Aurora module path on upstream `9.16.1` and
updates the Fleet wrapper modules to preserve compatibility where
possible while exposing the new KMS and observability capabilities.
Notable changes handled in the wrapper:
- `security_group_rules`
- upstream moved from older SG rule addressing to the newer
`security_group_rules` model
- added `moved` handling for the confirmed SG rule address rename to
avoid unnecessary destroy/create churn
- `manage_master_user_password`
- the wrapper continues to own the DB password flow
- Aurora is kept on `manage_master_user_password = false`
- Secrets Manager integration remains wrapper-managed rather than
switching to upstream-managed password behavior
- `final_snapshot_identifier`
- wrapper support was added so old behavior is preserved
- if unset, the legacy generated naming pattern is still used
- callers can now override it explicitly
- Observability / Database Insights wiring
- cluster-level Performance Insights / Database Insights configuration
was added to match Aurora's current control surface
- monitoring behavior was aligned to cluster-level management for
consistency with the Aurora module and Database Insights requirements
- `backtrack_window`
- added optional pass-through support for Aurora MySQL backtracking
- validated as `null` or `0..259200`
## Terraform version bump
This PR raises the Terraform minimum version from `>= 1.3.8` to `>=
1.5.0`.
Reason:
- deprecation warnings for legacy KMS `enabled` flags now use Terraform
`check` blocks
- `check` blocks require Terraform `1.5+`
This was done so published interfaces can remain backward-compatible for
existing `enabled` users while still warning during plan/apply and
preferring `cmk_enabled`.
## KMS surface expansion and pass-through
This PR adds or expands CMK support for:
- Aurora storage
- Aurora password secret
- Aurora observability / Performance Insights
- Aurora exported log groups
- Redis at-rest encryption
- Redis log groups
- VPC flow log CloudWatch log groups
- ECS cluster log groups
- Fleet private-key secret
- Fleet Fargate ephemeral storage
- Fleet application logs
- Fleet software installers
It also adds additive `extra_kms_policies` support across those
module-owned CMK surfaces so callers can append narrowly scoped
statements without replacing the inherited base policy.
During validation of the cron-monitoring integration, I found that the
root module schema was still dropping some nested KMS attributes before
they reached `byo-vpc`. This PR now carries those fields all the way
through to their final destinations, including:
- `rds_config.*.extra_kms_policies`
- `redis_config.*.extra_kms_policies`
- `ecs_cluster.cloudwatch_log_group.kms.extra_kms_policies`
- `fleet_config.private_key_secret_kms.extra_kms_policies`
- `fleet_config.fargate_ephemeral_storage_kms.extra_kms_policies`
- `fleet_config.awslogs.kms.extra_kms_policies`
- `fleet_config.software_installers.extra_kms_policies`
- `fleet_config.software_installers.cloudfront_distribution_arn`
- `vpc.flow_log_cloudwatch_log_group_kms.extra_kms_policies`
## DB password secret KMS handoff to monitoring
`byo-vpc` now exposes:
- `rds_password_secret_kms_key_arn`
The monitoring addon now accepts:
- `cron_monitoring.mysql_password_secret_kms_key_arn`
The monitoring addon also now exposes:
- `cron_monitoring_lambda_arn`
- `cron_monitoring_lambda_role_arn`
This is needed so the cron-monitoring Lambda can decrypt the Fleet DB
password secret when that secret is encrypted with a customer-managed
KMS key.
Expected wiring:
```hcl
module "monitoring" {
# ...
cron_monitoring = {
# ...
mysql_password_secret_name = "${local.customer}-database-password"
mysql_password_secret_kms_key_arn = module.main.byo-vpc.rds_password_secret_kms_key_arn
}
}
```
## Software installers KMS ownership change
This PR changes the software-installers KMS contract:
- `addons/cloudfront-software-installers` no longer manages the
software-installers KMS key policy
- `byo-ecs` now owns the software-installers CMK policy, including
required service / principal statements
- `fleet_config.software_installers.cloudfront_distribution_arn` is the
static input used to add the CloudFront KMS statement without
introducing a module cycle
- `byo-ecs` also adds the explicit Fleet task-role KMS statement
required under the narrower external key-policy model
- the CloudFront addon exposes `cloudfront_distribution_arn` for
visibility, but that output should not be fed back into `byo-ecs`
because that would create a dependency cycle
Important compatibility note:
- if software installers uses KMS at all, it must use a customer-managed
key
- CloudFront requires a key-policy statement on that key
- the AWS-managed default key cannot be modified to attach that policy
## Other notable items
- Added and expanded migration docs for RDS and Redis KMS adoption
- Added `byo-vpc/scripts/rds_storage_kms_migration.sh` to automate
Aurora storage-KMS migration workflows
- Added `scripts/cloudwatch_logs_kms_migration.sh` to help identify and
optionally remove pre-cutover log streams after associating a new KMS
key with a CloudWatch Logs group
- Normalized `cmk_enabled` usage while preserving deprecated `enabled`
compatibility only for previously published interfaces
- Refactored `addons/logging-alb` KMS policy handling to support
`kms_base_policy` and align it with the structured KMS statement model
used elsewhere
- Reduced repeated KMS policy boilerplate within modules where it was
materially duplicated
## Compatibility notes
- Existing published KMS interfaces that previously used `enabled` still
accept it, but now warn and prefer `cmk_enabled`
- New KMS surfaces are `cmk_enabled`-only
- Software-installers KMS policy ownership moved from
`addons/cloudfront-software-installers` to `byo-ecs`
## Validation
Validated module stacks after the refactors:
- `root`
- `byo-vpc`
- `byo-db`
- `byo-ecs`
- `addons/monitoring`
- `addons/cloudfront-software-installers`
- `addons/logging-alb`
Robert Fairburn
e7faee93de