Why Cloud Security Is Your Responsibility — Not Amazon's or Google's
Why Cloud Security Is Your Responsibility — Not Amazon's or Google's
TLDR: 89% of organisations experienced a cloud breach in 2023 according to the Venafi Cloud Security Report, and the majority cited misconfiguration as the root cause — not a provider failure. AWS, GCP, and Azure secure the infrastructure your workloads run on. Everything you build, configure, and deploy on top of it is yours to secure. This distinction has a name — the shared responsibility model — and misunderstanding it is one of the most expensive mistakes a startup can make.
The $74,000 AWS Bill
A founder called me after opening an AWS bill he couldn't believe. He'd been running his startup on AWS for two years, averaging around $800 a month. The latest bill was $74,000. In 48 hours.
What happened was straightforward: an AWS access key had been committed to a public GitHub repository three months earlier. An automated scanner — the kind that crawls public repositories specifically looking for credentials — found it within hours of the commit. The key sat unused for months while the attacker waited, or was sold to someone who eventually used it. Then, in a 48-hour window, hundreds of EC2 instances were spun up across multiple regions running cryptocurrency mining software.
AWS infrastructure worked perfectly. The instances launched as requested. The billing system recorded every hour accurately. Nothing was broken.
"Why didn't AWS stop this?" the founder asked.
Because from AWS's perspective, a valid API key made authenticated requests that were within the account's permissions. There was nothing to stop. The credential was legitimate. The behaviour was authorised — because the attacker had the credentials that said so.
This is the shared responsibility model, made viscerally clear.
The Shared Responsibility Model, Explained Plainly
Every major cloud provider publishes a shared responsibility model. AWS's version is at aws.amazon.com/compliance/shared-responsibility-model. The core concept is consistent across AWS, GCP, and Azure.
Think of it in two layers.
The provider's layer — "security of the cloud": the physical data centres, the hardware, the hypervisors, the network infrastructure, the managed service internals. AWS is responsible for ensuring the data centre in Ireland isn't physically breached, that the hardware your EC2 instance runs on is patched at the firmware level, that S3 as a service functions correctly. These things are genuinely AWS's problem. You have no visibility into them and no control over them — and you don't need either.
Your layer — "security in the cloud": your operating system configurations, your IAM roles and policies, your security group rules, your S3 bucket access settings, your application code, your encryption choices, your secrets management, your network architecture, your monitoring and alerting. These are entirely your responsibility, regardless of which cloud provider you're on.
The line is essentially: AWS is responsible for the building. You're responsible for everything inside your room.
The founder's EC2 instances were launched using valid credentials. AWS's building was fine. His room was wide open.
What Your Cloud Provider Is Actually Responsible For
Concretely: the physical security of facilities, the availability and durability of managed services (S3's 99.999999999% durability guarantee, for example), the security of the hypervisor layer, the patching of managed service infrastructure, and DDoS protection at the network level via services like AWS Shield Standard.
This is meaningful. You genuinely don't worry about someone physically walking out of an AWS data centre with your hard drives. The infrastructure layer is, by any reasonable standard, exceptionally well-secured.
But this security stops at the exact point where your configuration begins.
What You Are Actually Responsible For
Almost everything that determines whether your data is secure:
Identity and Access Management — every IAM user, role, and policy you create; every permission you grant; every access key you issue.
Network configuration — every security group rule, every VPC configuration, every decision about what is and isn't publicly accessible.
Data encryption — whether data at rest is encrypted, which keys manage that encryption, whether data in transit uses TLS.
Operating system and application security — patching EC2 instances, securing containers, hardening application configurations, managing secrets within your environment.
Monitoring and alerting — CloudTrail logs, GuardDuty configuration, billing alerts, anomaly detection. AWS generates this data. You decide whether to look at it.
Access key lifecycle — creating, rotating, and revoking credentials.
Every one of these is in your control. Every one of them was in the founder's control when his $74,000 bill arrived.
The 5 Most Common Gaps Where Startups Fail
1. Overpermissioned IAM roles and users. A developer creates an IAM user for a service and gives it AdministratorAccess because it's convenient and they'll "narrow it down later." Later never comes. That service account now has the permissions to spin up unlimited EC2 instances, read any S3 bucket, and modify any configuration in the account. Least privilege isn't optional — it's the foundational principle of cloud IAM.
2. Public S3 buckets. The default S3 configuration has changed over the years and AWS now blocks public access at the account level by default — but buckets created before these defaults were introduced, or where the block was explicitly disabled, remain publicly accessible. In 2024, publicly exposed S3 buckets were still a top-five finding in cloud security assessments.
3. Access keys in code repositories. Exactly what happened above. Automated scanners crawl GitHub continuously. A key committed for even a few hours is a key that has likely been harvested. Rotate immediately if this has happened in your history.
4. No billing alerts. AWS doesn't prevent you from spending $74,000 in 48 hours. It bills you for it. A billing alert set at $1,500 — twice your normal monthly spend — would have fired within hours of the attack beginning. This is a two-minute configuration in the AWS Billing console and it should be set on every account, today.
5. No CloudTrail analysis or GuardDuty. AWS CloudTrail logs every API call made in your account. AWS GuardDuty uses machine learning to detect anomalous behaviour — unusual API calls from unfamiliar IP ranges, credential use from impossible geographic locations, crypto mining patterns. Both services exist. Most startups have them turned off or have never looked at the output.
How to Assess Your Own Cloud Posture in 30 Minutes
This isn't a comprehensive audit — it's a first-pass that surfaces the most critical gaps.
Check for public S3 buckets. In the AWS console, navigate to S3 → Block Public Access settings. Confirm "Block all public access" is enabled at the account level. Then review individual bucket permissions for any exceptions.
Review IAM users and access keys. In IAM → Users, look for any user with AdministratorAccess, any access key older than 90 days, and any inactive user who still has permissions. The IAM credential report (IAM → Credential Report) gives you a full list of all users and key ages.
Enable billing alerts. In AWS Billing → Budgets, create a budget alert at 2x your normal monthly spend. Add your email. Takes three minutes.
Verify GuardDuty is enabled. GuardDuty → Getting Started. If it's not enabled, enable it. The 30-day free trial covers initial setup; the ongoing cost for a startup workload is typically a few dollars per month.
Search your code repositories for credentials. Run git log -p | grep -i "aws_access_key\|aws_secret\|AKIA" against your repositories. If anything surfaces, rotate those keys immediately.
How Kuboid Secure Layer Can Help
A cloud security review examines your IAM configuration, network architecture, S3 and storage permissions, encryption posture, logging and alerting setup, and secrets management practices — against the AWS Well-Architected Framework's security pillar and real-world attacker techniques.
The output is a prioritised list of what's misconfigured, what's overexposed, and what needs to change — with the specific configuration changes required, not general recommendations.
If you'd like a professional review of your cloud security posture, get in touch to start with a scoping conversation. You can also explore our services or learn more about how we work.
More security guides for founders and technical teams on the Kuboid Secure Layer blog.
