Ref: https://learn.cantrill.io/courses/1820301/lectures/41301356

• Summary:
• Contents:

VPC Security Group (SG) - Key Concepts

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/0800-VIRTUAL_PRIVATE_CLOUD(VPC)/00_LEARNINGAIDS/SG-1.png

• 🔧 Stateful firewall attached to Elastic Network Interfaces (ENIs) of AWS resources
  • Unlike NACL, NOT attached to VPC subnets
  • ‼️ SGs are also NOT directly attached to AWS resources!
    • Even if the UI shows you're attaching a SG to an EC2 instance, you're actually attaching a SG to the ENI of the instance!
    • 💡 Conceptually, an SG surrounds the ENI
• Inbound & outbound rules, same as a NACL
  • Rules match traffic entering/leaving the ENI
  • Support for IP/CIDR matching like NACLs
• Stateful → detects response traffic automatically
  • IN/OUT request allowed → OUT/IN response allowed automatically
  • 👍 No need to worry about ephemeral ports
• More features than NACL, since SGs operate on Layer 5 instead of Layer 4
  • Support for logical resource matching!
    • ❗ …including other SGs and itself!
• ‼️ Major limitation: NO explicit deny!!
  • ONLY explicit ALLOW or implicit DENY
  • Rules don't contain an allow/deny effect → if a rule exists, it explicitly allows traffic
    • If SG doesn't explicitly allow the traffic, it's implicitly denying it
  • Can't block specific bad actors → NACL support needed for this

VPC SG - Logical References

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/0800-VIRTUAL_PRIVATE_CLOUD(VPC)/00_LEARNINGAIDS/SG-3.png

• In order to allow a connection to an EC2 instance we can include an SG rule that…:
  1. …references the IP of the EC2 instance
     • 👎 Not very flexible (what if IP changes?)
     • 👎 Not very scalable (what if we need to allow 100 connections?)
  2. …references the CIDR of the subnet where instance resides
     • 👍 allows for scalability → new EC2 instances deployed in the subnet are automatically allowed, also old instances still allowed even if IP changes within subnet
     • 👎 Does not offer much granularity (what if we want to allow most instances in the subnet, but with a few exceptions?)
  3. …references the SG of the EC2 instance or its subnet! → super powerful!
     • SG source = traffic from anything that has that SG attached will be matched
     • 👍 Very scalable
       • SGs can be assigned automatically to newly deployed instances, regardless of what subnet they're in → Relevant connections automatically allowed.
       • SG rules can be stacked/nested when they are referenced in other SGs
     • 👍 Very flexible
       • Doesn't matter if IP changes, or if instances are moved to a new subnet
     • 👍 Maintains granularity
     • 👍 Less admin overhead → No need to worry about IPs/CIDRs
       • Simplifies security management → less prone to errors

SG Self-References

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/0800-VIRTUAL_PRIVATE_CLOUD(VPC)/00_LEARNINGAIDS/SG-4.png

• SGs can have a self-referential rule that allows all traffic
  • Any EC2 instances or other resources with this SG can then communicate with each other
  • Handles any IP changes automatically!
    • Useful if EC2 instances are within an Auto Scaling Group (ASG)
  • Simplified management of any intra-app communications (e.g. MS Domain Controllers or App HA)