Security Best Practices for Amazon EC2
Only use encrypted EBS volumes.
Encrypt your data, snapshots, and disk I/O using the AWS KMS AES-256 algorithm.
Activate your VPC Flow Logs.
Collect IP traffic from and to the network interfaces in your VPCs for further analysis.
Protect your EC2 Key Pairs.
Follow our best practices for managing your access keys.
Securing SSH Access and Managing AWS EC2 Access
Create Key Pairs Using Passphrase
Change SSH from port 22 to a non-standard port
Implement 2FA for SSH access to enhance security or utilize AWS Session Manager for secure, keyless access.
Do not keep private keys in temp or home directories
Do not keep unused EC2 key pairs
Leverage IAM roles for EC2.
Limit access only to required resources using IAM policies and roles.
Adopting AWS Session Manager can eliminate the need for SSH access via port 22, reducing the attack surface.
AWS Session Manager streamlines secure access by eliminating the complexity of managing SSH key pairs
Grant least privilege
Use groups to assign permissions to IAM users
Enable MFA for all users, including service accounts
Rotate credentials regularly at a minimum of 90 days once
Do not use your root account access keys
Do not share access using Access Key & Secret Key
Do not have a single role for all the users
Do not use old access keys. Rotate it.
Control inbound and outbound traffic to your EC2 Instances with clearly structured Security Groups.
A Security Group is a virtual, easy-to-use firewall for each EC2 instance controlling inbound and outbound traffic.
Restricted access to instances. Keep only those instances in a public subnet that need access directly from the internet.
You must create several subnets per your architecture and ensure that only those instances that need to be accessed from the outside world are kept inside a public subnet.
Use a bastion host to access private machines within your VPC
Limited access to ports
Open only specific ports
Use non-standard ports for your internal applications. Try to use non-standard ports for your internal applications.
This would add an extra layer of defense as the attack would not be able to guess the service from the port number. For example, if you are using MySQL, set it up to a custom port rather than to the default 3306.
ELB listener security. Instead of having HTTPS/SSL termination in your instances, having it at your ELB level is recommended.
Enable VPC flow logs.
Enable VPC flow logs is recommended.
You can configure it to capture both accept as well as reject entries. These logs can be powerful in keeping track of all the packet movements across your VPC network.
Never create security group rules like 0.0.0.0/0
You need to follow the rule of least privilege here as well.
It is important not to open port 22 for everyone.
Do not allow UDP / ICMP on private instances
Do not use IPs to allow intra-instance network access.
Instead of using IPs to allow intra-instance network access, use security groups to allow network access. This ensures that even if the IPs change, you do not lose your security to someone who may now have your previous IP
EC2 Termination Protection
If the AWS EC2 instances don’t have API termination protection enabled, it may lead to accidental termination of machines through an automated process. It is recommended that termination protection is enabled for all the mission-critical EC2 instances running in your AWS cloud account. This is a good EC2 security group best practice.
Unused Security Group
If certain security groups are not used or attached to any instances, it is recommended to remove these security groups.
Subscribe to my newsletter
Read articles from Niranjan G directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Niranjan G
Niranjan G
I am a persistent and detail-oriented cybersecurity professional, boasting over 17 years of dedicated experience in the field.