AWS deleted my 10-year account and all data without warning

Single provider = single basket

  • Many argue the author clearly “put all their eggs in one basket”: multiple regions and services within AWS still share vendor, legal, billing, and account-risk.
  • Others stress the real issue isn’t backups per se but provider accountability: the story is about what happens when the cloud provider itself becomes the failure mode.

AWS architecture and control planes

  • One claim that “all AWS services share the same control plane” is strongly disputed by ex‑employees, who describe cell-based, isolated control planes per service.
  • Counterpoint: even with technical isolation, at the account and billing layer AWS is effectively one basket from a risk standpoint.

Backups, shared responsibility, and 3‑2‑1

  • Many commenters insist the author never had true backups: all copies lived inside AWS. Cross-region, multi-service setups don’t protect against account termination.
  • Classic 3‑2‑1 advice is repeated: multiple copies, multiple media/providers, at least one offline/off-cloud.
  • Several describe strategies: local Git or NAS as canonical, cloud as secondary; live mirroring or regular dumps to another provider/account; cold/offsite media.

Billing, account ownership, and region

  • Discussion over the “payer” vs “account owner” confusion: some think AWS treated the payer as owner; others doubt that aligns with how contracts usually work.
  • MENA region is called out as “operates differently” and higher-risk; some say they avoid being assigned there by using foreign billing addresses.

Trust in cloud & SaaS (AWS, GitHub, etc.)

  • Multiple anecdotes about lost GitHub accounts, Reddit bans, or payment glitches reinforce a wider distrust of centralized platforms.
  • Core theme: critical data and source code shouldn’t have a single institutional point of failure, whether that’s AWS, GitHub, Google, or a single corporate account.

Plausibility & internal-error theories

  • Some suspect an internal AWS tooling error (e.g., misused “dry-run” flag) and premature deletion; others find it hard to believe such a powerful script could run with so little oversight.
  • Several note AWS communications look like templated “this is your fault” responses, with zero empathy or clear postmortem.

AI-writing and credibility

  • A side thread debates whether the blog post is partially LLM-assisted (stylistic tells like heavy em-dash use), and whether that affects credibility.
  • Others push back: writing style isn’t evidence of fabrication, and non-native speakers often use LLMs for editing.

Suggested takeaways

  • Don’t rely on one provider or one account for backups.
  • Keep at least one off-cloud copy of irreplaceable data.
  • Avoid third parties controlling payment for critical infrastructure.
  • Treat any “verification” or account anomaly as a trigger to immediately export and safeguard data.