Object Lock in the PDNS rebuild has to be checked before the bucket exists

Object Lock lives in the Create bucket dialog, under Advanced settings, behind a confirmation prompt ^[11]. The flag can be set while the bucket is being created, and not afterwards ^[10]. Default retention is configured separately, on the Properties tab of the finished bucket, where the article selects Compliance Mode ^[12].

According to the article, no user can delete or overwrite an object until the retention period expires, and that includes the root account and AWS Support ^[13]. The default retention it sets is 30 days ^[13]. The same steps add a lifecycle rule that transitions objects to Glacier ^[14]. With deletion blocked for a month, the only remaining way to cut the cost is the storage class ^[4].

The design then adds a second, independent lock. AWS Backup Vault Lock can still be modified or deleted during a 72-hour grace period, and the article says that after three days it is permanent and cannot be deleted or bypassed by anyone, including AWS ^[16]. Both locks sit in ap-southeast-3, Jakarta ^[15].

The incident behind all of this is reported in one place: a dev.to write-up that rebuilds the scenario as a reference architecture with code and runbooks ^[9]. It describes more than 230 government services out of action, airports on manual processes, weeks of recovery, and a demand for USD 8,000,000 ^[2][3][6][4]. Under 2 percent of the data had a backup ^[5][1]. The post's own line is "The most sophisticated ransomware in the world is powerless against a well-tested backup" ^[8], and it attributes the damage to the absence of backups instead of to the malware ^[7].

Detection is bolted on after the storage work. In Security Hub the article accepts findings from the GuardDuty integration and builds a custom insight for ransomware ^[18]. The CloudTrail trail logs management events, read and write, plus data events for all current and future S3 buckets and every Lambda function ^[17]. That scope covers buckets nobody has created yet ^[17].

Recovery runs in a different region. Elastic Disaster Recovery is initialised in ap-southeast-1, Singapore, with a dedicated VPC on 10.10.0.0/16, a public subnet in ap-southeast-1b, and an internet gateway ^[19][20]. Point-in-time recovery keeps 7 days of snapshots ^[22]. The agent goes onto the production server through Systems Manager Session Manager, so the plan assumes you can still install software on the machine you are trying to protect ^[23].

This transfers only if you can accept storage you are forbidden to delete for 30 days at a time ^[13]. It also requires that you are allowed to replicate block-level data out of your primary country to Singapore over TCP 1500 ^[21].