Companies often fall into the trap of building standardized infrastructure themselves, then offer it to their teams to run their workloads on. For example:
- Compute, IaaS, which let teams spin up and down compute;
- A mix of IaaS and DBaaS, making sure that databases are managed;
- Platform as a Service to let developers build and deploy their app all by themselves without having to maintain the underlying infrastructure;
- Container platforms like Kubernetes to let teams build and deploy anything on it, as long as it can be deployed as a container
The most complex, but most powerful option lets your teams choose individually what systems and deployment technologies they want to use. You can give them full access to the products and services a cloud provider is offering. Instead of only providing a subset of the offerings, like a Kubernetes cluster, you can give teams their own AWS accounts to build and deploy their applications on. If they want to use Kubernetes for example, they can spin up their own Kubernetes cluster. This also implies that the teams need to take ownership of it. They’ll have to make a well-informed decision about the technology they want to run and support. The teams will not only need to provision it, but will also need to ensure they can manage it. Managing a Kubernetes cluster is a lot of work, and maybe they don’t need such complex features or don’t want to spend resources on it. Other managed options like ECS, Elastic Beanstalk, or building AMIs with Packer can be a better option as they don’t require any development resources.
When implemented correctly within the organization the most noticeable will be the increase in developer velocity and autonomy. Over the years we have helped implement this strategy in various startups and enterprises and have seen a lot of amazing things happen. Below we have summarized a few key points on how to make this strategy successful within your organization using Amazon Web Services (AWS).
Setting boundaries
When giving users privileged access to a new AWS account, you’ll want to make sure that users cannot use unauthorized services, or create other users with full administrator privileges. A solution to restrict user access is to use Permission Boundaries in IAM.
A Permission Boundary can ensure that a user has still full access to the AWS account, but is bound to some limits. When the user tries to create a new IAM user or a new admin role, it’ll get a permission denied when “deny rules” are specified in the Permission Boundary. That way the users can still manage the full AWS account, but can’t circumvent policies and procedures set by the enterprise.
Provisioning Accounts
When a new account is created, you can ensure that it all starts with the same configuration options. Audit logs need to be kept, certain security controls need to be on. AWS has “Control Tower” for multi-account governance to do exactly this.
Single Sign-On
You can imagine that it gets quite complicated when you have a lot of AWS accounts and you need to make sure that user X gets access to account Y and not to account Z. Identity Provider software can help you with this. Software like Okta and Onelogin can make it easy for users to log in to different AWS accounts. With a single click on a button, they can log in to one or the other account, making it easy to give out and remove access to current and new users.
AWS also has “AWS Single Sign-On” which can provide the same capabilities, but with an enterprise directory like Active Directory where the users are stored.
Security
When you have a multi-account strategy, you’ll need to keep these accounts secure. You don’t want anyone accidentally creating a public S3 bucket. Security tools to monitor & remediate these compliance issues will be required to keep your accounts safe. AWS Config can be used to invoke rules on config changes to alert and remediate non-compliance resources within Amazon accounts.
Amazon services are getting more and more cross-account capabilities to provide cross-account security monitoring and compliance. Besides security, AWS Backups for example can roll out backup policies over all the AWS accounts in your organization. We expect more and more services to get these cross-account capabilities to make it easier to manage a multi-account setup.
