Should I create an IAM user in production env to operate resources in mgmt vpc

Gruntwork Customers
1

Hi guys!

I am reading an article named How to deploy a production-grade VPC on AWS. I could not understand if I should create an IAM user in production env to operate resources in mgmt vpc. According to multiple accounts practices, only roles can be created in production env. So how can I resolve this problem.

In addition to the problem mentioned above, I also could not understand if CI server, such as Jenkins, is deployed in mgmt vpc in production env, why we still use shared-service account to deploy CI server.

Thanks in advance!

2

Hi there!

Please check out our How to configure a production-grade AWS account structure using Gruntwork AWS Landing Zone for instructions on how to set up multiple AWS accounts, where to create IAM users, where to use IAM roles, and so on.

For something like Jenkins, you’d most likely deploy it into the shared-services account and NOT in production.

Hope that helps!
Jim

3

Hi Jim!

I have read the article about Landing Zone, and I know all IAM users should be created in security or root accounts. The other accounts, such as shared-service, should only contains roles.

Until recently, I read an article How to deploy a production-grade VPC on AWS and found the following code

Screenshot_2020-04-03-23-00-15-678_com.android.browser
Screenshot_2020-04-03-23-00-15-678_com.android.browser1080×2160 244 KB

It seems that mgmt vpc is created in production env, and because CI servers, OpenVPN servers are usually deployed into mgmt vpc, that’s why I though CI servers should be deployed into production account.

According to your recommendation, it seems that each mgmt vpc should be created in shared-service account. Does it means each account, such as production,stage,dev, should be paired with an independant mgmt vpc created in shared-service account?

Thanks!
slz

4

There are a few different options, and which you use depends on your needs:

  1. mgmt VPC: You can deploy a mgmt VPC in each account: e.g., one in shared-services, one in dev, one in stage, one in prod. It’s a useful place to put DevOps tooling in those accounts, such as OpenVPN servers (which you might have in each account), or Jenkins (which is probably only in the shared-services account), or monitoring/alerting tools (which would probably be in the production account, maybe the others too).
  2. Peering to the mgmt VPC: A separate decision is whether you should create a VPC peering connection between those mgmt VPCs and other VPCs. For example, it usually makes sense to peer the mgmt VPC to the app VPC in the same account: e.g., peer the mgmt VPC in prod to the app VPC in prod so that the OpenVPN server in the mgmt VPC can be used to connect to the apps in the app VPC. You might also want to peer the mgmt VPC from one account to the app VPCs of other accounts: for example, you could peer the mgmt VPC in the shared-services account to the app VPCs of dev and stage so that you can use a single VPN (running in the mgmt VPC of shared-services) for all your pre-prod accounts.