People often ask me what my favorite AWS service is (generally S3, EFS, Systems Manager, or IAM depending upon the day or my mood), but I virtually never get asked about the inverse: what’s the AWS service I despise most of all?
Maybe people are scared of the answer. Maybe they think that it’s going to cause me to come into conflict with their view of the world. Alternately, perhaps people think they can guess the answer. Maybe it’s the Managed NAT Gateway? Nope. I dislike its pricing intensely but it’s an incredibly useful service from a functionality perspective. I sure gave MemoryDB a very hard time when it launched — but no, that was simply a weak launch to general availability that came too soon for a service that’s rapidly improving past its Day One experience. My impression has improved markedly. The service I detest has no planned feature release that will change my opinion, no pricing change that makes it suddenly something I wholeheartedly endorse.
You can pick any service from AWS’s service list — any service at all, and you’d be wrong, because the service I like the least doesn’t appear on any of them. In fact, most people have never heard of it.
It’s called “Isengard.”
What on Middle Earth am I talking about?
Isengard has been named and described semi-frequently by Amazonians in open forums, but rarely in easily citable forms. Chalk talks at re:Invent, informal conversations with Amazonians, and periodic GitHub commits or issues from current or former Amazonians name it, but always in ways that imply it’s an NDA breach, or something that’s not to be spoken about too loudly for whatever reason. That’s okay; I’m not here to tell anyone’s secrets. Instead, to describe it I’m going to cite an article in Protocol that harangues Amazon’s attempts to crack the gaming market:
For example, internal AWS accounts are known as Isengard accounts, after the fortress in “The Lord of the Rings” eventually controlled by the corrupted wizard Saruman. When internal game development teams use Isengard accounts, they must pay (via internal accounting) the same rates for AWS compute cycles that outside retail customers pay, according to people close to the teams.
Completely ignoring at least one significant factual error in that citation, “Isengard” is effectively how AWS accounts are provisioned and managed internally. (Well, one way. There’s at least one other system that is out of scope for the point I’m making.)
Wait, why do I hate an internal AWS service?
You might expect me to launch into a blistering critique about what’s wrong with the service from a functional perspective. Not so! By most accounts it’s a fine service that handles things super well for AWS’s needs. It even (in a radical departure for an Amazon service) has an awesome name! My problem is explicitly and entirely that it’s an AWS internal service.
This may be news to some of you, but I do not work at AWS, nor have I ever. As such, I’ve never used Isengard, nor read its documentation. I have no idea where it starts or stops, how wonderful or horrible its user experience is, or any of the normal things I use to determine where I stand on a given service. Based upon rumor, I’m inclined to think that it’s rather excellent.
The fact that it’s the internal service used to provision AWS accounts means that AWS engineers building AWS are insulated from the way that the rest of the world manages AWS accounts–or should I say, ways. They don’t have to deal in the same way with AWS Organizations or Landing Zones or Control Tower or AWS SSO (an absolute hidden gem of a service, by the way). And that’s the crux of my beef with the service.
Managing multiple AWS accounts is simultaneously obnoxious and necessary. They are hard boundaries for access, budgetary responsibility, organizational boundaries, service limits, and many more things. AWS Control Tower is improving but it’s still painful, as well as not generally recommended for enterprises at large scale. AWS Organizations requires a lot of fiddly work to do governance well. What’s worse is that AWS accounts are one-way doors that you don’t realize you’re walking through at the time you set out down that path. I consider myself pretty well informed about AWS best practices and architectures, and I still have a “legacy” AWS account in my organization that was created in late 2016. Migrating resources out of an AWS account is super hard!
It’s very clear that AWS has internal tooling optimized for the things Isengard cares about. The problem is that AWS isn’t the only company by far that has to care about those things.
These aren’t problems unique to AWS as a company.
Every company with an even moderately sophisticated AWS account structure has to worry about the same challenges that Isengard almost certainly addresses.
Every company has to provision new accounts and then deprovision them after an experiment or project ends. Every company has to build a security model that every new account has to conform to. Every company has to make a service in one AWS account work well with a second, third, or fortieth AWS account. Every company has to manage the resulting sprawl from these and many more requirements, and do so effectively.
It’s clear that AWS has not only solved that problem via some internal tooling, but has implemented it in such a way that the AWS engineers building services internally have almost all of this complexity abstracted away from them in a way that serves as a significant departure from the customer experience.
And that is why I hate Isengard. I want to either see Isengard released as the AWS service customers can and should use to manage their AWS estates, or else see it shut down and force the various AWS service teams to gargle their own champagne by using the same account management tooling that the rest of the world has to deal with.
