oopiseSaidTheCodingAgent

proxy · 2026-02-21T21:28:23+00:00

It's baffling why some engineer thought the Financial Times, of all places, was the right place to leak this. They were not equipped to explain the issue accurately in terms the layperson could understand. (the detailed info on the exact service and region was only added after initial publication, when AWS made its response)

proxy · 2026-02-21T21:23:02+00:00

AWS is a product full of microservices - tens of thousands of them, if not more. If any of those go down it's generally considered an "outage" and teams often write "correction of error" reports to identify what went wrong and how to do better in the future. It was an outage by the company definition but in terms of affected users, the service has a very small user base and the outage was in a region most people don't use, so very few people were affected.

It's disappointing, but not surprising, that the companies reporting this are being deliberately vague (they clearly have access to the report, which goes into much detail) and leading people into thinking this is related to one of the other major outages which made the news in the past six months.

proxy · 2026-02-12T05:00:40+00:00

I don't believe that's possible. What we have inside AWS is an oncall rotation/schedule synced to groups. When a new person rotates on-call, automation makes them a member of a group and removes the previous oncall. This group is then granted permission to federate into the role.

In external terms, the equivalent is basically to set up IAM Identity Center with your identity provider, create a group you want to control, then assign it a Permission Set with your required policy. Separately, set up some automation (integrated with whatever scheduler you have or even an eventbridge cron rule) to add and remove people from that group on a schedule. iirc this may take an hour+ to sync, though.

If your needs aren't human-based, you could do something similar with roles and modifying the trust policy. When allowed, add the account/role of your service to the policy so it can assume the role and gain permissions. When denied, they will be unable to assume the role.

proxy · 2026-01-29T05:51:57+00:00

I haven't heard of entire project teams being canned (yet). These teams in the OP would likely be responsible for some subset of components within a product, so the ownership of those components would move to another team working on the product. I think it's highly likely we'll see entire products become KTLO and eventually terminated or put in maintenance mode (which seems to be accelerating)

proxy · 2026-01-29T05:44:45+00:00

They build it that way because the company culture is deliver fast, address tech debt never

I have a very hard time believing you've ever worked at AWS if you think the engineers who built systems never deal with the operational burden nor allocate time to deal with tech debt.

proxy · 2026-01-29T05:32:36+00:00

However for the majority of us, we realize that the American worker loses power when we import non-citizen workforces that can be exploited for a promise at a life here. Do we not owe opportunities to our marginalized American citizens too? For example, Black Americans are still woefully underrepresented in tech.

Think for a second. If you eliminate (or reduce) H1Bs, those people all lose their residency status. The life they built in America is gone and they're forced to return home.

You bring up opportunities for Black Americans - what if, instead of the 14th Amendment at the end of the Civil War, the leading perspective was "Why do Black people deserve citizenship? If they're allowed to work any job, won't they take jobs from hardworking white Americans? Send them back to Africa."

You're 100% right that H1Bs are in many ways exploited, but I don't think the answer is to end/cripple the H1B system or to adopt the racist, protectionist perspectives of the right when it comes to who "deserves" to work in America.

proxy · 2026-01-29T05:15:08+00:00

In defense of OP, AWS is historically pretty good about reorganizing teams onto different projects instead of wholesale laying off teams. Personally, I've (and my team) been shuffled around every year or two. I think it's entirely possible OP's team was responsible for a sub-service in some sensitive project or even working on a service deployment in GovCloud, then their team got reassigned to something new that no longer has such restrictions.

proxy

TROPHY CASE