AWS CloudFormation example that allows a security group rule to reference the same security group as the source.

aws-cfn-self-referencing-sg.json

{
  "Description": "Create a VPC with a SG which references itself",
  "AWSTemplateFormatVersion": "2010-09-09",
  "Resources": {
    "vpctester": {
      "Type": "AWS::EC2::VPC",
      "Properties": {
        "CidrBlock": "172.16.0.0/23",
        "EnableDnsSupport": false,
        "EnableDnsHostnames": false,
        "InstanceTenancy": "default",
        "Tags": [ { "Key": "Name", "Value": "vpctester" } ]
      }
    },
    "sgtester": {
      "Type": "AWS::EC2::SecurityGroup",
      "DependsOn": "vpctester",
      "Properties": {
        "GroupDescription": "vpc tester sg",
        "VpcId": { "Ref": "vpctester" }
      }
    },
    "sgtesteringress": {
      "Type": "AWS::EC2::SecurityGroupIngress",
      "DependsOn": "sgtester",
      "Properties": {
        "GroupId": { "Ref": "sgtester" },
        "IpProtocol": "tcp",
        "FromPort": "0",
        "ToPort": "65535",
        "SourceSecurityGroupId": { "Ref": "sgtester" }
      }
    }
  }
}

Say that the security group "sgtester" already had an ingress rule associated with the group, would "sgtesteringress" overwrite the existing rules or append the new rules to the group?

@alan thanks saved my night

Thank you :)

What does it mean to ingress on the self-security group? What does it do security-wise?

What does it mean to ingress on the self-security group? What does it do security-wise?

It allows compute nodes in that security group to communicate with other compute nodes in the same security group.

And the (untested) YAML equivalent:

Description: Create a VPC with a SG which references itself
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  vpctester:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 172.16.0.0/23
      EnableDnsSupport: false
      EnableDnsHostnames: false
      InstanceTenancy: default
      Tags:
      - Key: Name
        Value: vpctester
  sgtester:
    Type: AWS::EC2::SecurityGroup
    DependsOn: vpctester
    Properties:
      GroupDescription: vpc tester sg
      VpcId: !Ref vpctester
  sgtesteringress:
    Type: AWS::EC2::SecurityGroupIngress
    DependsOn: sgtester
    Properties:
      GroupId: !Ref sgtester
      IpProtocol: tcp
      FromPort: 0
      ToPort: 65535
      SourceSecurityGroupId: !Ref sgtester

How to give all protocols?

@saumilsdk See the IpProtocol documentation:

Use -1 to specify all protocols.

can you help me understand the difference between groupId and sourceSecurityGroupId?

Also, consider for eg, I have an ec2 bastion host, I have an RDS in the private subnet. I want to create a security group on ec2 that allows all inbound ssh traffic through the Internet gateway. I have another security group on RDS that allows inbound traffic from ec2 bastion. How can I do this? should I use sourceSecuritygroupId:<id of ec2's SG> in the ingress of RDS's security group?

@SwathiKanduri the groupId relates to the security group for which this AWS::EC2::SecurityGroupIngress resource is actually an ingress rule. The sourceSecurityGroupId relates to the security group which we want to allow inbound traffic from. In this case they both refer to sgtester because this is a self-referencing security group, but in the general case sourceSecurityGroupId would refer to some other security group that we want to allow inbound traffic from.

Thanks, it was helpful

Thanks!