Summary
When a LowKey deployment is removed, its VPC-wide BPA exclusion can disappear while another LowKey deployment is still using the same VPC. uninstall.sh should warn about this before the point of no return.
Background
PR #102 makes every deployment ensure a VPC-wide allow-bidirectional VPC Block Public Access exclusion, created and owned by the CloudFormation stack.
Exclusions created for a reused VPC use DeletionPolicy: Retain / UpdateReplacePolicy: Retain, so they survive their creating stack. The remaining gap is the ownership transition:
- Stack A creates a new VPC and owns its exclusion.
- The installer later offers that
loki:managed=true VPC for reuse, and Stack B reuses it.
- Stack B sees an active exclusion and does not create one, so it holds no CloudFormation ownership.
- Deleting Stack A deletes the exclusion while Stack B's instance is still in that VPC.
Under regional VPC BPA this can cut internet ingress/egress for the remaining deployment.
This was an accepted, deliberate limitation for PR #102: keep exclusion management inside the CloudFormation stack rather than splitting networking into a separate stack or blocking VPC reuse.
Proposed behavior
In uninstall.sh, before confirm_destruction's final DESTROY prompt:
- For each targeted VPC, detect other LowKey deployments still using it — for example EC2 instances in the VPC that are not part of the selected deployment.
- When the VPC is shared, warn explicitly that deleting this stack can remove the VPC-wide BPA exclusion the remaining deployment depends on.
- Name the affected VPC and the exclusion, and state the remediation: recreate a VPC-wide
allow-bidirectional exclusion, or redeploy the remaining stack with CreateVpcBpaExclusion=true.
- Skip the warning when the exclusion is retained (created by the reused-VPC path) or when no other deployment shares the VPC, so the message stays meaningful.
Notes
- CloudFormation has no pre-delete hook, so the disclaimer must live in LowKey's own teardown UX.
- A stronger long-term fix is VPC-scoped ownership of the exclusion (separate networking stack) or refusing reuse of a stack-owned VPC.
Summary
When a LowKey deployment is removed, its VPC-wide BPA exclusion can disappear while another LowKey deployment is still using the same VPC.
uninstall.shshould warn about this before the point of no return.Background
PR #102 makes every deployment ensure a VPC-wide
allow-bidirectionalVPC Block Public Access exclusion, created and owned by the CloudFormation stack.Exclusions created for a reused VPC use
DeletionPolicy: Retain/UpdateReplacePolicy: Retain, so they survive their creating stack. The remaining gap is the ownership transition:loki:managed=trueVPC for reuse, and Stack B reuses it.Under regional VPC BPA this can cut internet ingress/egress for the remaining deployment.
This was an accepted, deliberate limitation for PR #102: keep exclusion management inside the CloudFormation stack rather than splitting networking into a separate stack or blocking VPC reuse.
Proposed behavior
In
uninstall.sh, beforeconfirm_destruction's finalDESTROYprompt:allow-bidirectionalexclusion, or redeploy the remaining stack withCreateVpcBpaExclusion=true.Notes