Planning ahead on how you will use your AWS resources can be really hard, but let’s talk about some best practices that will help you start on the right foot (or at least to ensure you don’t do anything that you’ll need to fix later).
- Use an email alias. If you’re creating an account for a company, a team, or even a project, make sure you use an email alias instead of an actual person’s email address. If the person creating the account leaves your organization, you’re stuck with an email that you can’t check.
- Secure the Root Account with MFA right away, because security really matters! (This should be the first thing in your “To Do List” after creating the account.)
- Create an IAM user. Once the Root User has been secured, create an IAM user for yourself (a non-root user) and assign “Administrator Access” permissions. IAM users can sign in to the AWS Management Console for your AWS account with a special URL, and setting this Friendly Sign-In Link is really a good idea. (Please make sure to bookmark it.)
- Optional: Enable IAM user access to billing information if you want to share this information with other team members. Otherwise, only the Root user will be able to see this information.
- Finally, set up CloudTrail to log all actions on your account. You should start tracking everything from day one.
Those best practices are easy and straightforward, but one thing that people keep asking me is, “What’s the best approach for managing multiple environments using AWS?”
To build great apps, startups typically require multiple environments, such as Development, QA, Staging, and Production environments. As your startup grows your infra can go wild, but to be honest, there is no correct answer for how to manage this arrangement. It depends on too many factors, and no silver bullet or formula exist for doing this “right”.
Currently it is valid to say that there are three patterns that people (generally) use to manage multiple environments in AWS:
- One AWS account and one big (eventually huge) network. This is a more traditional datacenter mindset.
- One AWS account and many VPCs in which each VPC is a different environment.
- Many AWS accounts (with consolidated billing) in which each environment is a separate AWS Account.
Today we are not going to deep dive and describe all of the patterns mentioned above, but I will share what we have done at Split. We combined many AWS accounts (with consolidated billing) and VPCs that isolate different environments.
Currently we have three accounts:
- AWS Billing Account: This account houses our credit card and the billing parent for the other two. We do not use any other services from AWS in this account.
- AWS Dev: We have two main VPCs—Development and Staging. In this Deve account, we merge and deploy (CI/CD) our binaries and perform all our tests. Developers can access and manage their own resources to sandbox new microservices and play around with AWS features or services.
- AWS Prod: This account is locked down and very few people have access to it. All resources are only accessible from VPN clients (bastion host/Vpn Server). In this account, we host our infrastructure for Canary Deployments (Pre-Prod Environment) and obviously a VPC for our Production Environment.
This configuration enables us to have seamless billing processes while giving developers the freedom to tinker with their testing environments without sacrificing the sanctity of our production environment. *Other approaches are available, but they are not yet popular or mainstream.
I hope this summary puts some light on how to best organize your cloud environment to keep both a restricted access to production as well as providing some flexibility to your dev team.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
At Split, we pride ourselves on our security-focus. We’ve kept customer data security a number one concern since day one. With this focus in mind, we are in the process of deprecating non-secure versions of TLS (1.0 and 1.1) in preparation for a broad market deprecation of legacy TLS. Beginning…
At Split, we “dogfood” our own product in so many ways. Our engineering and product teams are using Split nearly every day. It’s how we make Split better.
Product experimentation is the most effective way to determine what works best for end-users. You can measure engagement with a feature and hypothesize ways to improve that engagement, which will ultimately impact one or more critical business metrics. If you’re setting up an experiment, it’s mission-critical to implement A/B testing…