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).
1. 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.
2. 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.)
3. 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.
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.
Get Split Certified
Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.
Switch It On With Split
The Split Feature Data Platform™ gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Switch on a free account today, schedule a demo, or contact us for further questions.