Deterministic S3 Bucket Naming

The primary (dr=active) must know the secondary's S3 bucket name in advance to create IAM policies that grant cross-region read access. This name must be predictable regardless of provisioning order: the secondary may not exist yet when applying the primary, or you may provision the secondary first and only later apply the primary with dr=active. Use a deterministic naming scheme so either cluster can compute the peer's bucket name ahead of time.

Why: Primary can't discover secondary's bucket name dynamically; IAM policies still need it.

Recommended format: <prefix>-<region>-<account_id>

  • Primary: logscale-s3-<primary-cluster>-us-west-2-<account_id>

  • Secondary: logscale-s3-<secondary-cluster>-us-east-2-<account_id>

How to enforce:

  • Set eks_s3_bucket_name explicitly in your tfvars to lock the exact name.

  • If using eks_s3_bucket_prefix, ensure your module logic yields the same deterministic pattern across environments.

  • In the primary tfvars, set dr_primary_s3_bucket to the secondary's deterministic name so IAM permissions can be created.

Remote state clarification:

  • On SECONDARY, the PRIMARY bucket name is fetched automatically from the primary's remote state (s3_bucket_id) when primary_remote_state_config is set.

  • On PRIMARY, the SECONDARY bucket name is not fetched via remote state in this flow and must be provided deterministically (e.g., dr_primary_s3_bucket).

Reference:

Original name formation logic — the S3 storage module