Add upwards of 100 parameter store values.
resource "aws_ssm_parameter" "service-s3-bucket" {
name = "/${var.service}/${var.environment}/S3_BUCKET"
type = "String"
value = "${aws_s3_bucket.service-messages.id}"
overwrite = true
}
Better performance on newer versions of the provider
A terraform plan is taking significantly longer on aws_ssm_parameter state refresh
provider "aws" {
region = "${var.region}"
version = "1.9.0"
}
terraform plan -> takes about 2 minutes to run in our caseprovider "aws" {
region = "${var.region}"
version = "1.28.0"
}
terraform initterraform plan -> takes 10+ minutes now
Abnormally large amount of param store variables in our aws account(s)
The speed difference seems to occur betweem AWS provider versions <= 1.10.0 (fast) and >= 1.11.0 (slow)
Hi everyone 👋 Sorry for the strange behavior here. It turns out that the SSM API can return results in an unexpected manner (e.g. empty DescribeParameters pages for _all_ SSM parameters even though we asked specifically for one name) depending on which type of request filtering is used.
We just merged in #5325 which changes the filtering type to only make a single API request. It should be released later today in version 1.29.0 of the AWS provider. Huge shout out to @julienduchesne who spent a lot of time doing investigative work here and coming up with (we expect) the correct solution to reduce the number of API calls.
This has been released in version 1.29.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.
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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!
Most helpful comment
Hi everyone 👋 Sorry for the strange behavior here. It turns out that the SSM API can return results in an unexpected manner (e.g. empty DescribeParameters pages for _all_ SSM parameters even though we asked specifically for one name) depending on which type of request filtering is used.
We just merged in #5325 which changes the filtering type to only make a single API request. It should be released later today in version 1.29.0 of the AWS provider. Huge shout out to @julienduchesne who spent a lot of time doing investigative work here and coming up with (we expect) the correct solution to reduce the number of API calls.