That S3 bucket from 2019 might still be wide open
AWS environments never sit still. Applications launch, teams add services, permissions get granted “just for this one thing,” and infrastructure grows faster than anyone can keep a mental map of it. A configuration that made perfect sense at initial deployment can quietly leave resources exposed, or handing out more access than anyone intended, months or years later.
We go through your AWS environment, IAM, storage, networking, logging, encryption, and everything in between, to find where that’s actually happened, without getting in the way of the business running on top of it.
What this actually is
An AWS Cloud Configuration Review is us looking closely at how your AWS environment is genuinely configured, not how the architecture diagram says it should be. That can cover Identity and Access Management, S3 storage, EC2 instances, VPC setup, Security Groups, Network ACLs, RDS databases, CloudTrail, CloudWatch, KMS and encryption, secrets management, Lambda, load balancers, Route 53, backups, logging, and account-level settings.
The point is finding configurations that raise your risk, and giving you something practical to do about each one.
Why this matters more than a lot of teams realize
Most cloud security incidents don’t come from some exotic zero-day. They come from a setting nobody double-checked. A review helps you find publicly accessible resources, excessive IAM permissions, weak account settings, insecure storage, missing logging, weak network controls, unencrypted sensitive data, exposed management interfaces, unnecessarily open security groups, poorly configured databases, weak secrets management, and backup controls nobody’s actually tested.
Regular reviews matter because configuration drifts on its own. Nobody decides one day to leave a bucket public, it just happens gradually, through a dozen small, individually reasonable-looking changes.
What we actually go through
IAM. Who can access what, and what they can actually do once they’re in. We look at users, groups, roles, policies, privileged accounts, cross-account access, access keys, unused credentials, and permissions that have grown wider than anyone intended. The goal is genuine least-privilege, not just least-privilege on paper.
S3. Since S3 tends to hold a lot of business and application data, we look hard at public access settings, bucket policies, access controls, encryption, logging, versioning, object-level access, and cross-account access, hunting for anywhere sensitive information is more reachable than it should be.
EC2. Instance exposure, Security Groups, network configuration, IAM roles attached to instances, storage encryption, management access, public IP assignments, and instance metadata configuration, all checked for how they connect to the wider environment.
VPC and networking. VPC configurations, subnets, route tables, Security Groups, Network ACLs, Internet Gateways, NAT Gateways, VPC endpoints, peering connections, and Transit Gateway setups. We’re looking for exposure and network access that’s broader than it needs to be.
Security Groups. These act as your virtual firewalls, so we check for unrestricted inbound or outbound access, open management ports, overly broad source ranges, duplicate or outdated rules, and access that’s just wider than the actual application requires.
RDS and databases. Public accessibility, network access, encryption, authentication, backup settings, Security Groups, logging, and snapshot or cross-account access, since databases tend to hold exactly the kind of information you don’t want casually reachable.
CloudTrail and logging. If something goes wrong, would you actually be able to see it happen? We check CloudTrail configuration, management and data events, log storage and protection, monitoring integrations, alerting, and retention settings.
Encryption and key management. Data at rest, data in transit, KMS keys, key policies, rotation settings, and who actually has access to your encryption keys.
Secrets management. Credentials, tokens, API keys, all the sensitive values your applications need to function. We check how they’re stored and accessed, and where they might be exposed more than necessary.
Lambda. For serverless environments, we check IAM execution roles, environment variables, resource policies, network configuration, function permissions, logging, and trigger setup, looking for excessive permissions that snuck in during development and never got trimmed back.
How we actually run this
Scope and planning. We define which AWS accounts, regions, services, and environments are actually part of the review.
Discovery. We build an understanding of your cloud architecture: resources, accounts, identities, network components.
Configuration collection. We gather the relevant configuration data to understand how security controls are actually implemented today.
Security control assessment. We go through IAM, networking, storage, encryption, logging, databases, compute, and serverless services.
Risk analysis. We weigh exposure, permissions, affected resources, data sensitivity, and business impact.
Validation. We confirm findings are actually meaningful, to keep false positives out of your report.
Reporting and remediation. A clear document on what we found, which resources are affected, the risk, and how to fix it.
Retesting. Once you’ve made changes, we can check back to confirm they held.
What tends to turn up
Publicly accessible S3 buckets. Excessive IAM permissions. Unused access keys nobody’s rotated or removed. Weak IAM policies. Missing MFA on privileged accounts. Overly permissive Security Groups. Publicly accessible databases. Unnecessary public IP addresses. Weak network segmentation. Missing CloudTrail logging. Poor log protection. Weak encryption configuration. Insecure KMS policies. Exposed secrets. Excessive Lambda permissions. Unrestricted cross-account access. Weak backup configuration. Resources nobody’s using anymore. General configuration drift.
Configuration review vs. AWS penetration testing
Different jobs. A configuration review finds weaknesses in your settings, permissions, policies, networking, storage, and logging. Penetration testing goes further, actually simulating an attack to validate whether those weaknesses can genuinely be exploited within an approved scope.
A configuration review can catch gaps a penetration test might never touch directly. A penetration test can prove real-world exploitability a configuration review can only theorize about. Together, they cover more ground than either alone.
Configuration review vs. Cloud Security Posture Review
A Cloud Security Posture Review tends to be broader, covering multiple cloud platforms and wider governance concerns. This review is specifically about AWS, digging into AWS-specific services, permissions, and policies at a deeper, service-level detail. If you’re running AWS specifically, this gives you a more granular look than a broader multi-cloud review would.
Who this is for
SaaS companies. E-commerce businesses. Financial and healthcare organisations. Technology companies. Startups. Enterprise businesses. Government-related organisations. Managed service providers. Anyone running customer-facing applications on AWS.
It matters most for organisations with multiple AWS accounts, multiple teams touching infrastructure, or cloud environments that are just changing faster than anyone can manually track.
When to do this
Before launching a major cloud application. After migrating workloads to AWS. After major architecture changes. Following an account restructuring. After introducing new cloud services. After a security incident. During regular reviews. Before compliance assessments. After significant IAM changes. When moving from development to production. Whenever configuration drift seems likely, which, honestly, is most of the time in an actively growing environment.
How to actually tighten AWS security
Apply least-privilege IAM permissions, genuinely, not just in theory. Enable MFA on privileged accounts. Remove unused credentials instead of leaving them lying around. Restrict public access wherever it isn’t intentional. Review Security Groups regularly. Encrypt sensitive information and protect the keys that unlock it. Enable proper logging. Monitor privileged activity. Manage secrets securely. Apply network segmentation. Maintain backups you’ve actually tested. Review cross-account access periodically. Keep an eye on configuration changes as they happen, not months later.
Security in AWS is genuinely ongoing work, because the environment itself never stops changing.
Why work with us
We assess AWS services based on how you’re actually using them, not just what the documentation says they’re capable of. That means real identity and access review, IAM permissions, roles, policies, privileged access, all checked for unnecessary exposure. Storage, networking, databases, compute, logging, and encryption all get covered. Findings come with practical recommendations, ranked by real risk, exposure, and business impact. Once you’ve made fixes, we can review again to confirm they actually held.
Bottom line
AWS gives you the flexibility to build and scale fast, but that same flexibility means environments get complicated quickly. New accounts, new users, new services, new permissions, all of it can introduce configuration gaps nobody notices until someone’s specifically looking. A structured review across IAM, storage, networking, databases, encryption, and logging helps you find those gaps and build a genuinely stronger cloud security foundation.
FAQs
What is an AWS Cloud Configuration Review?
A security assessment of your AWS environment, covering configurations, permissions, policies, networking, storage, logging, encryption, and other cloud controls.
What AWS services can be reviewed?
Depending on scope: IAM, S3, EC2, VPC, Security Groups, RDS, CloudTrail, CloudWatch, KMS, Lambda, Route 53, load balancers, and other AWS services.
Can it find public cloud resources?
Yes. We can identify resources that are publicly accessible or have broader access than they should, depending on what’s included in the review.
Is this the same as penetration testing?
No. This focuses on security settings and controls. Penetration testing focuses on actually exploiting things within an approved scope.
How often should AWS be reviewed?
Regularly, and definitely whenever major changes happen to accounts, IAM permissions, applications, networking, or architecture.
Can you review multiple AWS accounts?
Yes, when they’re included in the agreed scope.
Does this cover IAM?
Yes, and it’s a big part of it, users, groups, roles, policies, permissions, access keys, and privileged access all get checked.
Can this help with compliance?
It can help identify gaps relevant to certain compliance requirements, though exact coverage depends on the framework and scope you’re working toward.
What’s in the report?
Affected AWS resources, identified weaknesses, evidence, risk context, remediation recommendations, and retesting results where applicable.
Secure your AWS environment with a Configuration Review
Talk to Sunvak Boreal about your AWS setup. Let’s find out what’s quietly still open from three deployments ago.