fix: Object Lock enabling on existing buckets

[vladislavdedushkin]

Description

Allows Object Lock to be enabled on existing S3 buckets without recreating them.

Two changes in main.tf:

1. Decoupled aws_s3_bucket_object_lock_configuration from var.object_lock_enabled. The resource is now created whenever object_lock_configuration.rule.default_retention is set, regardless of the object_lock_enabled flag:

   -count = local.create_bucket && var.object_lock_enabled && try(var.object_lock_configuration.rule.default_retention, null) != null ? 1 : 0
   +count = local.create_bucket && try(var.object_lock_configuration.rule.default_retention, null) != null ? 1 : 0

2. Added depends_on = [aws_s3_bucket_versioning.this] to aws_s3_bucket_object_lock_configuration so versioning is configured before the Object Lock configuration is applied.

var.object_lock_enabled still feeds aws_s3_bucket.object_lock_enabled and remains the way to enable Object Lock at bucket creation time.

Motivation and Context

object_lock_enabled on the aws_s3_bucket resource is ForceNew — flipping it from false to true on an existing bucket makes Terraform destroy and recreate the bucket, which is a non-starter for any bucket holding data.

AWS itself does not require recreation: Object Lock can be turned on for an existing bucket via PutObjectLockConfiguration, which is exactly what aws_s3_bucket_object_lock_configuration calls (its object_lock_enabled argument defaults to Enabled). The module was gating that resource behind var.object_lock_enabled, so the only path it offered was the bucket-recreating one — users who set object_lock_configuration alone got it silently ignored.

The depends_on addition covers the second half of the problem: AWS requires bucket versioning to be enabled before Object Lock can be configured. Without an explicit dependency there is no reference between the two resources, so Terraform is free to order them arbitrarily and the apply can fail with InvalidBucketState on a first run that enables both at once.

With both changes, enabling Object Lock on an existing bucket is:

versioning = {
  enabled = true
}

object_lock_configuration = {
  rule = {
    default_retention = {
      mode = "GOVERNANCE"
      days = 30
    }
  }
}

— no object_lock_enabled = true, no bucket replacement.

Breaking Changes

No backwards-incompatible changes for existing working configurations.

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects
  Validated in a live AWS environment:
  • Created a bucket with versioning enabled and no Object Lock, then added object_lock_configuration on a second apply — Object Lock was enabled in place, plan showed no bucket replacement, and the retention rule was verified with aws s3api get-object-lock-configuration.
  • Single-shot apply enabling versioning and Object Lock together on a new bucket — succeeded, with depends_on producing the correct ordering.
  • Existing configurations using object_lock_enabled = true plan clean (no diff) against previous state.
• I have executed pre-commit run -a on my pull request

[bryantbiggs]

this is an incorrect change