In order for the 10.0.0.88 instance to access the Internet (or EC2) via the Internet Gateway (IGW), the instance either needs to have an associated Elastic IP Address or needs to be talking through a NAT instance (which has an Elastic IP Address).
To lock down an EC2 security group to allow traffic from the VPC instance, specify the allowed source as the Elastic IP Address from either the instance itself or the NAT instance, as discussed above (ex. 192.0.2.25/32).
Referencing the default security group is possible using:
{ "Fn::GetAtt" : ["VPC", "DefaultSecurityGroup"] }
Where "VPC" is your VPC resource name.
With AWS::EC2::SecurityGroupIngress and AWS::EC2::SecurityGroupEgress, you can augment the permissions of this default security group.
I think this is what you want:
"VPCDefaultSecurityGroupIngress": {
"Type" : "AWS::EC2::SecurityGroupIngress",
"Properties" : {
"GroupId": { "Fn::GetAtt" : ["VPC", "DefaultSecurityGroup"] },
"IpProtocol":"tcp",
"FromPort":"22",
"ToPort":"22",
"CidrIp":"0.0.0.0/0"
}
},
As mentioned by @artbristol and @gabriel, this allows Ingress/Egress rules to be added to the default security group for the VPC in a single stack deployment.
I'm pretty sure that the self-referential problem still impacts any attempts at changing any of the other properties on the default security group of the VPC. A good example of this would be adding Tags, or a Description. If you wish to change these things, you'll have to deal with extraneous security groups laying around.
Best Answer
When you say you "whitelisting that SG in other SGs" what exactly do you mean?
I would simply create a single security group with these rules and assign that security group to all instances. An instance can have multiple security group, and rules are additive in a permissive sense. ie default deny, unless any rule in any security group allows access. You will have to create new instances to change the security groups associated with an EC2 instance, but once it's associated with the groups any changes made are done in real time.
You could also do it with network ACLs, which work at a subnet level. NACLs are like a firewall, they run at the subnet level, though each NACL can apply to multiple subnets. They can add more "deny" rules that apply to all instances in the subnet but can't open up ports that security groups have closed. Remember they're stateless so you need to add incoming and outgoing rules.
Note that the question/answer you linked to is a very specific situation which doesn't apply to you, regarding using private or public IPs. Security groups apply to private EC2 IPs or public IPs. For example I have security groups set up that allow access only by my CDN provider and my home IP address, which are definitely public IPs.