AWS Server Hardening Guide: A Practical EC2 Baseline

AWS server hardening is not a single tool, firewall rule, or one-time checklist. A hardened EC2 server is built from repeatable decisions: who can reach it, what software runs on it, how changes are patched, where logs go, and how quickly the team can recover if something goes wrong.

This guide focuses on a practical hardening baseline for EC2-backed workloads such as web servers, application servers, bastion replacements, WordPress hosts, Laravel apps, internal APIs, and small business production systems.

It is not a compliance certification. Treat it as a starting point for a scoped review.

1. Start with the server's purpose

Before changing rules or installing agents, document what the server is supposed to do.

Question	Why it matters
What workload runs here?	A web server, worker, database, and admin box need different controls.
Who owns it?	Every server needs a technical owner and business owner.
Which ports are required?	Hardening starts by removing unnecessary reachability.
What data does it touch?	Data classification affects encryption, logging, backup, and access.
How is it rebuilt?	A server that cannot be rebuilt is harder to patch safely.

If the team cannot answer these questions, the first hardening task is inventory, not tooling.

2. Lock down AWS account and IAM access

A secure instance can still be compromised through excessive AWS permissions. Harden identity before hardening the operating system.

Use this baseline:

• Protect the root user with MFA and avoid using it for normal administration.
• Prefer IAM Identity Center or federation for human access.
• Use IAM roles for EC2 workloads instead of storing AWS access keys on the server.
• Grant least-privilege permissions to the instance role.
• Review and remove unused users, roles, policies, and access keys.
• Use CloudTrail evidence when reducing permissions, but test changes before production.

For EC2 workloads, the instance profile should only allow actions the application actually needs. A web server that uploads invoices to one S3 bucket does not need broad S3, EC2, IAM, or administrator permissions.

3. Prefer Session Manager over public SSH

Public SSH is one of the most common exposure points. Where possible, use AWS Systems Manager Session Manager for administrative access instead of opening port 22 to the internet.

Session Manager can reduce risk because:

• It does not require an inbound SSH port.
• Access can be controlled with IAM policies.
• Sessions can be logged when configured.
• You avoid distributing long-lived SSH private keys between operators.

This does not mean SSH is always forbidden. Some environments still need SSH for specific tools or emergency paths. If SSH remains enabled:

• Restrict source IPs in the security group.
• Disable password authentication.
• Disable direct root login.
• Use named users, not shared accounts.
• Rotate keys when staff or vendors change.
• Alert on repeated failed logins.

Do not leave 0.0.0.0/0 on SSH because "we will fix it later." Later is where incidents breed. Tiny gremlin, big bill.

4. Require IMDSv2 where compatible

The Instance Metadata Service can provide temporary credentials and instance information to software running on EC2. Harden metadata access by requiring IMDSv2 where your agents and applications support it.

For new instances, configure metadata options at launch or through account-level defaults. For existing instances, test first, then move toward:

• HttpTokens=required
• Metadata endpoint enabled only when needed
• A controlled hop limit, especially for containerized workloads
• No exposure of unnecessary tags through metadata

Be careful: older agents, scripts, or applications that only support IMDSv1 may break when IMDSv2 is enforced. Test in staging before applying this broadly.

5. Reduce network exposure

Security groups should describe the minimum traffic required for the workload.

For internet-facing applications:

• Put only the load balancer or public web tier in public subnets.
• Keep databases, queues, caches, and internal services private.
• Allow HTTP/HTTPS only where required.
• Restrict admin ports to trusted sources or remove them entirely.
• Prefer outbound rules that match actual dependencies where practical.

For private applications:

• Avoid public IPs.
• Use private subnets.
• Use VPC endpoints for AWS service access where useful.
• Route administrative access through Session Manager, VPN, or a controlled network path.

Network ACLs can provide another layer, but security groups are usually the primary day-to-day control. Keep them readable. A clever rule nobody understands becomes operational debt.

6. Harden the operating system baseline

The OS hardening baseline depends on the distribution, but the pattern is consistent.

Minimum Linux baseline:

• Use a supported operating system version.
• Remove unused packages and services.
• Keep only required users and groups.
• Disable password login for SSH if SSH is used.
• Use sudo deliberately; avoid permanent shared admin shells.
• Configure host firewall rules if they add meaningful defense inside the instance.
• Keep system time synchronized.
• Set safe file permissions for application secrets, deploy keys, and configuration.
• Send logs off the server before an attacker or disk failure can erase the only evidence.

Avoid installing random "hardening scripts" from the internet. They often make broad changes without explaining tradeoffs, and they can break package management, networking, monitoring, or recovery.

7. Encrypt storage and protect secrets

Enable EBS encryption for boot and data volumes, and use AWS KMS keys where your governance model requires customer-managed keys. Encryption does not replace access control, but it reduces risk around snapshots, backups, and storage handling.

Also harden secrets:

• Do not store AWS keys in application files.
• Do not commit .env files to source control.
• Use AWS Secrets Manager, Parameter Store, or your deployment platform's secret store.
• Limit which role can read each secret.
• Rotate secrets after vendor access, staff changes, or suspected exposure.

If a secret has lived in a repository, assume it is compromised and rotate it. Removing it from the current file is not enough because git history may still contain it.

8. Patch with a process, not vibes

Hardening decays. A server that was safe three months ago can become risky after new CVEs, dependency updates, package changes, and forgotten exceptions.

Define a patching process:

• Use Systems Manager Patch Manager or a documented patch workflow.
• Scan regularly for missing patches.
• Set severity-based remediation targets.
• Test application health before and after patching.
• Plan reboots instead of avoiding them indefinitely.
• Record exceptions with an owner and expiry date.

For small teams, a simple weekly security patch window is often better than a sophisticated process nobody follows.

9. Scan for vulnerabilities and unintended exposure

Amazon Inspector can scan EC2 instances for package vulnerabilities and network reachability issues. Use it or another vulnerability-management process, but make sure findings become work items.

A practical vulnerability workflow includes:

Finding level	Suggested action
Critical exposed service	Triage immediately; restrict exposure or patch quickly.
Critical local package	Patch in the next emergency or accelerated window.
High	Assign owner and target date.
Medium/Low	Batch into routine patching unless context raises risk.
Accepted exception	Record business reason, compensating control, owner, and expiry.

The scanner is not the control. Remediation is the control.

10. Centralize logs and detection

If a server is compromised, local logs may be modified or deleted. Send important logs to a controlled destination with retention and restricted deletion rights.

At minimum, review these signals:

• CloudTrail management events
• GuardDuty findings
• Inspector findings
• OS authentication logs
• Web server access and error logs
• Application errors
• Load balancer logs where useful
• Backup and restore job results

Use CloudWatch alarms, Security Hub, ticketing, email, Slack, or another path that reaches a real owner. Alerts that nobody owns are just decorative noise.

11. Protect backup and recovery paths

Hardening should assume failure is possible. If the server is corrupted, deleted, encrypted by malware, or misconfigured during a change, the team needs a recovery path.

Baseline recovery controls:

• Automated EBS snapshots or AWS Backup plans.
• Separate retention for important data.
• AMIs or infrastructure-as-code templates for rebuilds.
• Documented restore steps.
• Periodic restore tests.
• Restricted delete permissions on backups.
• Separate account or vault controls for higher-risk workloads.

Backups are not proven until someone restores them and records the result.

12. Production hardening checklist

Use this as a quick review before launch or after inheriting an existing AWS server.

Area	Hardened baseline
Identity	Root protected, MFA enabled, named access, workload role attached
Admin access	Session Manager preferred; SSH restricted if still required
Metadata	IMDSv2 required where compatible
Network	Only required ports open; data tiers private
OS	Supported version, patched, unused services removed
Secrets	No long-lived AWS keys on disk or in code
Storage	EBS volumes and snapshots encrypted
Patching	Defined scan/install/reboot process
Vulnerabilities	Inspector or equivalent scanning with owners
Logging	CloudTrail and server logs retained centrally
Detection	GuardDuty/Security Hub/alerts routed to an owner
Recovery	Backups automated and restore-tested

Hardening mistakes we see often

• Opening SSH globally for convenience.
• Using one shared administrator key.
• Running production on an end-of-life OS.
• Treating security groups as documentation while nobody reviews them.
• Installing monitoring but not configuring actionable alerts.
• Enabling backups without testing restore.
• Giving the EC2 role broad permissions because "the app might need it."
• Leaving old vendor users and keys after a project ends.
• Patching only the OS while ignoring application dependencies.
• Keeping the only copy of deployment notes on the server being protected.

Verify with AWS

• Best practices for Amazon EC2
• IAM security best practices
• AWS Systems Manager Session Manager
• Configure EC2 instance metadata options
• AWS Systems Manager Patch Manager
• Scanning EC2 instances with Amazon Inspector
• Amazon EBS encryption
• CloudTrail security best practices
• What is Amazon GuardDuty?

The practical takeaway

AWS server hardening is about narrowing access, reducing exposed services, keeping software current, preserving evidence, and proving recovery. Start with the controls that remove the biggest risk: identity, admin access, public exposure, patching, logs, and backups.

If you want a fast first pass, use the AWS Infrastructure Health Assessment. For a deeper review of EC2 exposure, IAM roles, patching, logs, and recovery evidence, request an AWS server security review.

Related reading: How to Secure an AWS Server: Checklist, AWS IAM Roles vs Users: A Secure Access Guide, AWS Monitoring: Metrics, Logs, and Traces Guide