This message was deleted.

If you export the values you'll need to recreate it, absolutely. Example:

import * as awsxClassic from "@pulumi/awsx/classic";
import { ComponentResourceOptions, Input, all } from "@pulumi/pulumi";

export interface BaseArgs {
  tags?: aws.Tags;
}

export class BaseComponentResource extends ComponentResource {
  private readonly name: string;

  public getName(): string {
    return this.name;
  }

  constructor(type: string, name: string, args: BaseArgs, opts?: ComponentResourceOptions) {
    super(type, name, args, opts);

    this.name = name;
  }
}

export interface ExistingVpcArgs extends BaseArgs {
  privateSubnetIds: Input<Input<string>[]>;
  publicSubnetIds: Input<Input<string>[]>;
  vpcId: Input<string>;
}

export class ExistingVpc extends BaseComponentResource {
  vpc: any;

  constructor(name: string, args: ExistingVpcArgs, opts?: ComponentResourceOptions) {
    super("shared-vpc", name, args, opts);

    this.vpc = all([args.publicSubnetIds, args.privateSubnetIds, args.vpcId]).apply(
      ([publicSubnetIds, privateSubnetIds, vpcId]) => {
        return awsxClassic.ec2.Vpc.fromExistingIds(this.getName(), {
          vpcId,
          publicSubnetIds,
          privateSubnetIds,
        });
      },
    );
  }
}

usage:

const vpc = new sansVpc.ExistingVpc("default-vpc", {
  privateSubnetIds,
  publicSubnetIds,
  vpcId
});

So I would have to use the classic package even if I used the 1.0 to create the resources? How would modifying the VPC after look like? (if I wanted to add a public subnet for example)

No, you should use the latest if you can. I was just showing you old code to illustrate the point

But stack references don't import the resources right? They might as well be stack inputs (the vpcId for example). I have something like this in the original codebase:

new MegaComponent()

which does a bunch of stuff - creates VPC, ecs cluster, database, etc. Now I would like to untangle this, so that VPC stuff would go into a separate pulumi project/stack/whatever you call it. In pulumi aws package there is the

import

option, but here it is missing. In 1.0 there isn't even the

.fromExistingIds

. I tried exporting and importing the stack, but the urn's are messed up. Is what I am attempting even possible? Should I recreate the state by hand?

Here is a much more detailed overview of how to utilize Stack References and organize your projects with a "shared resources" pattern https://www.pulumi.com/blog/iac-recommended-practices-using-stack-references/

I don't have an issue with multiple stacks. My issue is on how to split the existing stack into multiple and keep the same resources allocated on AWS. The

VPC.fromExistingIds

does not import the resource (from my understanding). Is there a way to import the awsx.ec2.VPC component or is this impossible ATM?

Have you already tried

import

in the

opts

?

this option does not exist for awsx version of VPC

Maybe manually editing the state? 😕

Yeah, that is what I'm currently trying to do... untangle the component out of the current state by hand... this feels super hacky, but wcyd...

how about if you use this?

const defaultVpc = new aws.ec2.Vpc("defaultVpc", {}, {
    import: "<vpc-id>",
});

I would have to also add all subnets, route tables, associations, etc by hand

Yeah, I feel you.

awsx

and VPCs have been a major pain point for me in my projects as well 😞

Yeah, awsx is super cool to set up things, but it is a pain to setup existing components with it... I'll create an issue on github and see what can be done about that. Thanks for all the help!

There might be a path using classic to get it into your other stack using what I suggested, then once it's in that new stack, upgrade AWSX.

But then the URNs will be wrong, which would render it basically impossible to upgrade.

Maybe you can overcome that with aliases?

aliases?

But I can't alias the individual resources if the VPC creates a whole bunch of them.

Ahhh, I see what you mean now. Maybe? I'm not sure. Someone else might know the answer.

tnx anyway, got another tool in the toolbox now 😄

This pain point is what made me divest from Custom Resource Components early on..

Yeah, I'm refactoring our internal custom components to just awsx, but even this seems to be a pain to refactor if needed. I have opened github issue and I'll see what comes off that...

We've moved to using the AWS provider for the majority of cases, except a few.