This message was deleted.

Creating resources in an apply is to be avoided, but isn't always avoidable (sad panda). Your first preview/apply will definitely not include anything in an apply one way or the other because the value isn't known. I can't remember if subsequent preview/applies will include the resource - gonna have to run it and see. I have a vague notion that resources in an apply are included because the value is known, but that could be wishful thinking. The main issue is that you don't get the preview reliably, but the behavior of the program will be the same regardless. That is, there's no connection between preview and apply in the sense that the preview is just a dry run (which you can even skip if you want to, but don't do that for anything important). The apply is not necessarily bound by what is shown in the preview.

Very much sad panda 😄

I don't know these particular resources, but this seems like the type of place where you do need to create resources in an apply. For me, it's nearly always involved dealing with an Output that's an Array.

Just made an edit along the lines of your reply after realising what was going on after following through with the update. It seems that outputting the value leads to more reliable previews, so this may be a workaround?

Yeah, or you could do the

ProjectIpAccessList

in a separate stack if the overhead is worth the safety you'd get.

Yeah, really anything that is a firewall or network type config is going to have this issue where the resource addresses are unknown. I can think of a few ways to work around it, but they would all have drawbacks - which I guess explains why it works how it works

If you don't need a

/32

for these rules (i.e. a single IP), you might be able to avoid the apply. Could you maybe provision the public IP separately and pass it through?