AWS \ Security Group \ Inbound Rule \ Unable to update the rule using CIDR as source

Hello everybody, good morning ,

Through the creation of a VPC and its associates objects automatically, I get a SG with an Inbound Rule I cannot update using as source my IP :

In the Field Source of the SecurityGroupRuleID = sg-065cba0045348c4af / default

It means that the source of the INBOUND RULE = the SG’s ID to which the RuleID belongs to :confused:

And when I try to update it with my IP I get this error : “You may not specify an IPv4 CIDR for an existing referenced group id rule.”

Just to emphasize that when I create manually everything (VPC, SUBNET, RTB, IGW, ACL, SG …) I have no problem using CIDR in the SOURCE of an INBOUND RULE.

Thanks for any idea which could help to fix this problem.

Have a good day

Hello Didier, if i get you well here you are trying to update an inbound rule ? why you not try and add a new inbount rule and specify your IPv4 CIDR to that same seguriy group.

Hello Antoine,

Yes and No :face_with_monocle:

If I add a rule, indeed I can use a CIDR as the source.
But the rule will be at the second position.
And the first position allows all trafic with source as the SG.
And I don’t know what includes the SG as a source.

I would like to understand why in that case , the INBOUND RULE of this SG contains a rule which references as the source the SG to which the INBOUND RULE belongs to.

As I know it is really complicated to understand the context when you are not in front of the screen, I provide some screen captures :

This is what I get when I access the EDIT INBOUND RULES :

Trying to replace the SG with an IP :

System refuses it :

Here below , is the definition of the SG :

And this behavior occurs only when all networks objects have been created automatically along the process of creation of an EC2 instance.

Thanks for your help.
Not urgent.


Hello Didier,

When an SG rule references the source as the SG to which the rule belongs, it is known as self-reference. In simpler terms, the rule allows inbound traffic from the same security group. By allowing inbound traffic from the same security group, instances within the group can communicate with each other.
The order of the rules in a security group is important because the rules are evaluated sequentially. When an inbound connection is received, the security group evaluates the rules from top to bottom and applies the action of the first matching rule. Therefore, if the first rule allows all traffic from the security group itself, it will take effect for inbound connections initiated by instances within the same security group.
The second position rule that you mentioned, which allows a CIDR as the source, would only come into play if there are specific IP ranges or subnets that need to be allowed access to the instances in the security group. The CIDR rule would be evaluated after the rule allowing traffic from the security group itself

Hello Antoine,

thanks you very much for your explanation. :+1:
Understood everything. :grinning:

Have a very good day