Are you an all day every day user of the Amazon Web Services (AWS) management console? Do you represent a number of clients, each with their own AWS assets and separate AWS accounts? Do you find yourself managing dozens of AWS account credentials and juggling logins just to make small changes throughout your day? Are you tired of jumping through hoops before you can even start your work?
If you’re a developer at a digital marketing agency, (and like many developers these days, your cloud provider of choice is Amazon,) the answer to these questions is probably yes. If so, read on! If not, here are some other fantastic blog posts.
Let me present a brief history of AWS account management. Members of emfluence’s web dev team have been building our clients’ homes in the cloud at AWS for years. We could spin up new services for our clients with unprecedented ease, and it was all on demand. Hurray! But we soon found ourselves in a mess of infrastructure, with a large number of assets across a large number of services, all within one account. We struggled to identify which assets and clients were accruing which charges.
Screenshot of a single AWS management console dashboard: That’s a lot of services to keep track of!
Amazon gave us some tools to manage the complexity, like tags and resource groups, but those tools, unfortunately, weren’t keeping pace with the sprawling list of available services. And those tools really seemed to be more geared towards a monolithic organization’s assets. For a number of reasons, including billing and external access management, we began moving more and more of our clients into distinct AWS accounts. Thanks to Amazon’s consolidated billing system, we could still manage costs internally and it was a lot easier to see which assets were connected to which clients. Hurray.
But now we had another challenge: Internal access management. When we only had one account, we could create Identity Access Management (IAM) identities for each team member and easily manage what they had access to. Unfortunately, each IAM account only applies to one AWS account. And so our options were to either give each team member the root account credentials for every client, or create separate IAM identities in every client’s account. Did I hear you say multi-factor logins? For each account? Ouch. We were stuck between unsecure and unwieldy.
This year, AWS introduced cross-account access for this exact use case. We’ve since stripped our multitude of accounts of their individual IAM team member identities in favor of this approach. It’s great because we don’t need to manage a ridiculous number of identities (team members multiplied by the number of AWS accounts), or jump through login hoops all the time.
One identity per person!
Here’s how we use it: Each account has a single IAM role setup for cross-account access by team members. We don’t have an overly stratified dev team, so we’re fine with just one role that gives access to the common set of assets. The role contains an access URL, which we keep stored with client information in our internal knowledge base. Staff with appropriate credentials in our main AWS account can simply look up a client and click on the link to jump right into managing assets. Hurray!
There are a lot of benefits to the cross-account access system. It simplifies things greatly for us. And it’s clearly what AWS has in mind for our use case. Of course it’s not perfect. For example, you can’t permanently add shortcut links to your account/roles menu in the AWS dashboard – which means that we need to keep taking the extra step of jumping into our KB. And while you can switch quickly, you can’t keep multiple accounts open in multiple windows – which would be handy if you were transferring assets or copying configuration details. But who am I to complain? We’re finally on the right track with identity AND account management and it feels great that AWS is addressing the agency use case.
[more]
