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

ah, found this: <https://github.com/pulumi/pulumi/issues/1743>
Is it only related to Helm not following this principle?

could it theoretically be achieved through remodelling stuff directy as Pulumi ComponentResource?

so you have wrapped all of the implementation details of istio inside a component resource and then want to wait for that entire component resource to finish before the next resource is created?

the VPC class is a component resource and manages all of the infrastructure required (e.g. NAT gateways, route etc)

I then peer these together

```const appVpc = new Vpc("app-vpc", {
	description: `${baseTags.ManagedBy} App VPC`,
	baseTags: baseTags,

	baseCidr: "172.28.0.0/16",
	availabilityZoneNames: availabilityZones.names.slice(0, azCount),
	enableFlowLogs: true,

	endpoints: {
		s3: true,
		dynamodb: true,
	},
});

const dataVpc = new Vpc("data-vpc", {
	description: `${baseTags.ManagedBy} Data VPC`,
	baseTags: baseTags,

	baseCidr: "172.18.0.0/16",
	availabilityZoneNames: availabilityZones.names.slice(0, azCount),
	enableFlowLogs: true,

	endpoints: {
		s3: true,
		dynamodb: true,
	},
});

appVpc.configurePeering({
	peerVpc: dataVpc,
	nameTag: `${baseTags.ManagedBy} Peer App to Data`,
	routeSubnets: "private",
});```

so I need both VPCs to be created before the peering is take care of

now in the second VPC, I can update to this

```const dataVpc = new Vpc("data-vpc", {
	description: `${baseTags.ManagedBy} Data VPC`,
	baseTags: baseTags,

	baseCidr: "172.18.0.0/16",
	availabilityZoneNames: availabilityZones.names.slice(0, azCount),
	enableFlowLogs: true,

	endpoints: {
		s3: true,
		dynamodb: true,
	},
}, {
	dependsOn: appVpc,
});```

and this will ensure that the second resource actually depends on the first resource (in this case it's a component resource) is completed

Neat! So the second vpc is waiting for all resources of the first vpc?

yes - and even on destroy, it does it in the reverse order