AWS Provider: aws_s3_bucket_lifecycle_configuration change in expiration breaks configuration

[mimozell]

Expected Behavior

aws_s3_bucket_lifecycle_configuration.expiration should continue being an object (instead of array) same as in the AWS provider version 5.90.0 or before (currently an issue in 5.90.1 and 5.90.2)

Actual Behavior

Logged the issue with the provider as well here: hashicorp/terraform-provider-aws#41896

aws_s3_bucket_lifecycle_configuration.expiration has changed from being an object into being an array. In the terraform configuration this change is not apparent, but it breaks cdktf configurations in versions after 5.90.0. Previously a rule would be configured the following way:

      {
        id: "expire_object",
        status: "Enabled",
        expiration: {
          days: 7
        },
      },

while now we need to use:

      {
        id: "expire_object",
        status: "Enabled",
        expiration: [{
          days: 7
        }],
      },

for no apparent reason. Configurations break with the following error:
Type '{ id: string; status: string; expiration: { days: number; }; }' is not assignable to type 'S3BucketLifecycleConfigurationRule'. Types of property 'expiration' are incompatible. Object literal may only specify known properties, and 'days' does not exist in type 'IResolvable | S3BucketLifecycleConfigurationRuleExpiration[]'.

I suspect expiration has changed from an object to a dynamic in terraform, that's why in the native HCL documentation - that has only examples of single expiration {} blocks - this change is not apparent, but becomes very visible when selecting the TypeScript docs.

Steps to Reproduce

1. Create a bucket
2. Set S3BucketLifecycleConfigurationRule with an lifecycle rule to expire objects

Versions

@cdktf/provider-aws: 19.57.0
cdktf-cli: 0.20.11
terraform: v1.10.2

Providers

No response

Gist

No response

Possible Solutions

No response

Workarounds

No response

Anything Else?

No response

References

No response

Help Wanted

• I'm interested in contributing a fix myself

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

[InfraPlatformer]

Hi @hashicorp/cdk-team, I'd like to contribute a fix for this issue where aws_s3_bucket_lifecycle_configuration.expiration changed from object to array format in AWS provider v5.90.1+.

Problem Confirmation
Confirmed the breaking change between provider v5.90.0 (object) → v5.90.1+ (array)

CDKTF's current typings don't reflect this provider change

Proposed Solution

Type Definition Update:

// Current
readonly expiration?: S3BucketLifecycleConfigurationRuleExpiration;

// Proposed
readonly expiration?: S3BucketLifecycleConfigurationRuleExpiration | S3BucketLifecycleConfigurationRuleExpiration[];

Runtime Normalization:
private normalizeExpiration(exp: any) {
return exp ? (Array.isArray(exp) ? exp : [exp]) : undefined;
}

Should we match the provider's exact behavior (array-only) or support both?

Any concerns with this approach?

If approved, I can submit a PR with tests and docs updates.

[mimozell]

@SREAlam since cdktf is generated from terraform, I think your approach wouldn't work, because on every regeneration it would be overridden.

[InfraPlatformer]

Hi @mimozell,

Thank you for clarifying that CDKTF’s types are generated from Terraform schemas—I understand now that manual fixes would be overwritten on regeneration.

Proposed Next Steps
Upstream Fix (AWS Provider):

I’ll engage with the AWS provider team (hashicorp/terraform-provider-aws#41896) to:

Confirm if this was an intentional schema change

Propose reverting to Type: Object or adding ConfigMode: SchemaConfigModeAttr for backward compatibility

Would you prefer I focus on the AWS provider fix first?

If the schema must stay as Type: List(Object), is there a CDKTF mechanism (e.g., schema patches) to preserve backward compatibility?

I’m happy to collaborate on the best path forward—let me know how you’d like to proceed!

[InfraPlatformer]

Hi @mimozell,

Thanks for spotting the prefix issue too - this confirms the pattern affects multiple attributes. Since manual type changes would be overwritten, I propose:

Immediate User Solution:
I'll draft a helper function users can import to normalize both cases:

export function normalizeLifecycleRule(rule: {
expiration?: object | object[],
filter?: { prefix?: string } | Array<{ prefix?: string }>
}) {
return {
...rule,
expiration: rule.expiration ? (Array.isArray(rule.expiration) ? rule.expiration : [rule.expiration]) : undefined,
filter: rule.filter ? (Array.isArray(rule.filter) ? rule.filter : [rule.filter]) : undefined
}
}

Long-Term Fix:
I've commented on hashicorp/terraform-provider-aws#41896 asking:

If these changes were intentional

Whether they'd accept a PR adding ConfigMode: SchemaConfigModeAttr to prevent forced array wrapping

Documentation:
Can we add a migration note to CDKTF's AWS provider docs explaining this pattern?

Would you prefer I:

Focus on the AWS provider fix first?

Submit the helper function as a temporary solution?