Terraform having state wasn’t some easy button decision, it was absolutely required and carefully considered.
The state is stored in the resources themselves, to be precise.
> It’s also not usable for lots of important parts of AWS, which does not have consistent tagging support and would leave you running very much foul of API rate limits.
As someone who worked on tagging inside AWS, I don't believe that there are any major AWS services left that don't support tagging. These days, tagging-on-creation also guarantees that you won't have untagged resources if your provider happens to die between "CreateResource" and the "TagResource" operations.
You can also sometimes use prefixed names to signal that a resource belongs to the infrastructure-as-code.
API limits for "describe" calls are also pretty lax. And you need to use them anyway to check if the current state of the world matches with the saved state.
State will be needed for some integrations that don't support tagging/naming (Okta, I'm looking at YOU!), but at least for AWS it's not needed.
Furthermore, tagging is restrictable by IAM, is often co-opted by finance for cost allocation, and is subject to often-bizarre limits about what the content can be (even more so across providers).
Finally, how would you manage tags as an actual resource themselves in this model?
