Releases: cloudposse/terraform-aws-components
Releases · cloudposse/terraform-aws-components
v1.450.0
- No changes
v1.449.0
fix(`rds`): Corrected SSM Paths for Non Existent `var.name` @milldr (#1052)
what
- Add output for KMS key alias
- Update SSM naming convention
why
- Useful output for KMS key references
- When
var.name
doesnt exist, this path includesnull
. We want to optionally support settingvar.attributes
without avar.name
references
- customer engagement
v1.448.0
Extra Dynamodb outputs @Benbentwo (#1051)
what
- Add
hash_key
andrange_key
outputs
why
- Hash and range key are needed by other resources so we should add them as outputs to this component
references
v1.447.0
v1.446.0
v1.445.0
chore: karpenter v1beta upgrade @dudymas (#1039)
what
- upstream the karpenter component
- update
README.md
section 1 of install docs - update
README.md
section 2 of install docs - update
README.md
section 3 of install docs - fix/update
README.md
links and additional notes
- update
- upstream the karpenter node pool component
- update
README.md
docs (change from provisioners to node pools)
- update
why
- Considerable changes between alpha and beta api
references
v1.444.0
v1.443.0
feat: allow overriding the dynamodb table name @nitrocode (#1016)
what
- allow overriding the dynamodb table name
why
- This will make it possible to import older dynamodb tables without having to null portions of the context
- Matches s3-bucket module's
bucket_name
references
- See cloudposse/terraform-aws-dynamodb#126
- This depends on the 0.36.0 release https://github.com/cloudposse/terraform-aws-dynamodb/releases
v1.442.0
feat: `elasticache-redis` Optionally Disable VPC Ingress Rule @milldr (#1044)
what
- Add new variable 'allow_ingress_from_this_vpc' for
elasticache-redis
Changed default behavior to not allow Ingress from the VPC in this accountremoved
why
- Previously the default behavior allowed the full VPC CIDR in this account without an option to disable it. We should not only be able to disable it if we choose,
but the default behavior should be less permissive.
references
- Customer ask
v1.441.0
`sqs-queue` Update default KMS key to be null @Benbentwo (#1043)
what
- Update default SQS queue's KMS key to be null, this takes precedence in the module over
sqs_managed_sse_enabled
why
- If KMS key is set - use that key
- then, if KMS key is null &&
sqs_managed_sse_enabled
= true - use AWS SSE - Finally if KMS key is null &&
sqs_managed_sse_enabled
= false - no encryption