Under the AWS shared responsibility model, AWS secures the infrastructure that runs its services. Customers secure everything they configure on top of it, including identity, storage access, encryption, and logging.
That customer side is where cloud risk tends to concentrate. The Cloud Security Alliance ranks misconfiguration and inadequate change control as the top threat to cloud computing, with identity and access management in second place.
Your team might know the shared responsibility model exists, but do they know which responsibilities are theirs, and which security gaps need their attention?
If your organization runs on multiple cloud environments, it’s imperative to ensure policies are consistent: Hybrid and Multi-Cloud Infrastructure Governance
Where AWS’s Job Ends and Yours Begins
AWS splits cloud security into two parts. Its Shared Responsibility Model describes the division as security “of” the cloud versus security “in” the cloud.
What AWS Covers
AWS secures the physical facilities, the hardware, and the virtualization layer that keeps one customer’s workloads separate from another’s. In practical terms, that includes:
- Physical security and access control at data centers
- Servers, storage devices and networking hardware
- The hypervisor that keeps one customer’s workloads separate from another’s
- The global network that links AWS Regions and Availability Zones
What Falls to You
The customer side covers anything configured inside the account. On AWS, that typically includes:
- Identity and access management, including users, roles, policies and credentials
- Storage permissions, such as bucket policies and snapshot sharing
- Encryption settings and key management
- Logging, monitoring and alerting
- Network controls like security groups and network ACLs
- Operating system patching on EC2 instances
Responsibility Moves with Services
AWS states that customer responsibility depends on the services a customer selects, which means the shared responsibility split looks different from one service to the next.
On EC2, for example, the customer patches the guest operating system and manages the software running on it. On Lambda, AWS handles the runtime, and the customer’s share narrows to the function code and the permissions attached to it.
Two areas remain a customer responsibility: identity and data. AWS provides the controls for both and leaves the decisions to the account owner.
How Cloud Security Gaps Open Up
Clear ownership of these settings is less common than it should be.
Over the past decade, much of the responsibility for provisioning infrastructure moved onto application teams. Engineers who write product code now create IAM roles and storage buckets as part of shipping features.
That shift speeds up delivery, but it also means security settings are decided in the middle of feature work, often under deadline pressure. For example, a permissive policy gets added to make a deployment pass, or a template is copied from an older project. Once the feature ships, nobody is assigned to come back and review the configuration.
Default Settings Only Help New Resources
Drift adds another layer; AWS improves its defaults over time, and those improvements apply to resources created after the change.
S3 is a clear example: AWS began automatically enabling S3 Block Public Access and disabling access control lists for all new buckets in April 2023. Existing buckets, however, saw no change.
What this means is, an account that has been running for several years carries configuration from every stage of its history. Some of it was set up before current best practice existed.
Gap #1: Identity Configuration
Identity is the most common way into a cloud environment. An attacker holding valid credentials can sign in and use every permission those credentials carry.
Long-Lived Access Keys
IAM user access keys are static. They stay valid until someone rotates or deletes them.
Datadog’s earlier State of Cloud Security reports found long-lived credentials to be the most common cause of publicly documented cloud security breaches. Its 2025 findings show how widespread they remain
- 59% of AWS IAM users have an active access key older than one year
- More than half of those users have credentials that have gone unused for over 90 days
- 39% of organizations still use IAM users in some capacity, and one in five relies on them exclusively
- Keys like these often leak through source code, container images and build artifacts
An unused key still carries every permission attached to it. Removing it costs the team nothing.
Overly Broad Permissions
Permissions tend to grow over time. AdministratorAccess gets attached during initial setup and stays, while roles pick up new permissions with each feature and rarely lose any.
AWS recommends granting least privilege and refining permissions based on how they’re used. A useful habit is to treat every new policy as a first draft, then narrow it once real usage is known.
Where to Start
- Move human access to IAM Identity Center: Engineers sign in through your identity provider and receive temporary credentials.
- Give workloads roles in place of keys: Assign IAM roles to EC2 instances, Lambda functions, EKS service accounts, and ECS tasks, so each workload receives temporary credentials automatically.
- Run IAM Access Analyzer: It surfaces unused access along with resources shared outside your account.
- Set guardrails at the organization level: On AWS, a service control policy can block the creation of IAM users across every account.
- Require MFA for all human access: Start with the root user, then keep root credentials out of daily use.
Access controls are a critical component of identity configuration: Zero Trust in Practice: Real Identity and Access Controls
Gap #2: Storage Permissions
S3 buckets have always been private by default. When data becomes publicly reachable, a setting somewhere in the account has allowed it.
Block Public Access at the Account Level
Block Public Access can be applied to individual buckets or across an entire account. The account-level setting covers every bucket, including ones created later, and overrides any policy or ACL that tries to grant public access.
Most applications need neither public buckets nor ACLs, and teams should be deliberate about creating any bucket that relies on them. Where public content is required (such as static website assets) serving it through CloudFront keeps the bucket itself private.
Over-Permissioned Bucket Policies
Bucket policies are often written quickly and not revisited. Common problems include:
- A “Principal”: “*” statement with no conditions limiting who can use it
- Cross-account access granted to account IDs nobody on the team recognizes
- Write or delete permissions where read access was all that was needed
- Legacy ACLs still active on older buckets
Exposure Beyond S3
Storage risk extends past buckets; EBS and RDS snapshots can be shared publicly with a single setting change, and so can Amazon Machine Images (AMIs).
A snapshot of a production database holds the same data as the database, but it doesn’t carry the network controls and access rules that protect the original.
Where to Start
- Turn on S3 Block Public Access at the account level in every account.
- Use IAM Access Analyzer to flag buckets shared publicly or with external accounts.
- Review sharing permissions on snapshots and AMIs, and enable the block public access settings available for both.
- Disable ACLs on older buckets and manage access through bucket policies.
Gap #3: Encryption Settings
Parts of encryption on AWS happen automatically. Others depend on choices the customer has to make, and those are easy to overlook when the automatic parts create a sense that encryption is handled.
What’s Automatic?
S3 automatically encrypts every new object upload using S3-managed keys, at no additional cost. That default encryption can no longer be removed from a bucket.
What Needs a Decision?
- EBS volumes: Encryption by default for EBS starts out disabled and must be switched on in each Region. Turning it on only affects new volumes, while existing ones stay as they are.
- Key choice: S3-managed keys protect data on disk, and anyone with read permission on an object can still read it. Customer managed keys in AWS KMS add a second layer of control, since the key policy decides who can decrypt.
- Encryption in transit: S3 can reject unencrypted connections through a bucket policy that denies requests where aws:SecureTransport is false. Database connections need similar enforcement through engine settings.
- Key policies and deletion: Losing access to a KMS key can make the data it protects unrecoverable. Key policies deserve the same review as IAM policies.
Building compliance into the heart of your cloud environment will go a long way in strengthening your overall security posture: Engineering Compliance in Cloud Infrastructure
Hardening is an Operating Rhythm
An AWS account changes every week. New services get adopted, roles get created and templates get reused. This means a configuration that passed review in spring can drift by summer.
Making hardening recurring work keeps that drift in check. A practical cadence might include:
- On every change: Scan infrastructure code and policies in the deployment pipeline, so misconfigured resources fail before they reach production.
- Continuously: Run AWS Config rules and Security Hub checks to catch drift between deployments.
- Quarterly: Review access and remove unused keys and roles.
- Annually: Assess the full environment against the CIS AWS Foundations Benchmark and rehearse an incident investigation using your own logs.
Who Owns the Rhythm?
This cadence works best with people whose primary job is the platform. It calls for depth in AWS security services and infrastructure as code, along with the time to apply it consistently.
Teams that are focused on shipping product features rarely have room on their roadmap for this work. It tends to slip each time a deadline moves.
Map Your Side of the Cloud Shared Responsibility Model
The shared responsibility model describes a boundary, but how well the customer side runs is left to each organization.
A written responsibility map is a simple place to start. For each AWS service in use, list the settings that fall to your team and the person accountable for them. Revisit the map whenever a new service enters the environment, because each one moves the boundary slightly.
SMS is a certified AWS Partner with a dedicated platform engineering team. Our engineers design, build, and secure AWS environments using infrastructure as code, so security settings are defined in code and reviewed with every change.
We can work alongside your engineers and take on the platform work that keeps an account secure over time. If something in your environment needs attention, we’ll tell you plainly and walk you through the options.
Talk to our team about your AWS security posture.
