Security Groups and Key Pairs

A security group is a virtual stateful firewall that controls inbound and outbound traffic to and from an EC2 instance (or other AWS resources like RDS, Lambda, ELB). Security groups operate at the instance level—each rule specifies a protocol (TCP/UDP/ICMP), port range, and source/destination (IP range or another security group). Unlike traditional firewalls, security groups are stateful: if you allow inbound traffic, the response traffic is automatically allowed outbound without an explicit rule.

Security groups have separate inbound and outbound rule sets. Inbound rules control traffic arriving at the instance—by default, all inbound traffic is denied. Outbound rules control traffic leaving the instance—by default, all outbound traffic is allowed. You add explicit Allow rules; there are no explicit Deny rules in security groups (use Network ACLs for explicit denies). All rules in a security group are evaluated together using a logical OR—any matching Allow rule permits the traffic.

Security groups support source/destination security group references, which is more flexible and secure than specifying IP ranges. For example, an ALB security group allows 0.0.0.0/0 on port 443. The EC2 instances' security group allows inbound port 8080 only from the ALB security group ID—not from any IP. If an ALB is replaced or scaled, the rule still applies correctly without IP changes. This pattern creates a layered, dynamic defence for multi-tier architectures.

Stateful means the security group tracks connection state. If your inbound rule allows TCP port 80 from the internet and a client makes a request, the response packets (outbound) are automatically allowed back to the client—even if there is no outbound rule for port 80. This is fundamentally different from Network ACLs, which are stateless and require explicit rules for both directions of traffic. Statefulness makes security groups easier to configure for typical application traffic patterns.

You can attach multiple security groups to a single EC2 instance (up to 5 by default, adjustable). The rules from all attached security groups are combined using a union (OR logic)—if any security group allows a request, the request is permitted. This means security groups can only add permissions, never restrict them—if you want to tighten access, you must remove or modify rules, not add a more restrictive security group. Keep this additive behaviour in mind for exam questions about access restriction.

Every VPC includes a default security group. Its default rules: inbound allows all traffic from other instances also in the default security group; outbound allows all traffic to anywhere. This is deliberately permissive so new instances can communicate by default. For production environments, create a custom security group with a locked-down inbound rule set and remove instance associations with the default security group to avoid accidental exposure.

EC2 key pairs use asymmetric cryptography for SSH authentication. AWS generates the key pair (or you import your own public key): AWS stores the public key and injects it into the instance at launch; you download and store the private key (.pem file)—AWS never stores it. SSH uses the private key to prove your identity to the server without transmitting a password. The private key must have restrictive permissions (chmod 400) or SSH will refuse to use it.

If you lose the private key for a Linux EC2 instance, you cannot SSH in conventionally. Recovery options include: Systems Manager Session Manager (if the SSM agent is running and an IAM role is attached—no key needed), EC2 Instance Connect (injects a temporary key via browser or CLI—requires an open SSH port and EIC permissions), or stop the instance, detach the root EBS volume, attach it to another instance, modify the authorized_keys file, re-attach and restart. For Windows, use Systems Manager to retrieve the password.

Leaving SSH (port 22) open to 0.0.0.0/0 exposes your instance to brute-force and credential-stuffing attacks from anywhere on the internet. Best practices: restrict SSH to your specific corporate IP range or use a bastion host (jump box) in a public subnet with a tightly controlled security group, then SSH from the bastion to private instances. Better still, use Systems Manager Session Manager to eliminate SSH port exposure entirely—no inbound rules needed at all.

Key default limits for security groups (adjustable via Service Quotas): up to 2,500 security groups per VPC, 60 inbound and 60 outbound rules per security group, and 5 security groups per network interface. When referencing another security group as a source, each referenced security group–rule combination counts as a rule. If you hit rule limits, consolidate by referencing security group IDs instead of individual IP ranges, or use prefix lists to group multiple CIDRs into one manageable entity.

A managed prefix list is a set of CIDR blocks that you can reference in security group rules or route tables. AWS maintains AWS-managed prefix lists for services like S3 and CloudFront, so you can allow traffic to/from these services without maintaining IP ranges yourself (which change over time). You can also create customer-managed prefix lists to group your corporate IP ranges—update the prefix list in one place and all security groups referencing it inherit the change automatically.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: security groups are stateful virtual firewalls that allow traffic by default deny, chaining security groups by ID is more secure and flexible than using IP ranges, and key pairs provide asymmetric SSH authentication while Systems Manager Session Manager removes the need for open SSH ports. Next up we cover EC2 storage options: Instance Store vs EBS.