3.1.4. Basic Network Security (Security Groups for Apps)
First Principle: Security Groups (SGs) act as stateful virtual firewalls that control inbound and outbound network traffic to your application's compute resources, ensuring basic network isolation and security.
For developers deploying applications on EC2 instances or in a VPC environment, understanding Security Groups is fundamental for basic network security. Security Groups are associated with EC2 instances or Elastic Network Interfaces (ENIs).
Key Characteristics of Security Groups (SGs):
- Instance-Level: Applies to individual EC2 instances or ENIs.
- Stateful: If you allow inbound traffic (e.g., HTTP on port 80), return outbound traffic is automatically allowed for the same connection.
- Allow-Only: You define only allow rules. All other traffic is implicitly denied.
- Rules: Define inbound and outbound rules based on protocol (TCP, UDP, ICMP), port range, and source/destination IP address or other Security Groups.
- Least Privilege: Best practice is to open only the ports and protocols absolutely necessary for your application.
Beyond Security Groups: Traffic Protection Developers Configure
- Encryption in transit (TLS): protects data while it moves over the network. Examples are HTTPS to an API Gateway endpoint (API Gateway serves only HTTPS), an HTTPS listener on port 443 of an Application Load Balancer with an SSL/TLS certificate installed on that listener, and TLS on the database connection from an app to RDS. Encryption at rest (KMS, SSE, default bucket encryption) does not protect data on the wire.
- Certificates: AWS Certificate Manager (ACM) provisions and renews free public certificates for ALB, CloudFront and API Gateway custom domains (in us-east-1 for an edge-optimized API). AWS Private CA runs a private certificate authority that issues certificates for internal services, such as per-microservice client certificates for mutual TLS.
- SSH to EC2 Linux: launch the instance with an EC2 key pair and connect with its private key, with port 22 open in the security group only to your IP. Session Manager (3.2.3) avoids SSH keys and open ports entirely.
- Lambda in a VPC: to reach a private RDS database, attach the function to private subnets with a security group. The function then has no internet path, so it reaches public AWS APIs through a VPC endpoint (a free gateway endpoint for DynamoDB or S3) or a NAT gateway. A public subnet does not help, because Lambda network interfaces get no public IP. The execution role still needs the service permissions.
- AWS WAF: a layer-7 web application firewall attached to an API Gateway REST API stage, an ALB, CloudFront or AppSync. Its managed rule groups block SQL injection and XSS patterns. Shield handles DDoS, and GuardDuty only detects threats; neither filters SQL injection requests.
Scenario: You're deploying a web application on EC2 instances in a public subnet. You need to ensure that only web traffic (HTTP on port 80 and HTTPS on port 443) from the internet can reach your web servers, and that your web servers can only make outbound connections to your backend application servers.
⚠️ Exam Trap: Security Groups are stateful (return traffic is automatically allowed). NACLs are stateless (you must explicitly allow return traffic). If a question mentions explicitly configuring outbound rules, it's likely about NACLs, not Security Groups.
⚠️ Exam Trap: Security Groups attach to network interfaces inside a VPC (EC2, RDS, VPC-connected Lambda, interface endpoints). A public API Gateway API is not a VPC resource, so a Security Group cannot be attached to it. Protect it with IAM, Cognito or Lambda authorizers, a resource policy (e.g., source-IP or VPC-endpoint conditions) and AWS WAF.