terraform-provider-aws VS aws_sso_login

For Terraform, instead, a new version of the AWS module supports a dedicated resource.

If we check the support for the Terraform AWS Provider here (state for the date of publishing this article), we will see that the service is not yet fully supported. Last week, after more than half a year, support for creating a policy store was added. Additionally, we have the configuration to add template policies. However, the identity source is in the form of a PR draft, and there is no PR yet for the ability to create policies.

https://github.com/hashicorp/terraform-provider-aws/issues/3...

The size is what you get when you add every single AWS Go client into one binary.

Each service client like 1-2MB. But when you have 200 services....

Well, at least we now have a promising lead. Some diligent googling and browsing through Github issues in the AWS provider project yielded no directly related findings. However, I did come across a few recent bug reports about the recent change AWS made regarding the treatment of public buckets. And interestingly, they described precisely the behavior I was encountering.

> We're coming up on 10000 resources in our main Terraform repository and while there is definitely some friction, it's overall much better than having to hit the cloud API's to gather each of those states which would probably take at least an order of magnitude longer.

I don't think that's necessary true. Most cloud API's actually can return hundreds of records with 1 API calls, e.g. https://docs.aws.amazon.com/elasticloadbalancing/latest/APIR... has a maximum page size of 400.

If I manage the cloud resources via some custom tools and/or with some ansible-fu, I can decide to batch the API calls when it makes sense.

With terraform, it is not possible to do so (https://github.com/hashicorp/terraform-plugin-sdk/issues/66, https://github.com/hashicorp/terraform-provider-aws/issues/2...).

Release notes - https://github.com/hashicorp/terraform-provider-aws/releases/tag/v5.0.0

The only footgun I know of is changing the behavior of RDS instances created from snapshots. Force replacement on snapshot_identifier change for DB cluster resources will fuck up your world if you use a data source for snapshot_identifier since yesterday it would ignore any updates and today it will happily destroy your database (and, because AWS, all of the automated snapshots thereof) when the data identifier changes out from under it. 🎉

A while back I wrote a PR for the AWS provider to expose the policy simulator directly inside Terraform: https://github.com/hashicorp/terraform-provider-aws/pull/25569

The reason you see that is because the AWS Classic provider (pulumi_aws) is built on top of the open-source terraform-provider-aws (via the Terraform bridge you identified), and terraform-provider-aws is emitting that notice at runtime. Not all Pulumi providers are built from Terraform providers, however, but some, like this one, still are. (There's a notice at the bottom of the page for each resource where this is the case.) It works like this: