This message was deleted.

Hi,

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. For existing projects, AWS Classic remains fully supported; at this time, we recommend waiting to migrate existing projects to AWS Native.

yeah, I read that, however awsx doesn't seem to work well with aws-native. also wondering how to migrate aws-classic resources to aws-native at a later point - how to handle the state migration?

AWSX are just AWS Classic components, so I'm not sure where you're seeing incompatibility. Can you maybe explain a little more?

Hi @stocky-restaurant-98004, maybe 'incompatible' is not the right word, but when starting out, as the first I wanted to create a Vpc, and reached for

awsx.ec2.Vpc

then realized this was creating classic resources, and would require it's own provider (separate from the aws-native one). Also some props are named differently (e.g. vpc.id vs. vpc.vpcId) which makes code depending on the outputs change between aws-classic/native. However my main concern is that there is no clear path on how to eventually migrate those resources to aws-native. I understand how to change the code from aws-classic to native, but I don't see how the already deployed resources will be ported without having to recreate them (is there some way to migrate state from classic to native?) and I really don't want to recreate resources that are used for live production workloads. Feel free to reach out if you want to discuss further

Some points that you may find useful: • While AWS Native will become the preferred way to create resources once AWS has adequate coverage and the provider hits 1.0 (no timeline on this at present - it's dependent upon AWS getting enough resources in CloudControl), AWS Classic will be well supported for a very long time. We have a ton of customers using it. I would not have any long-term maintenance concerns creating resources in AWS Classic, even for production workloads. • It's totally idiomatic to use multiple providers. In some cases you have to use AWS Native because the resources does not exist in Classic, (e.g. CloudWAN stuff as of several months ago - might've changed since then). • If you really want to, you could import the resources into a new AWS Native-only stack, but I don't see a compelling reason to do so.

I see, thanks. I'm not giving up on Pulumi (it's way to good for that), but for now I'll stay away from aws-native (except for resources that only work there). I think what bothers me is that from the docs I had understood/hoped it was 'ready' for use in new projects for most things, so had expected fundamentals to be working. But when I'm unable to even create a working VPC (neither Route or VPCGatewayAttachment is working) without having to mix native/classic, it doesn't really feel so for me and I ended up spending a lot of time figuring out what works and doesn't - and in the end this led me to stay away from aws native. It does sound very promising, and I think it would be good with some clear guidance on how you would eventually migrate an existing running production workload to aws native.