Wednesday, January 24, 2018

security - Where should I setup a staging environment in Amazon VPC? And testing?

I setup the production environment for my service in an Amazon VPC in Oregon:




  • 2 availability zones

  • 1 public subnet (including bastion, nat, and ELBs) and 3 private subnets (database, web servers and configuration/supervision) in each availability zone.

  • 11 security groups



There are about 25 VMs, for now, and hopefully it will grow.




Now I'm going to setup the staging environment, but I'm not sure where to put it:




  1. should I simply put the staging instances next to the production instances? Basically, simply reuse the same Amazon region, the same availability zones, the same subnets and the same security groups? I would just need to create new ELBs pointing to staging instances, and that's it. Simple.

  2. or should I put the staging instances in their own subnets, but still in the same region/availability zones? The public subnets would have to be the same though, because you cannot have two public subnets in a single availability zone. Having separate subnets might make it easier to manage things, and I could have dedicated routing rules, to go through different nat instances and possibly a different bastion as well. More complex, but tighter security. I think I might not need to double the security groups though, because I could have a single overall network ACL forbidding traffic between production and staging subnets.

  3. or should I duplicate the whole setup in a different VPC? Since I can only have one VPC per Amazon Region, I would have to do this in a separate region.



The whole point of the staging environment is to be identical to the production environment (or as close as possible). So setting up staging environment in a different Amazon Region just feels wrong: this rules out option 3, doesn't it?




Option 1 is closest to the target of being as close to production as possible. But having staging and production environments in the same subnets feels a bit like a potential security issue, right? So I'm somewhat leaning towards option 2, but I wonder if the potential security issues are serious enough to justify having twice as many subnets to manage?



And what about the testing environment? It should resemble production as well, but it does not need to match it as closely: everything can fit on a few instances, no need for ELBs and everything. Perhaps this environment could all fit in a single dedicated subnet in the same VPC? Being in the same VPC, it would have simple access to the git repository and chef server and supervision tools and openvpn access, etc.



I'm sure many people have been through these considerations? What's your take on this?



Thanks.

No comments:

Post a Comment

linux - How to SSH to ec2 instance in VPC private subnet via NAT server

I have created a VPC in aws with a public subnet and a private subnet. The private subnet does not have direct access to external network. S...