Sanitized portfolio sample
Sample AWS Security Architecture Review
This page demonstrates the type of structure, language, and prioritization I use in an AWS architecture review. It is not based on a real client environment.
Executive summary
The reviewed architecture has a strong foundation, including account separation and managed AWS services. The highest-priority improvements are least-privilege IAM tightening, stronger detection coverage, explicit network egress controls, and clearer incident response runbooks.
Filter sample findings
Use these filters to explore how findings can be grouped by technical area.
Broad IAM permissions for application roles
Overly broad permissions increase blast radius if a workload is compromised.
Recommended action: Replace wildcard actions/resources with scoped policies based on observed access patterns.
Incomplete centralized logging coverage
Gaps in detection reduce the team's ability to investigate suspicious activity.
Recommended action: Confirm CloudTrail, GuardDuty, VPC Flow Logs, and application logs feed into a retained central location.
No documented incident response runbook
Teams lose time during incidents when roles, escalation paths, and containment steps are unclear.
Recommended action: Create a short AWS incident response runbook and test it with a tabletop exercise.
Network egress assumptions are not documented
Unclear egress paths make it harder to reason about data movement and incident containment.
Recommended action: Document expected egress routes and apply explicit controls where practical.
Detailed finding example
Finding: Application role grants wider access than required
Severity: High
Evidence: The application execution role includes broad read/write permissions across multiple resources even though the workload only requires access to a small set of queues and database secrets.
Impact: If application credentials are abused, an attacker could access or modify resources beyond the intended application boundary.
Recommendation: Create workload-specific IAM policies using scoped resources, condition keys where appropriate, and separate roles for deployment, runtime, and break-glass operations.
Suggested priority: Address within 14 days; validate with access analysis and regression testing.
Example remediation roadmap
- Week 1: Remove unused IAM permissions and confirm no static access keys are used by workloads.
- Week 2: Enable or validate centralized security logs, GuardDuty, and alert routing.
- Weeks 3–4: Harden network boundaries, egress patterns, and secrets access.
- Month 2: Run incident response tabletop and formalize ownership for recurring cloud security reviews.
Notes for real engagements
Real reports are tailored to the in-scope architecture, the maturity of the team, and the evidence provided. I avoid alarmist language and focus on practical improvements that reduce meaningful risk.