No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

I use this syntax:

`export const net1VpcId = ipv6VPC.id`

Thank you for the suggestion.

Yes - that works for the VPC, but not the subnet

The subnet is populated later, during the pulumi.all() phase of the build. And, for some reason, the results of that build are not included in the export.

The current work-around is break up my project into different stacks.

1. build the VPC and Subnets in the first stack
2. run `pulumi stack export &gt; first.json`
3. parse first.json in the second stack and move on
Not the best feeling, but it works... would love to hear the solution for the original problem, though.

Ah I see, I'm on a phone and missed that you're creating the subnet in an `apply`. Why are you doing that? You shouldn't have to do that, it's not recommended.

As far as I can tell, you're doing that because you want to transform strings that are not available at execution time, so you're waiting until deploy time. That is the thing you should have a look at resolving.

Can you build the VPC from the IP range, instead of the other way around? Or maybe use the awsx VPC, as that does it for you?

<@U012UJTT55M>, the issue is that I am trying to use an AWS allocated IPv6 block. You cannot specify that - it has to come from AWS. And, it is only available after the VPC is created. So, I cannot create a subnet until after the IPv6 block is allocated, so I can allocate a /64 block to the subnet.

Ok. You're not going to be able to export anything that comes from an `apply` or `then` block. You may be able to `await` something at the top level if you're using esnext or esmodule, but even then, you might not, as the promises you get from Pulumi have broken dependencies that outputs don't suffer from.

So you may want to look into ways to provide your own IPv6 block to AWS, rather than the other way aroud. Or maybe, use separate projects, so that you can build the VPC in one stack, await the entire stack, then use the AWS-provided IPv6 block in another project?

This wouldn't be hard if you're using automation-api.