At AWS re:Invent last November, I was invited to a marketing panel in which AWS sought customer feedback. I’ll never forget the developer on the panel who kept proclaiming his “love” of AWS — the answer to every question he was asked was, essentially, that AWS is the best technology ever invented. I think even the AWSers were embarrassed for him.
I don’t go that far. But I’m really close. And something that AWS did recently might make me a bigger fanboy than that developer.
In my current gig, we are primarily running Windows Server. The main thing that makes Windows Server run in EC2 is a service that AWS installs in the AMIs of Windows Server called EC2ConfigService. When you start a Windows Server instance in EC2, it comes along with the operating system.
And you really need it. It does all kinds of housekeeping tasks. It manages Windows activation; it can set your hostname; it provides http access to current EC2 metadata about your instance and it helps you run the sysprep utility to clone an instance.
EC2ConfigService was the kind of thing you never needed to worry about — until recently. AWS added a bunch of new capabilities to it — and it bloated all out of proportion. Click on the before and after screen images to see what happened to virtual memory in the service.
I sent these two images to AWS Support and their response was a happy surprise. From the first, the support guy took the issue seriously. This is in marked contrast from almost every other tech vendor whose support people presume you did it — or, more likely, you’re too stupid to know you did it.
A couple of days later, the answer came back from the product guys that I expected: “Virtual memory doesn’t matter.” Well, that’s not true, of course, even to people who didn’t start their computer careers on antique 64K machines using real core memory. In fact, I would argue for a bunch of technical reasons that virtual memory is even more crucial in a virtual machine, or hypervisior environment, especially one that is generalized. (AWS runs a much-customized version of Xen; not Hyper-V. The latter could be expected to be more tolerant of memory mismanagement in Windows than the former.) If you’d like to know more about this, just let me know. (Sing to the tune of Yellow Submarine: “We all live in a virtual machine…”)
So, I pushed back, more or less gently, and to my great surprise and pleasure, I got a detailed email with a workaround. I’d post that workaround here. But you won’t need it. If you look at the release notes for EC2ConfigService 3.3.174, you’ll see AWS fixed it in an update released at the same time I got the fix.
Bravo, AWS. And thanks! Cringeworthy love or not, that developer in Las Vegas had it right.
Leave a Reply