You know your IAM policies are too permissive. You're pretty sure there are S3 buckets that shouldn't be public. Maybe you have a SOC 2 audit coming and you're not sure what "ready" looks like on AWS. These are the problems I solve.
Most AWS security incidents trace back to misconfigurations, not sophisticated attacks. Overly permissive IAM, unencrypted data, missing logging. The shared responsibility model means AWS secures the infrastructure, but everything you build on top is yours to protect.
Security isn't about implementing every control
It's about understanding your risk profile and prioritizing protections that matter for your specific environment. A startup with no sensitive data needs a different posture than a healthcare SaaS handling PHI.
I focus on the fundamentals that prevent most breaches: tight IAM policies, encryption everywhere, and comprehensive logging. These aren't glamorous, but they're what actually stops attackers.
Key security areas
Identity & Access
Least-privilege IAM, MFA enforcement, Service Control Policies, IAM Access Analyzer. The controls that prevent most breaches.
Data Protection
Encryption at rest and in transit, KMS key management, Secrets Manager, S3 bucket policies that prevent accidental exposure.
Detection & Monitoring
CloudTrail, GuardDuty, Security Hub, and CloudWatch alarms. Know when something's wrong before customers tell you.
Compliance Readiness
SOC 2, HIPAA, PCI-DSS. Proper logging, encryption, access controls, and audit trails built into the architecture from the start.
How exposed are you?
Uncheck the ones you've already addressed.
Multi-tenant SaaS security
A single authorization bug shouldn't expose one customer's data to another. I design systems with multiple isolation layers: tenant context in every API request, row-level security at the database, IAM policies scoped to tenant resources, and audit logging that tracks cross-tenant access attempts.
For enterprise customers with strict isolation requirements, I've implemented cellular architectures using AWS Organizations: separate accounts per customer with centralized management and consistent security baselines.
How an engagement works
Assessment
What's running, who has access, what's being logged. I map your current security posture against your actual risk profile.
Prioritized remediation
Not everything is critical. I focus on the gaps that could actually be exploited, ranked by likelihood and impact.
Implementation
IAM policy rewrites, encryption configuration, logging setup, network hardening. Working infrastructure, not just a PDF report.
Compliance mapping
For teams pursuing certifications: bridging the gap between technical controls and auditor expectations, with automated evidence collection.
Frequently Asked Questions
What is the AWS shared responsibility model?
AWS secures the underlying infrastructure (physical data centers, hypervisors, managed service internals), while you're responsible for everything you build on top: IAM policies, network configurations, data encryption, application security, and operating system patches. Most security incidents trace back to customer-side misconfigurations, not AWS infrastructure failures.
How do I prepare for SOC 2 compliance on AWS?
Start by building on AWS's own SOC 2 certification. Many infrastructure controls are already covered because AWS maintains them. Focus your effort on: IAM policies and access reviews, encryption at rest and in transit, CloudTrail logging and retention, incident response procedures, and change management documentation. AWS Artifact provides AWS's compliance reports, and AWS Config can automate evidence collection for many controls.
What's the most common AWS security mistake?
Overly permissive IAM policies. Teams often use broad policies like AdministratorAccess or create custom policies with Resource: "*" because it's faster than figuring out the minimum required permissions. This violates least-privilege and creates unnecessary blast radius. IAM Access Analyzer can help identify policies that grant external access.
Do I need a WAF for my API Gateway?
It depends on your threat model. AWS WAF adds cost and complexity but provides protection against common web exploits, rate limiting, and geographic restrictions. For internal APIs or low-traffic applications, API Gateway's built-in throttling may be sufficient. For public-facing APIs handling sensitive data or high traffic, WAF is usually worth the investment.
How do I secure a multi-tenant SaaS application on AWS?
Multi-tenant security requires defense in depth: tenant isolation at the data layer (row-level security or separate tables/databases), IAM policies scoped to tenant context, API authorization that validates tenant access on every request, and logging that includes tenant identifiers for audit trails. For high-security requirements, consider account-per-tenant isolation using AWS Organizations.