In the previous parts of this EC2 series, we explored Amazon EC2 as a compute service and examined how to choose appropriate instance types and pricing models. Once an instance is launched, however, the most critical questions become: How does it communicate? Who can access it? And how is that access controlled securely?
This blog focuses on the networking and access mechanisms that govern EC2 instances, with an emphasis on security groups, key pairs, and common connectivity patterns.
EC2 and the Amazon VPC
Every EC2 instance runs inside an Amazon Virtual Private Cloud (VPC). The VPC defines the network boundary for your instances and determines how they communicate internally and externally.
Key VPC components that affect EC2 include:
- Subnets (public and private)
- Route tables
- Internet gateways
- NAT gateways
- Network ACLs
While VPC architecture deserves its own deep dive, it is important to understand that EC2 networking behavior is always constrained by the VPC configuration.
Public vs Private Subnets
An EC2 instance’s accessibility depends primarily on the subnet it is placed in.
Public subnet
- Has a route to an Internet Gateway
- Instances can have public IP addresses
- Used for bastion hosts, load balancers, and public-facing services
Private subnet
- No direct route to the internet
- Instances are not publicly accessible
- Used for application servers, databases, and internal services
Most production systems place EC2 instances in private subnets and expose them through controlled entry points.
Security Groups: Instance-Level Firewalls
Security groups act as stateful firewalls that control inbound and outbound traffic to EC2 instances.
Important characteristics:
- Rules are evaluated at the instance level
- Only allow rules are defined (no explicit denies)
- Return traffic is automatically allowed
- Changes take effect immediately
Security groups define what traffic is permitted, not what is blocked.
Inbound Rules
Inbound rules control who can initiate connections to an instance.
Typical examples:
- Allow HTTP (80) from a load balancer
- Allow SSH (22) only from a bastion host
- Allow application ports only from specific security groups
Restricting inbound access is one of the most important security practices in EC2 environments.
Outbound Rules
Outbound rules control where an instance can send traffic.
In many setups, outbound traffic is left open, but in regulated environments it is common to restrict outbound access to known destinations.
Network ACLs vs Security Groups
Security groups are often confused with network ACLs.
Security groups
- Stateful
- Applied at the instance level
- Recommended for most access control
Network ACLs
- Stateless
- Applied at the subnet level
- Useful for broad traffic restrictions or compliance requirements
In practice, security groups handle fine-grained access, while network ACLs provide coarse-grained controls.
Key Pairs and Instance Authentication
EC2 instances do not use passwords by default. Instead, they rely on key pairs for authentication.
A key pair consists of:
- A public key (stored on the instance)
- A private key (stored securely by the user)
This mechanism ensures secure, passwordless access to instances.
SSH Access (Linux Instances)
For Linux-based instances:
- SSH is used for remote access
- Private keys must be protected carefully
- Key rotation should be planned
Best practices include:
- Never sharing private keys
- Using bastion hosts or SSM instead of direct SSH
- Removing unused keys promptly
RDP Access (Windows Instances)
Windows instances use RDP for access. The administrator password is encrypted and can be retrieved using the instance’s key pair.
Security considerations are similar: access should be tightly controlled and monitored.
Bastion Hosts and Access Patterns
Direct access to EC2 instances is rarely recommended in production.
A common pattern includes:
- A bastion host in a public subnet
- Private instances accessible only through the bastion
- Strict security group rules limiting access
This pattern reduces the attack surface and improves auditability.
Using AWS Systems Manager for Access
AWS Systems Manager (SSM) offers a modern alternative to SSH and RDP.
Benefits include:
- No open inbound ports
- No key management
- Centralized access logging
- IAM-based permissions
SSM is increasingly considered the preferred access method for EC2 instances in secure environments.
Elastic IPs and Public Connectivity
Elastic IPs provide static public IP addresses that can be attached to EC2 instances.
Use cases include:
- Legacy systems requiring fixed IPs
- Failover scenarios
However, Elastic IPs should be used sparingly, as they increase public exposure.
Common Security Anti-Patterns
- Allowing SSH or RDP from
0.0.0.0/0 - Using shared key pairs across teams
- Exposing instances directly instead of using load balancers
- Running production workloads in public subnets
- Ignoring outbound traffic controls
Avoiding these patterns significantly improves security posture.
Conclusion
EC2 networking and access control form the first line of defense in AWS environments. A solid understanding of VPC placement, security groups, key pairs, and access patterns is essential for building secure and maintainable systems.
In Part 4, we will examine EC2 storage options, including EBS, instance storage, snapshots, and data durability strategies.
Top comments (0)