Frankfurt am Main - November 2024

How AWS needs to change

In previous posts, I took AWS to task for not making the customer’s security Job Zero. This offended some sensibilities, so let me lay out my 95 13 Thesis against the current AWS Culture and how it is neither Customer-Obsessed, nor makes security job zero.

How AWS needs to change.

  1. End the complete independence of the two-pizza team1. Yes, it makes AWS move faster, but the counter to that is that each team does its own thing. There are no enterprise standards to ensure a consistent customer experience. This is obvious with the complete chaos that is the IAM Action prefixing (Get, List Describe - pick two, three, or four).
  2. End the culture of secrecy. Most releases aren’t a competitive advantage. Deploy docs a week out and let customers respond to what’s coming. Dropping AssumeRoot on an unsuspecting world on a Thursday afternoon led to a lot of emergency Friday push-to-production changes. Nor is breaking your most dedicated customers:
    Tweet about Function URLs breaking due to a new feature
  3. Stop hiding behind Shared Responsibility.
    • The lack of IMDSv2 was key to the Capital One incident.
  4. Security services and IaC should be a promise.
    • Stop launching new regions without GuardDuty. Tweet about GuardDuty not being available in eu-north-1 at launch Tweet about GuardDuty finally being available in eu-north-1 95 days later
    • Stop launching new services without CloudFormation Support.
  5. Not all features are for all customers (like kms:ImportKeyMaterial).
    • Perhaps start with service quotas, or make the default SCP not Action:*
  6. Security should be job zero, and it should be free. Stop up-charging for key logs and telemetry. You’re not Micro$oft.
    • CloudTrail data events should be free
    • You need to offer a CSPM that does not cost a whole percentage point (or more) of the total AWS bill.
  7. Customers are desperate for consistency in IAM Actions. We need clear ways to build our security invariants.
    • Move all new networking actions to a vpc: namespace
    • Give us clear API actions that delineate between Data Access and Metadata Access
    • If ABAC is going to be your “best practice”, then all services - especially core services - must support it.
  8. Secure Defaults are critical.
    • The EC2 Launch Wizard must stop defaulting to 0.0.0.0/0
  9. Your customers don’t know how their cloud works. They need help.
    • Add new IAM Effects: Audit-Allow and Audit-Deny. Let us see what an SCP/RCP would do before we apply it in production. I shouldn’t need Splunk, Chronicle, or Defender to figure out I’m not going to blow up my company when I introduce a new SCP or RCP.
  10. Stop letting customers shoot themselves in the foot with Organizations
    • Don’t let them create an organization in an account where an ENI exists
    • Startup credits need to apply to an AWS Organization. You’re incentivizing poor security behavior when you offer credits that don’t work in an AWS Organization.
  11. Console warnings are fine, but IaC is the major problem.
    • anywhere there is a console warning, you need to add something to the API that’s a --yes-I-really-mean-to-do-this flag.
    • That needs to apply to CloudFormation, Terraform, Pulimi, CDK, etc.
      i-acknowledge-im-doing-something-dumb = true
  12. All IAM Actions are logged - no hidden usage of access keys.
  13. Maybe it’s time for new services not to be callable by IAM Users.

  1. This is wrong:

    We want to operate like the world’s largest startup. That means having a passion for constantly inventing for customers, strong urgency (for most big opportunities, it’s a race!), high ownership, fast decision-making, scrappiness and frugality

    ↩︎