Better check during planning of security group rules when large number of rules

[hashibot]

This issue was originally opened by @DevilWAH as hashicorp/terraform#16309. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Hi there,

Expected Behavior

When i run a plan of my changes after adding new rules to a security group, I am told that it is all ok and "new resources" will be created. and I expect when I run apply this will be successful.

Actual Behavior

If the change increased the number of security rules above the limit for the security group the old rules may get deleted but fail to get recreated due to the limits being reached. So it is not just the "changes" that might not be applied but because it it doing a destroy / create operation you can end up losing rules already in place. Is there any way during the plan phase the user can be notified if the rule base will be exceeded. We use a lot of CIDR list variables so adding a single IP any results in 5-10 rules being created and it can have serious impact if the apply fails in production.

[gwohletz]

+1 on this, even an option to give you a count of the number of rules the plan will result in would be helpful

[bflad]

It is probably worth noting that as of version 1.27.0 of the AWS provider, likely releasing tomorrow, that the security group rule handling within a single aws_security_group resource has been improved to authorize and revoke only changed individual ingress/egress rules despite their configuration grouping (e.g. replacing an individual element in a multiple element cidr_blocks list). This should help reduce scenarios where the AWS provider is revoking rules unnecessarily during updates.

[varks]

@bflad This issue doesn't seem to be resolved. Within a single aws_security_group, replacing an individual element in multiple element cidr_block list, would still revoke all the rules first before updating it accordingly.

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.