How do I handle development and production environments in AWS?

user_5923408 0
Viewed 4419

Building an app to be launched in production - and unsure how to handle the dev/production environments on AWS.

If I use multiple buckets, multiple DynamoDB tables, multiple Lambda functions, multiple Elastic Search instances, EC2, API gateway - it seems SUPER cumbersome to have a production and a dev environment?

Currently there is only ONE environment, and once the app goes live - any changes will be changing the production environment.

So how do you handle two environments on AWS? The only way I can think of - is to make copies of every lambda function, every database, every EC2 instance, every API and bucket.... But that would cost literally double the price and be super tedious to update once going live.

Any suggestions?

amazon-elastic-beanstalk aws-lambda amazon-web-services amazon-ec2 amazon-s3
2 Answers

There are couple of approaches. However, regardless of option I have found it best to keep as much infrastructure as code as possible. This gives the maximum flexibility in terms of environment set up and recoverability.

There's the separate account approach

  • Create a new account
  • Move all your objects(EC2, S3 etc) into this account
  • This is easily done if you have the majority of your infrastructure as code and are working out of version control such as git - as you can use AWS Cloudformaton.
  • Make sure you rename the s3 buckets to something which is globally unique and compliant

You are then running 2 separate instances of everything. However, you can put some cost controls in place such as smaller EC2 instances. Or, you can just delete the entire Cloudformation stack when you are not using it and then spin it up when needed. There is more up front cost in terms of time with this approach, but it can save $$$ in the long run. Plus, the separation of accounts is great from a security perspective.

One account approach

This can get a bit messy but there are several features which can help you split out one account into dev and production.

  • Lambda versioning. If you are using lambdas you can get versioning and alias. Which in effect means you can have one lambda set up with a production and dev version under the same function name.

  • API Gate way has 'Stages'. This is effectively environments and you can label one production and one development to split the separations of concern for a single API.

  • S3 buckets. You can always make a key at the top level of the directory S3://mybucket/prod/ and s3://mybuckey/dev/. It's a bit messy, but better than having everything in the one directory.

However, what you really need to ask is how much does it actually cost to run a second account verses one account for this use case? and the answer is probably close to the same.

That's the advantage of AWS, and cloud computing in general. You only pay for what you use. Running a lambda across two accounts costs the same as running one lambda in a single account but invoking it the exact same amount of times.

The two account approach also gives a lot more clarity into what is going on, and helps prevent issues in production where a development piece of code finds its way in because it is all in one account.

user_138307320

I suggest two AWS accounts. Then make a CloudFormation template that provisions all the resources you need. Once you make the template, it is no longer cumbersome, and having side-by-side environments makes it easy to test code updates before they go live. It is not a good idea to test changes in a production environment.

Yes, this will mean double the costs, but you can always delete the CloudFormation stack in your pre-prod account when you are done testing so there are no idle resources. You just spin them up when you need to test, then spin them down when you are done. So you are only doubling costs for that small window of time when you are testing. And pushing the changes live is just a matter of updating the CloudFormation stack.

These cloud capabilities are one of the big selling points for moving to the cloud in the first place--they can solve the problem you describe without it being cumbersome, but it does take investment in building the CloudFormation template (infrastructure-as-code).

user_2300550
Related