Hi all! Sorry if that was already discussed, but I...
# aws
e
Hi all! Sorry if that was already discussed, but I couldn't find answer anywhere. As of https://github.com/pulumi/pulumi-aws-native/pull/1750 AWS Cloud Control plugin (FKA aws-native) is no longer promoted to be used for new projects: > For new projects, we recommend using AWS Native and AWS Classic side-by-side so you can get the speed and correctness benefits of AWS Native where possible. Became: > For new projects, we recommend starting with our primary AWS Provider and adding AWS Cloud Control resources on an as needed basis. That caught me by surprise, as we were doing the former - using AWS Cloud Control plugin and using AWS Classic only when we could not get AWS CC to work. Now it reads as if we should stick to AWS Classic only. I might be missing something but as AWS Classic covers all the resources, seems like "as needed basis" will never be the case. Can anybody elaborate whenever it's safe to assume that AWS CC provider will eventually become the primary provider? Or should we stop bothering about it and just stick to AWS classic one?
q
IMHO, that is a pragmatic change to not have the aws cc provider as the primary one, as that depends on AWS actually providing support for all their services through the cloud control api - which they do not.
e
I am more confused about the as needed basis. In our use case AWS Classic covers 100% of cases, so Cloud Control API based one is never needed. So it feels like aws-native is redundant in this case.
And (full disclosure) we had a bit harder time with aws-native in some cases. On the other hand, security groups referring to each other are almost impossible with AWS classic 😄 So I guess I have answered my own question LOL
l
I use security groups that refer to each other as a matter of course. Just don't use inline rules.
e
@little-cartoon-10569 Oh! By some reason I was not aware that AWS classic has same feature. Awesome! Thank you!
b
@eager-church-17824 I guess as needed would be some corner cases where the classic provider does not provide coverage but cc provider does, or you need some feature before it is implemented in classic provider. Technically the Cloud Control API could be used with 3rd party (not AWS) resources exposed via Cloud Control API, although in Pulumi's case that would likely be done via a provider for that 3rd party instead. Pulumi CDK uses the CC provider under the hood for code that you build with AWS CDK libraries to use with Pulumi.
e
Can anybody elaborate whenever it's safe to assume that AWS CC provider will eventually become the primary provider
I would not assume that. The messaging update you caught was attempting to stop giving the impression that AWS CC will replace Classic. We are committed to maintaining both but objectively AWS Classic as of today is the recommended option as it just works better for most users.
One interesting use case for AWS CC in the Pulumi ecosystem is it use in the CDK bridge https://github.com/pulumi/pulumi-cdk that allows to provision CDK constructs on top of Pulumi.
e
Thank you everyone! That clears things out for me!