How to Secure an AWS Server: Checklist

Security is rarely one big decision — it's a series of smaller, unglamorous defaults that compound into a much harder target. Here's a practical checklist covering the fundamentals.

Access and identity

• Use IAM roles for AWS service access instead of hardcoded access keys wherever possible
• Apply least-privilege permissions — grant only the specific access a role or user actually needs, not broad admin access "to be safe"
• Enable multi-factor authentication (MFA) on your AWS root account and any IAM users with meaningful permissions
• Never use the AWS root account for day-to-day work. Prefer IAM Identity Center or roles with temporary credentials instead of creating more long-lived IAM users.
• Use separate named identities; never share console users or SSH private keys
• Review unused roles, policies and credentials on a defined schedule

For administration, consider AWS Systems Manager Session Manager instead of exposing SSH to the internet. Session Manager can provide identity-based access and session logging without distributing inbound SSH keys, provided the instance role, agent, network path and logging destination are configured correctly.

Network security

• Restrict SSH access (port 22) to specific known IP ranges, not 0.0.0.0/0
• Only open the ports your application actually needs
• Keep databases in private subnets with no direct public internet access
• Use security groups as your primary access control, and treat network ACLs as a secondary layer

Data protection

• Enable encryption at rest for EBS volumes, RDS databases, and S3 buckets
• Use HTTPS everywhere — no production traffic should be served over plain HTTP
• Don't commit AWS credentials or secrets to your code repository, ever — use environment variables or AWS Secrets Manager

Require Instance Metadata Service Version 2 (IMDSv2) on EC2 where compatible. IMDSv2 uses session-oriented requests and reduces exposure to several metadata-access attack paths. Test older agents and applications before enforcing it.

Monitoring and detection

• Enable CloudTrail to log account-level API activity, so you have a record if something unexpected happens
• Consider GuardDuty for automated threat detection — it flags unusual account behavior without requiring you to manually watch logs
• Set up basic CloudWatch alarms for unusual patterns (a spike in failed login attempts, for example)

Send important logs to a controlled destination with explicit retention and restricted deletion rights. At minimum, review CloudTrail coverage, operating-system authentication logs, application errors, load balancer access logs where useful, and security findings. An unowned log archive is not detection; route meaningful findings to a person or response process.

Patching and updates

• Keep your operating system and installed packages up to date
• Keep application-level dependencies (WordPress plugins, npm packages, Composer packages) updated — outdated software is one of the most common attack vectors
• Have a defined process for applying security patches promptly, not "whenever someone gets around to it"

Use Amazon Inspector or another supported vulnerability-management process to identify exposed software and package vulnerabilities. Define severity-based remediation targets, exception ownership and evidence that the fix was deployed. A scanner without a remediation process only creates a backlog.

Backup and recovery

• Maintain automated backups with a tested restore process
• Store backups somewhere separate from your primary infrastructure, so a compromise of one doesn't also compromise your backups

For workloads where account compromise is part of the threat model, evaluate a separate backup account, restricted vault permissions and logically immutable controls. Test that the recovery identity can restore data even if normal production administration is unavailable.

Secure the application path

Server hardening does not protect an application with vulnerable code or unsafe authentication. Keep the operating system, runtime, framework and dependencies within supported versions. Place internet-facing applications behind TLS, validate headers and cookies, protect administrative endpoints, and evaluate AWS WAF where its managed and custom rules match the threat and operating capacity.

Do not install a security control without monitoring its effect. WAF rules, host firewalls and intrusion-prevention tools can block legitimate traffic or create a false sense of protection when left in count-only or default modes indefinitely.

Minimum monthly security review

Review	Question to answer
Identity	Which privileged identities, keys and role trusts changed?
Exposure	Which instances, databases, load balancers and ports are publicly reachable?
Vulnerabilities	Which critical or high findings remain open, and who owns them?
Detection	Did alerts reach the expected owner, and were any findings ignored?
Patching	Are the OS, runtime and application dependencies still supported?
Recovery	Can protected data be restored using the documented recovery identity?

Record evidence, not only checkbox status

Control area	Evidence an operator can verify
Root account	MFA enabled, no root access keys, recovery contacts controlled
Human access	Named identities, temporary sessions, least-privilege review
Workload identity	Instance or task roles; no credentials in code or images
Network exposure	Reviewed security-group rules and public resource inventory
Detection	CloudTrail coverage, log destination, alert owner, tested notification
Recovery	Protected resources, retention, isolation, latest restore result
Vulnerability management	Patch policy, last scan or review, remediation ownership

This is a baseline, not a compliance certification. The required controls depend on the workload, data classification, contractual obligations, and threat model.

Verify with AWS

• AWS root user best practices
• AWS Foundational Security Best Practices
• Connect to instances with Session Manager
• Configure EC2 instance metadata options

Why this list matters more than any single item

No single item on this list is sufficient on its own. A structured review should produce evidence, owners and remediation dates rather than a collection of unchecked recommendations.

Use the server health checklist for an initial operational review. For a scoped assessment of identity, exposure, patching, detection and recovery, request an AWS server security review.

Related reading: What is VPC in AWS? Plain English Explanation, AWS Backup Best Practices for Businesses