It appears the Fargate TS sample code (link) uses deprecated bindings. It uses

awsx.elasticloadbalancingv2.NetworkListener

, but this no longer exists. I think it moved from

awsx

to

aws

at some point, to

aws.elasticloadbalancingv2.Listener

. (Could someone verify / explain what falls under

awsx

vs

aws

?) And then I find out from the docs that now this is deprecated in favor of

aws.lb.Listener

, so I should really be using that? And to further the confusion, I learn that everything under

@pulumi/aws

is known as classic, and if I want to stay modern I should actually be using

@pulumi/aws-native

instead of any of the options above? Incredibly, although

elasticloadbalancingv2

got renamed to

lb

in classic, it's back to being called

elasticloadbalancingv2

in native!

There have been some changes made to the awsx library since that example was created. Long story short, the example should still work 🙂 Longer explanation: As we can see in package.json, it uses version 0.40 of awsx. This version of the package written in TypeScript and can only be used in TypeScript. Later on, it was rewritten as a multi-language package, so that it can be used from any other language supported by Pulumi. As part of the above, the old TypeScript-only resources got moved to this directory: https://github.com/pulumi/pulumi-awsx/tree/master/awsx-classic So everything from the example can be used even with the new version of the package (which is >1.0 now). It didn't move from

awsx

to

aws

, because the

aws

package reflects resources from the corresponding terraform aws provider.

awsx

is a wrapper around that

aws

provider that provides you with some sensible defaults and allows to get started quickly. It's not a separate thing, it just complements the original

aws

provider. Ok, so now the classic / native. The classic

aws

package utilises the terraform provider, with its convenience hacks (like a security group association resource, which is not a real resource). Whenever a new service appears from AWS, or an existing one gets a new feature, it has to go through the aws terraform provider development cycle, to be included later on into the Pulumi's aws provider, which will just update the terraform provider version under the hood. The Pulumi's "native"-type providers are created differently. They're generated from the API specs, and can be quickly regenerated whenever there's a change in the spec. Then are much leaner in a sense and allow to bring new features quickly. Which one to use? Depends on the use case. I'd still have the classic

aws

as the base, and add

aws-native

if there's a feature I need, which doesn't exist in the former yet. Disclaimer: I'm not affiliated with Pulumi org, I'm just a fellow Pulumi user who likes processing information 😄 If I made any wrong statements or assumptions, please correct me!

Thank you! So the elastic load balancer v2 was formerly in awsx because it awsx had some helpers to create sensible defaults, but post version 1.0, the aws package eventually built this in so the awsx load balancer helpers were removed?

Looks like it's still there! https://www.pulumi.com/docs/guides/crosswalk/aws/elb/#load-balancing-ecs-service-targets