4 ms·

I think it is easy to have dev, qa and prod VPCs. Without VPC these separate infrastructure groups might be harder to split out. I usually reference security gr

I think it is easy to have dev, qa and prod VPCs. Without VPC these separate infrastructure groups might be harder to split out. I usually reference security groups instead of subnets in security groups, avoiding referencing IP ranges (v4 or v6) entirely.

watermelon0 7y ago
You can also use multiple AWS accounts to separate those environments, which also eases user management (usually you have different people with access to each environment, with some overlap). This also means that developers can have close to admin privileges, since the worst they can do, is to disrupt work of another developer, without affecting either QA or production.
- WaxProlix 7y ago
  Accounts are the correct level to separate these at. Keeps credentials easier to manage for devs, techs, etc, and limits blast radius if unauthorized accesses take place.
  - StreamBright 7y ago
    >> This also means that developers can have close to admin privileges >> limits blast radius if unauthorized accesses take place. I am not sure if admin privileges are the right way of limiting blast radius. Reasonable roles with least privileges are. "In information security, computer science, and other fields, the principle of least privilege (PoLP), also known as the principle of minimal privilege or the principle of least authority, requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose."
    - WaxProlix 7y ago
      Yeah, and you want those roles and accounts scoped appropriately. Someone with the 'Admin' role in a pre-prod account wouldn't necessarily get that same role in a production one. Someone with admin in a standard prod account might not get that same privilege in an account that you manage for a customer, or one with extra compliance requirements, etc.
scarface74 7y ago
Which is really an old school way of doing it. Having multiple VPC's doesn't get around account limits, resources with the same name (sns topics, queues, stacks, etc.) Just use separate accounts in an Organization. You can give your developers almost complete unrestricted access to your dev account.
- StreamBright 7y ago
  I work with both style of AWS installations. Having organization is a constant pain for people who access multiple accounts even with something like Okta. 1 browser can access 1 account and if you switch you have to go through the switching process, or use multiple browsers. Quite often people would like to access cross account resources which a whole different level of discomfort. This is why I still think, old school or not, that having a single account and multiple VPCs is a better option.
  - scarface74 7y ago
    If you’re using AWS as a more expensive colo and mostly just using VMs it’s fine. But once you start actually using AWS for anything else it’s s pain. You have to worry about the different service limits and they are all shared. What’s the process for giving developers access to experiment? When you have different accounts, the development department can have basically unlimited access to the account and moving to production is basically getting a CloudFormation template approved and run by the Devops team.
    - StreamBright 7y ago
      I am not using AWS as a more expensive colo, actually as a much much cheaper colo instead. I have optimized several workloads on AWS to save several hundred thousand / year for companies. In my experience giving unlimited access to anybody is a fairly bad idea since it that credential gets stolen you are going to quickly figure out how much a bitcoin mine costs on AWS. I find it counter productive to have a separate DevOps team and prefer the DevOps resources embedded into teams. I also do not like CloudFormation, it is a horribly verbose and complicated tool there are many alternatives that are better for the use cases for the customers I work with. I agree that you have to worry about service limits which is exactly the right thing to have, instead of living a wasteful life pretending that we have infinite resources.

watermelon0 7y ago

You can also use multiple AWS accounts to separate those environments, which also eases user management (usually you have different people with access to each environment, with some overlap). This also means that developers can have close to admin privileges, since the worst they can do, is to disrupt work of another developer, without affecting either QA or production.

WaxProlix 7y ago
Accounts are the correct level to separate these at. Keeps credentials easier to manage for devs, techs, etc, and limits blast radius if unauthorized accesses take place.
- StreamBright 7y ago
  >> This also means that developers can have close to admin privileges >> limits blast radius if unauthorized accesses take place. I am not sure if admin privileges are the right way of limiting blast radius. Reasonable roles with least privileges are. "In information security, computer science, and other fields, the principle of least privilege (PoLP), also known as the principle of minimal privilege or the principle of least authority, requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose."
  - WaxProlix 7y ago
    Yeah, and you want those roles and accounts scoped appropriately. Someone with the 'Admin' role in a pre-prod account wouldn't necessarily get that same role in a production one. Someone with admin in a standard prod account might not get that same privilege in an account that you manage for a customer, or one with extra compliance requirements, etc.

scarface74 7y ago

Which is really an old school way of doing it. Having multiple VPC's doesn't get around account limits, resources with the same name (sns topics, queues, stacks, etc.) Just use separate accounts in an Organization. You can give your developers almost complete unrestricted access to your dev account.

StreamBright 7y ago
I work with both style of AWS installations. Having organization is a constant pain for people who access multiple accounts even with something like Okta. 1 browser can access 1 account and if you switch you have to go through the switching process, or use multiple browsers. Quite often people would like to access cross account resources which a whole different level of discomfort. This is why I still think, old school or not, that having a single account and multiple VPCs is a better option.
- scarface74 7y ago
  If you’re using AWS as a more expensive colo and mostly just using VMs it’s fine. But once you start actually using AWS for anything else it’s s pain. You have to worry about the different service limits and they are all shared. What’s the process for giving developers access to experiment? When you have different accounts, the development department can have basically unlimited access to the account and moving to production is basically getting a CloudFormation template approved and run by the Devops team.
  - StreamBright 7y ago
    I am not using AWS as a more expensive colo, actually as a much much cheaper colo instead. I have optimized several workloads on AWS to save several hundred thousand / year for companies. In my experience giving unlimited access to anybody is a fairly bad idea since it that credential gets stolen you are going to quickly figure out how much a bitcoin mine costs on AWS. I find it counter productive to have a separate DevOps team and prefer the DevOps resources embedded into teams. I also do not like CloudFormation, it is a horribly verbose and complicated tool there are many alternatives that are better for the use cases for the customers I work with. I agree that you have to worry about service limits which is exactly the right thing to have, instead of living a wasteful life pretending that we have infinite resources.