📣 The Pulumi AWS Classic Provider 6.0 is now available! 🎉 We've added many improvements to the latest version of the most heavily used provider across the entire Pulumi Ecosystem. Highlights include: 🔌 56 new resources & 23 new functions unlocked with TF Plugin Framework support 🏎️ Faster updates with up to 90% smaller SDKs 🔧 Fixes for many high-visibility issues including Default Tags and WAFv2 diff Learn more: https://pulumip.us/AWS-Classic-6

FYI "Release Notes" link is 404 https://github.com/pulumi/pulumi-aws/releases/tag/v6.0.0

Thanks @millions-furniture-75402! Let me correct that 🙂

Is there anyplace that details the concept of "Classic" vs. "Native" providers - not just from AWS perspective, but in general (e.g. would also apply to Azure Classic vs. Native)? The little I've been able to pick up made me think that once a "native" provider existed for a cloud service, any "classic" provider there might have been would at that point be deprecated. Sounds like at least for AWS, that's not the case. So how are we to think about these things?

Classic means it's based on the terraform provider. Native means a provider that was developed Pulumi-first and I believe they all use the Cloud provider APIs that describe their SDKs (e.g. AWS CloudControl API) to generate the Provider SDKs.

From Pulumi's perspective, what's the benefit to enhancing a "classic" provider once a native provider exists?

1. Coverage differences. The classic providers had A LOT more coverage last time I checked. 2. Customers depend on it. If things start to break because Pulumi isn't maintaining the libraries many of the their customers use, then Pulumi's product looks poor