AWS accused of a ‘digital execution’ after it deleted 10 years of users' data without warning — software engineer details “complete digital annihilation” at the hands of AWS admins, claims false excuses given for account deletion
www.tomshardware.com
And the cloud giant is accused of a 'cover up' with the verification requested only after someone had accidentally wiped all the user's data.

A software engineer has warned against trusting cloud data storage services in a painstakingly detailed blog post detailing their own “complete digital annihilation” at the hands of AWS admins. Developer Abdelkader Boudih, pen name Seuros, says they had been a fee-paying AWS subscriber for a decade, with the cloud service becoming a firm part of their workflow. Suffice to say, the developer’s long-standing relationship with AWS has now ended acrimoniously.

  • tyler@programming.dev
    11·
    30 days ago

    AWS very likely can recover all of their data, they probably just don’t want to. We had a devops person at our company run a script that wiped out 95% of our Lambdas, ‘irreversibly’ according to AWS docs. AWS spent 2 weeks with our devops team to recover as many of the lambdas as possible. Most of the recovered lambdas were just sent over to us as randomly identified zips, but we did get the majority of them back.

    • shiftymccool@programming.dev
      9·
      30 days ago

      I have to know, how do you lose lambdas? You should still have the source code. Please tell me you didn’t code them directly in the aws console…

      • tyler@programming.dev
        2·
        28 days ago

        I meant to respond to this yesterday. We didn’t lose the lambda code, we lost lambda versions, which are immutable versions of your Lambda. There is no way to restore these (hence immutable).

        We had every lambda version’s code tagged in github as a release and while we could have redeployed them it would have taken just as long if not longer, due to how long our deployments for the lambdas in question were (20minutes to 1.5h depending on the lambda).

        There were a lot of suboptimal things that happened to make it a shitshow, but essentially:

        • we should have been using function Aliases from the beginning, our versions were referenced directly, so redeploying would have resulted in needing massive db changes downstream to result in referencing the right lambda versions.
        • AWS should have specified that what we were doing was not what they intended (they’ve updated the docs now, but at the time their docs literally just said if you want immutable functions you can use function versions!).
        • we should have saved off the function.zips before deploying (we didn’t think that was necessary because we had all the code and the artifact was the least important part of our deploy)
        • we should have had our own AWS account rather than using the company’s ‘shared’ account which was how everything was done at the time.

        This all resulted in a dumb devops dude getting a ticket to clean up our dev account due to running out of lambda storage space. He cleaned up the dev account with a script that was built to only be run against dev. Then he decided even though the ticket said just clean up dev, he would take a look at prod and clean that one up too.

        Thus managing to take down the entire company’s sales infrastructure.

        The shared aws account and the devops script to clean up lambdas was built before I started at that company, but the rest of the code/architecture was mine and one other person’s design. It worked really really well for what it was built for (immutable rules for specific points in time), but there were a lot of shortcomings and things we missed that resulted in everything going badly that month.