Audit logging is the one control that cannot be applied retrospectively. Every other hardening step can be done later; the record of what happened last month either exists or it does not.
Enable these immediately
- Control-plane audit logs: who called which API, when, from where.
- Authentication events, including failures.
- Changes to identity, permissions and policies.
- Network flow logs, at least for anything internet-facing.
- Access logs for storage holding sensitive data.
Protect the logs from the thing you are logging
An attacker with administrative access will delete evidence if they can. Ship logs to a destination the workload account cannot modify – a separate account or an append-only store – and restrict who can change retention settings.
| Decision | Guidance |
|---|---|
| Where they live | A separate account or project where possible. |
| Who can delete them | Ideally nobody; certainly not workload administrators. |
| Retention period | Long enough for your obligations and investigations. |
| Storage class | Move older logs to cheaper tiers rather than deleting. |
| Integrity | Enable object locking or equivalent if available. |
Alerts worth setting on security events
- Any use of the root or owner identity.
- Creation of a new administrative identity or access key.
- Changes to logging configuration or retention.
- Authentication from an unexpected country or an unusual pattern of failures.
- A sudden change in daily spend.
Five alerts, each rare and each meaningful. That is a channel people will still trust in six months.
Retention is a decision, not a default
Default retention is often short and set for convenience rather than for your needs. Investigations frequently reach back further than people expect, and some obligations specify a minimum. Set it deliberately and budget for the storage.
Summary
Turn logging on before the first workload, send it somewhere the account cannot edit, set retention on purpose, and keep a handful of high-signal alerts. This is the control you cannot add later.
