Cloud security is not a single AWS service. It is a set of everyday choices about access, configuration, monitoring, and recovery.
AWS secures the underlying cloud infrastructure. Your organisation remains responsible for what it deploys, who can access it, how data is protected, and how incidents are detected and handled. This shared responsibility model is the foundation of every AWS security plan.
1. Secure the root account
The root user has complete control of the AWS account. Treat it as an emergency account, not an administrator account for daily use.
- Enable multi-factor authentication immediately.
- Use a strong, unique password stored securely.
- Do not create access keys for the root user.
- Use IAM identities or AWS IAM Identity Center for normal administration.
- Ensure billing and security contacts are current.
2. Give people only the access they need
Avoid shared AWS accounts and broad administrator access for every developer. Use roles and policies based on job responsibilities.
An application should use an IAM role to access S3, Secrets Manager, or other AWS services. It should not depend on access keys written into a configuration file. A developer who needs read-only access to logs should not automatically have permission to delete a database.
Review permissions regularly, especially after a staff member changes teams or leaves the company.
3. Protect credentials and application secrets
Database passwords, JWT signing keys, payment credentials, SMS provider keys, and third-party API tokens should never be committed to Git repositories or inserted directly into container images.
Use AWS Secrets Manager or Systems Manager Parameter Store. Restrict which IAM roles can read each secret. Rotate sensitive credentials where the application and vendor support it.
If a secret is exposed, replace it immediately. Deleting it from a Git commit does not make it safe again.
4. Log what matters
You cannot investigate an incident if there is no record of what happened.
At minimum, enable and review:
- CloudTrail for AWS account and API activity.
- CloudWatch Logs for applications, load balancers, and infrastructure.
- VPC Flow Logs where network-level visibility is needed.
- AWS Config to track configuration changes and assess rules.
- GuardDuty for threat detection signals.
Logs need defined retention, access control, and alerting. They should not contain passwords, access tokens, full payment information, or one-time passwords.
5. Encrypt data and connections
Use HTTPS for public applications. Encrypt sensitive data at rest using AWS-managed encryption or customer-managed KMS keys when the security model requires it.
For common services, this includes enabling encryption for S3, EBS, RDS, backups, and logs where appropriate. Encryption is important, but access control is equally important. An encrypted file is still exposed if an overly broad role can read it.
6. Reduce network exposure
Security groups should allow only the traffic required by the application. A database should normally accept traffic from the application layer, not from the entire internet.
Avoid rules such as 0.0.0.0/0 for SSH, RDP, database ports, and internal service ports. If administrative access is necessary, restrict it using VPN access, a bastion approach, AWS Systems Manager Session Manager, or tightly controlled IP ranges.
7. Back up and test restoration
Backups protect availability and integrity after accidental deletion, ransomware, failed deployments, or infrastructure mistakes. Define backup frequency, retention, encryption, access, and restore responsibility.
Then test a restore. A backup that has never been restored is an assumption, not evidence.
8. Prepare for misuse and attacks
Public applications should have practical protections against automated abuse. Use AWS WAF for web-layer controls where appropriate, rate-limit sensitive endpoints such as login and OTP requests, and monitor unusual spikes in requests, errors, or outbound messages.
Security controls must be matched to the application. A public API may need different protection from a staff-only internal tool.
Final thought
Security improves when it becomes part of deployment and operations, not a task saved for an audit. Start with identity, secrets, logs, network exposure, and recovery. Those five areas prevent a large share of avoidable cloud incidents.