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.
The increased usage of feature flags and canary releases (also “canary deployments”) in software development has had a tremendous impact on the overall release process for software companies globally. These canaries and feature flags allow you to test your features in production , convert your monolith to microservices, perform A/B…
Kicking off an internally developed feature flagging system is standard practice for many companies today as feature flags help engineering teams release faster at lower risk. As use cases for feature flags grow, so do the challenges of building an in-house system. This article will explore 10 challenges of building an in-house feature flagging solution.
This is one post in a series about managing the breakup of a monolithic architecture into a small service. In the first post of the series we looked at some fundamental techniques which allowed us to perform this sort of broad architectural shift as a series of small, safe steps. We started off…