On a longer planning horizon than many companies seem to operate, it would appear that the approach that most of the existing cloud providers are taking today is suboptimal. Their messaging, their product offerings, their enhancements around existing services, and their hiring all swirls around a central theme: migrating enterprise workloads into cloud.
I’ve been an advocate for AWS SSO for a while, but the official tooling used to log in and work with various accounts within your organization has been somewhat lacking, to put it mildly. That’s why I was so pleased to stumble across granted recently.
Usually when I talk about AWS regions and availability zones, it ties back to [data transfer pricing] or some other model of cloud economics. Today I want to take a different angle: it’s my belief that how I think about AWS regions and how AWS talks about them are somewhat far apart. The reason I’m doing this in blog form instead of as a Twitter stunt or whatnot is that I’m not particularly intending to be funny, and to be transparent, I’m not completely sure whether I’m right or not. Let’s dive in.
You want to find a way to maturely and sensibly store those secrets in ways that are centralized (so you don’t have to update every server / container / function whenever one changes), secure (so they remain secret), and accessible (in practice, there’s little difference between a service going down and you losing your credentials to talk to the service). There are a number of ways to do this with native AWS services.
Status Paging You Last week The Register did an analysis piece on the AWS Status Page that heavily quoted me. This is a good thing; I’m a big fan of […]
One of the often-debated questions in AWS is whether AWS account IDs are sensitive information or not and the question has been oddly-difficult to answer definitively. AWS is extremely clear […]