If your company runs on AWS, most security incidents are preventable. In this guide you’ll harden your AWS Organization in three practical steps: (1) enforce guardrails with Service Control Policies, (2) design private-by-default networking, and (3) turn on the AWS security services that catch what slips through. The goal: reduce attack surface, stop common misconfigurations, and keep delivery moving—without months of security reviews.
By All Accounts of Murphy’s Law, It Was Impossible
Not long ago, a fast-growing SaaS startup found out the hard way what a few exposed credentials can do. In early 2025, hackers quietly slipped into Salesloft’s GitHub account, staying hidden for months. From there, they uncovered secrets like AWS access keys and pivoted into Drift’s AWS environment. With those tokens in hand, attackers gained access to sensitive integrations and even customer data. The breach wasn’t caused by a new zero-day — it happened because secrets were poorly protected, and AWS resources became the gateway.
Around the same time, on the other side of the world, Angel One, one of India’s largest stock brokers, disclosed that parts of its AWS infrastructure had been compromised. The company scrambled to rotate credentials and lock down affected services, but not before attackers had a window into critical financial systems.
These aren’t theoretical cautionary tales. They’re fresh examples of how attackers are exploiting the weakest links in cloud adoption, turning AWS environments into high-value targets.
Time to Take Action
As you probably know, enterprises today are facing security challenges like never before. A huge part of the problem emerges from integrating cloud providers such as AWS into their infrastructure. Even when organizations recognize the need for secure environments, the design and review process can slow deployments by weeks or even months.
The transition to cloud platforms introduces new threat vectors, misconfiguration risks, and compliance hurdles. But these risks aren’t inevitable — many breaches can be prevented in advance, if you build strong security standards into your environment before you go live.
Before You Start: Ask These AWS Questions
Modern problems require modern solutions. Although AWS generated a new spectrum of vulnerabilities, it also provides tools to face them. Accordingly, when we are about to face a new risk in the AWS environment, we first need to ask ourselves: Can we mitigate this risk with other AWS services? What parts of our infrastructure should we secure, and what AWS secures natively? Is the resource we want to defend managed by AWS? When we answer these questions, we often get a pretty simple solution to prevent most of the attacks on our AWS console.
Ask these first:
- Can this risk be mitigated by a native AWS service?
- Which parts should we secure ourselves vs. inherit from AWS? What is our responsibility vs. what is AWS responsible for.
- What are the cost differences between the solutions?
- Is the resource fully managed by AWS (and covered by its SLAs/controls)? Is it centralized for our entire environment?
While improving my skills by exploring the AWS console, I figured out three key concepts that every organization should implement in its environment. Let’s strengthen our security using these concepts!
Step 1: Enforce Guardrails with Service Control Policies (SCPs)
SCPs (Service Control Policies) are actually a kind of restricting policies mostly used by high privileged users to restrict users in AWS Organization for specific actions and services in the cloud. While Permission Sets grant the users access to services in AWS, SCPs can only be used to deny access to these services. Meaning that if I want my users to stop attaching Security Groups to instances, stop creating networking public resources, or even restrict them from making an S3 bucket public, I can use SCP and achieve it in seconds. SCPs can also be attached to unique organizational units (OUs) in our organization. For example, if we have an OU for production accounts and we want to prevent our users from deleting S3 buckets, we can attach an SCP policy at the production OU to achieve that purpose.
SCPs don’t grant permissions—they only set org-level allow/deny guardrails that apply to all IAM users and roles in member accounts (including the root user of those accounts).
In the end, SCPs are really one of the easiest ways to enforce organizational restrictions within our company with almost no effort at all.
If you don’t know how to start, here are a few best practice recommendations:
- Use SCP to prevent creation of public resources.
- Ensure proper AMIs are picked during instance creation.
- Prevent access to IAM in low-privileged users groups.
- Limit access to Security Groups rules in EC2.
Step 2: Design Private-by-Default Networking
The next point we are going to discuss is a little bit more complex. It is not just about adding security controls to our architecture, but also about designing the network infrastructure correctly and achieving better infrastructure security accordingly.
When an attacker tries to hack into our company servers, the less public access we have the better. In other words, the better approach is to keep our infrastructure as private as possible. If we need two of our services in two different VPCs to communicate with each other, then instead of letting them communicate using the public network we better create a VPC peering connection between them. Private connectivity (VPC peering/Transit Gateway/PrivateLink) removes public exposure and prevents trivial interception and spoofing attempts over the internet. I’m not going to show all the ways of making private network communication within your infrastructure, but here some key services you definitely should remember: for VPC communication you can use VPC peering, VPC Lattice or Transit Gateway, for accessing AWS services privately you can use PrivateLink endpoints and instead of connecting to your instances using SSH over the public network you can connect privately using SSM Session Manager.
Moreover, we can save a lot of money when keeping our network traffic private as communication with the public network charges a lot more money. Yes guys, while traffic moving through the internet costs you a lot of money, private communication can be free of charges (If you are staying within the same AZ), so this is another huge benefit of keeping your network private.
The main issues with it are being able to plan all your architecture in advance, and the migration itself (like enabling VPC endpoints and modifying configuration of existing resources). Yet the result will absolutely be better than your old internet facing architecture.
Step 3: Turn On the Built-In AWS Security Services
Most of the time, when we need to implement security in our environment, we start to get nervous and don’t know where to start or how to achieve it. However, these days, AWS has already built most of the security tools that we need, and they fit into our environments perfectly.
AWS offers many security features to help us secure our accounts in various aspects of security:
- Amazon Macie – discover and protect PII in S3. (Can be very expensive yet it is AWS native so probably won’t take much effort)
- Amazon GuardDuty – intelligent threat detection across accounts, data, and workloads. Guard Duty can scan logs from various sources in your accounts or organization and identify a wide range of security risks that might otherwise go unnoticed like malware detection and instance compromise.
- AWS Firewall Manager – centrally apply WAF/network firewall/Shield Advanced policies across accounts.
- Amazon Inspector – is an automated vulnerability management service that continuously scans your AWS workloads for known software vulnerabilities and unintended network exposure. It checks resources in many services like EC2, ECR, and Lambda functions to create a list of findings, prioritized by severity, so you know exactly what to patch.
- AWS Security Hub – Collects, organizes, and prioritizes security alerts or findings from all other security services we discussed into a single, unified dashboard. It runs automated security checks and gives you a comprehensive view of your security and compliance posture.
These are only a few of the services already available today in AWS that provide the highest level of security for your organization using almost no effort at all. So when you need a security solution that fits your company, think first that you are probably not the first one to need this and maybe it is already developed on AWS.
Conclusion & Next Steps
In summary, navigating the complexities of cloud security doesn’t require reinventing the wheel; it demands a strategic and proactive mindset. Security is that one thing we must not do levity and sometimes employees avoid this or try to develop new tools as they lack knowledge about AWS provided features. These steps are not just isolated fixes, but layers of a defense that hardens your environment from the ground up. In the end, securing your AWS Organization is an achievable goal that protects your enterprise from all kinds of hackers, allowing you to keep operating with confidence.
