dynamodb: Can't update PITR on inline table replicas when CMK

[szesch]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform AWS Provider Version

Terraform v1.2.8
registry.terraform.io/hashicorp/aws v4.28.0

Affected Resource(s)

• aws_dynamodb_table

Terraform Configuration Files

Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.

provider "aws" {
  region  = "us-east-2"
}

provider "aws" {
  region  = "us-west-2"
  alias   = "uswest2"
}

provider "aws" {
  region  = "eu-west-2"
  alias   = "euwest2"
}

resource "aws_kms_key" "us_east_2" {
  description = "CMK for us-east-2"
}

resource "aws_kms_key" "us_west_2" {
  description = "CMK for us-west-2"
  provider    = aws.uswest2
}

resource "aws_kms_key" "eu_west_2" {
  description = "CMK for eu-west-2"
  provider    = aws.euwest2
}

resource "aws_dynamodb_table" "test" {
  name           = "replica-pitr-test"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "id"
  stream_enabled = true

  point_in_time_recovery {
    enabled = true
  }

  server_side_encryption {
    enabled     = true
    kms_key_arn = aws_kms_key.us_east_2.arn
  }

  attribute {
    name = "id"
    type = "S"
  }

  replica {
    region_name = "us-west-2"
    kms_key_arn = aws_kms_key.us_west_2.arn
    #point_in_time_recovery = true
  }

  replica {
    region_name = "eu-west-2"
    kms_key_arn = aws_kms_key.eu_west_2.arn
    #point_in_time_recovery = true
  }
}

Debug Output

https://gist.github.com/szesch/69e6025e6670be53c85c96142f6f9283

Expected Behavior

When enabling PITR for global table replicas, each replica should have its PITR updated accordingly.

Actual Behavior

The following error occurs and PITR recovery is not updated for the replicas

aws_dynamodb_table.test: Modifying... [id=replica-pitr-test]
╷
│ Error: updating Amazon DynamoDB Table (replica-pitr-test): updating replicas, while creating: creating replica (us-west-2): ValidationException: One or more parameter values were invalid: KMSMasterKeyId must be specified for each replica.
│       status code: 400, request id: GG3TINE9O3KKHJ5TVNBPDBQK37VV4KQNSO5AEMVJF66Q9ASUAAJG
│ 
│   with aws_dynamodb_table.test,
│   on main.tf line 32, in resource "aws_dynamodb_table" "test":
│   32: resource "aws_dynamodb_table" "test" {

This happens because the UpdateTable API call is made with only a single replica instead of all replicas.

terraform-provider-aws/internal/service/dynamodb/table.go

Line 1049 in 4b0075a

Update: replicaInput,

. This causes the error to be returned from the API. This can be reproduced with the AWS CLI. If a call is made with a single replica it will fail with the same error but if a call is made with all replicas it will succeed. Since this UpdateTable call fails before the call to update PITR on replicas, that code path is never executed.

Steps to Reproduce

1. terraform apply to create the global dynamodb table
2. Edit the configuration to uncomment PITR for the replicas
3. plan and apply

[YakDriver]

Related #28814
Related #24903
Related #27850

As mentioned in #28814 (comment), without KMS keys, PITR enable updates are working fine. The problem appears to be isolated to KMS.

[github-actions]

This functionality has been released in v4.52.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.