Key takeaway
Start by assigning an owner to each resource. Then restrict access, protect data, record changes and test recovery.
Govern accounts and identities
Inventory the AWS accounts used for production, testing and log archives, and assign a technical owner to each. Give people access through centralized identity; where possible, use IAM roles and temporary credentials for workloads instead of long-lived keys. Limit permissions to what each role needs, require multifactor authentication for privileged access, and review unused users, roles and keys. Keep the root user out of routine work.
Review data exposure and resource access
Record data sensitivity and whether public access is justified. For S3, review Block Public Access, bucket policies and Object Ownership. Bucket owner enforced disables ACLs; inspect ACLs only when enabled, without enabling them for this review. Document necessary exceptions and get the data owner’s approval. Check that sensitive data is encrypted in storage and transit, and define who can use and administer keys. Keep application secrets in an approved secrets-management system rather than source code. Choose encryption and key policies for the service in question; one setting does not remove every AWS resource risk.
Record changes and monitor the baseline
Plan AWS API activity logging with CloudTrail and send logs to a centrally controlled archive; choose the event types your investigations require. Use AWS Config or an equivalent control to record resource configurations and identify drift from an approved baseline. Assign an alert owner and escalation path. Logging does not stop an incident by itself, so verify log completeness, retention, searchability and operational use separately. Distinguish management events from selected data events such as S3 object reads and writes. Trails and event data stores do not log data events by default; check event selectors for the resources and operations required.
| Question | Evidence to inspect | What remains to verify |
|---|---|---|
| Administrative change | Management-event record | Account-region coverage and retention |
| Object read/write | Selected data-event record | Event selector coverage |
| Configuration drift | Configuration history or baseline finding | Owner and remediation |
| Recovery | Restore result | Dependencies and measured recovery results against targets |
Protect workloads and recovery
For IaaS resources such as EC2, define the customer’s work for the guest OS, applications, network rules and patches. Choose a scanner that discovers assets and keeps vulnerability data current; route findings to an owner and patch window, because scanning does not fix a weakness by itself. Build environments from reviewed infrastructure-as-code templates, review changes, and check for unexpected open ports, public storage, excessive permissions and outdated packages. Keep backups where the same incident is less likely to affect both the source and copies, and practise restoration. Responsibility for managed services varies by service, so check its documentation.
Plan resilience and safe change
Spreading components across availability zones can reduce the effect of a failure only when the application, dependencies and data replication are designed for it. Test dependencies, health checks and traffic failover for critical services, and protect backups separately. Distribution across zones and replication do not replace isolated recovery copies and tested restores. Review infrastructure-template changes and keep a rollback path. Set recovery objectives for each service and data class, then validate them in an exercise.