I have some engineers that have built some things using EC2 instances. I built these instances logged in with my AWS administrator account (Root user?). Now, I want to create a PROD "container" that only certain users can see. Secondly, I'd like billing for this to be completely separate, if possible, so we can bill the customer directly. I'm looking for a structure like this:
Customer 1
PROD
EC2 Instance 1
EC2 Instance 2
DEV
Customer 2
PROD
DEV
And then separately, I'd like to be able to say "Engineer 1 can access Customer 1 - DEV" or "Engineer 2 can access Customer 2 - PROD".
I know how to do this in Azure, but AWS is confounding me. What would the containers/folders above be called? Organizations?
You should setup different AWS Accounts for each application environment, e.g. "Customer 1 - DEV", "Customer 1 - PROD", "Customer 2 - DEV" and so on. This way you can leverage AWS IAM on the account level to grant individual developers access and have a clean boundary for billing as well. I'd stay away from using tags for cost allocation, as that's usually very hard to maintain clean.
To setup multiple AWS accounts, you need AWS Organizations. Organizations allows you to build a hierarchy of multiple AWS Accounts, just like an Azure Tenant with multiple Azure Management Groups and Subscriptions. In an AWS Organization you can designate one account as the "payer account" and that's the one that receives all the consumption charges for all managed accounts in your org. These charges are broken down per account, so you can easily chargeback that cost to your customers.
If you have more than a handful of accounts, I'd recommend building a landing zone. AWS Control Tower is a good point to get started though there are other options.
Use AWS Organizations and IAM Identity center. Create different accounts (and organizational units) for dev, prod, staging etc. workloads and grant access rights to certain accounts only for certain individuals. Even if the all accounts belong to same organization, you will be able to get cost reports for each account.
Rather easy to implement after reading documentation for those services.
Check also AWS Control Tower which can be used to create a secure landing zone for use case you described.
Related
I am creating an AWS organization and some member accounts within their own OUs (organizational Unit). Is there a way to create new accounts in the OUs from the member accounts or is the only way to create new accounts from within the Management account?
For example: account a-acc is in OU a-ou and has a service catalog product to create new accounts in a-ou but not only there. If this is possible, how can I do it?
As far as I'm aware, the only way to create new accounts in an AWS organization is via the Organizations API in the management account.
It appears what you want to do is provide self-service tenant provisioning capabilities to your teams. There's a few options
Use AWS Control Tower Account Factories expose them via AWS Marketplace to member accounts
Use a custom AWS Marketplace service (e.g. the "old" Account Vending Machine solution)
Build an in-house tenant provisioning process outside of AWS, e.g. with GitOps or an existing service management portal (ITSM)
With all of these solutions you need to implement a form of the "same OU" restriction you mention. For the AWS marketplace based solutions you can e.g. create a product wrapping the "generic" account factory and pre-populate the OU parameter for where the account is going to be placed. This means that you have to create and manage many different "wrapping" products.
From my experience with setting up resource hierarchies for enterprises on many different clouds its much better to stay flat and refrain from modeling your organizational structure (e.g. departments, teams, divisions) into the cloud resource hierarchy. Most IT systems outlive the organizational structure they were born from and re-organizing your cloud resource hierarchy is usually pretty painful. I'm just mentioning this here because your "same OU" restriction sounds like "I want to give this team their own OU and manage their own accounts".
If this accurately describes what you're trying to accomplish, here's some ideas for alternatives
model organizational hierarchy like department etc. as tags on accounts instead of mapping to OUs
leverage a cloud foundation platform that can enforce permission models (who can create a new account) and tagging (e.g. accounts requested by this team always get tagged with their team id)
first of all
dont use aws organisations but use AWS Control Tower
secondly
either way cotrol tower or organisation
you can use aws service catalog to create new accounts
Yes, you can create AWS accounts from member accounts. To do this, you'll need to provide your Amazon account credentials and select the AWS account type ( Individual , Business , or Partnership ) that corresponds to your organizational structure. You'll then be prompted to enter your organization's primary contact information ( Corporate Email Address and Phone Number ). After you've completed these steps, you'll be able to create an AWS account and begin using AWS services.
At the bottom left corner, it says Developer accounts which is in addition to the Product accounts that we have i.e Sandbox/dev/test/prod/tools
Is it recommended to have individual developer accounts?
How to set up individual developer accounts when using the Landing zone set up. (As of now, all users login to the landing zone account and assume role in sandbox/dev/test/prod accounts.
Is it recommended to have individual developer accounts?
Playground/sandbox environments are a very effective pattern for building cloud skills with your teams. Using them at scale however requires good discipline around budgets (alerts!) and decomissioning process. Unless you have the required automation in place to manage that, it's probably better to delegate that responsibility to product owners/managers (or whoever is responsible for cost and budgets of cloud environments for their teams).
How to set up individual developer accounts when using the Landing zone set up. (As of now, all users login to the landing zone account and assume role in sandbox/dev/test/prod accounts.
The assume role setup is quite tedious, AWS SSO provides a much better foundation to build on. Though you can of course also always setup individual AWS IAM users in developer accounts with a SAML Identity Provider in each account. That's quite a bit of work to automate though and is an additional hurdle to jump through for letting developers CLI/API access.
I really dont like this phrase, but "it depends". Having dedicated accounts for each developer can be a luxury but at the same time, if resources are left unterminated, you will see a raise in the aws bill. The dev account should be specific to some projects, that the team is working on. You can also have some short live, sandbox accounts to do certain POCs.
AWS Landing Zone, comes with an Account Vending machine. It is built using the AWS Service Catalog. You should use that to create/provision new accounts.
I will recommend, to checkout the AWS Control Tower. This is the new version of AWS Landing Zone solution, released as a service
I know it might sound like a basic question but I haven't figured out what to do.
We're working on having a testing environment for screening candidates for Cloud Engineer and BigData interviews.
We are looking into creating on demand AWS environments probably using Cloudformation service and test if the user is able to perform specific tasks in the environment like creating s3 buckets, assigning roles, creating security groups etc using boto3.
But once the screening is finished, we want to automatically tear down the entire setup that has been created earlier.
There could be multiple candidates taking the test at same time. We want to create the environments (which might contain ec2 instances, s3 buckets etc which are not visible to other users) and tear down them once the tests are finished.
We thought of creating IAM users for every candidate dynamically using an IAM role and create a stack automatically and delete those users once the test is finished.
However, I think the users will be able to see the resources created by other users which is not what we are expecting.
Is there any other better approach that we can use for creating these environments or labs and deleting them for users? something like ITversity and Qwiklabs.
The logged in user should have access to and view the resources created only for him.
Please suggest.
Query1:
Let's say I have created 10 IAM roles using and one user using each of those roles. Will the user in created from IAM role 1 be able to see the VPCs or EC2 instances or S3 or any other resources created by another user which is created by IAM role 2?
Will the resources be completely isolated from one IAM role to another?
Or does service like AWS Organizations be much helpful in this case?
The Qwiklabs environment works as follows:
A pool of AWS accounts is maintained
When a student starts a lab, one of these accounts is allocated to the lab/student
A CloudFormation template is launched to provision initial resources
A student login (either via IAM User or Federated Login) is provisioned and is assigned a limited set of permissions
At the conclusion of the lab, the student login is removed, a "reaper" deletes resources in the account and the CloudFormation stack is deleted
The "reaper" is a series of scripts that recursively go through each service in each region and deletes resources that were created during the lab. A similar capability can be obtained with rebuy-de/aws-nuke: Nuke a whole AWS account and delete all its resources.
You could attempt to create such an environment yourself.
I would recommend looking at Scenario 3 in the following AWS document:
Setting Up Multiuser Environments in the AWS Cloud
(for Classroom Training and Research)
It references a "students" environment, however it should suite an interview-candidate testing needs.
The “Separate AWS Account for Each User” scenario with optional consolidated billing provides an excellent
environment for users who need a completely separate account environment, such as researchers or graduate students.
It is similar to the “Limited User Access to AWS Management Console” scenario, except that each IAM user is created in
a separate AWS account, eliminating the risk of users affecting each other’s services.
As an example, consider a research lab with 10 graduate students. The administrator creates one paying AWS account,
10 linked student AWS accounts, and 1 restricted IAM user per linked account. The administrator provisions separate
AWS accounts for each user and links the accounts to the paying AWS account. Within each account, the administrator
creates an IAM user and applies access control policies. Users receive access to an IAM user within their AWS account.
They can log into the AWS Management Console to launch and access different AWS services, subject to the access
control policy applied to their account. Students don’t see resources provisioned by other students.
One key advantage of this scenario is the ability for a student to continue using the account after the completion of the
course. For example, if students use AWS resources as part of a startup course, they can continue to use what they have
built on AWS after the semester is over.
https://d1.awsstatic.com/whitepapers/aws-setting-up-multiuser-environments-education.pdf
However, I think the users will be able to see the resources created by other users which is not what we are expecting.
AWS resources are visible to their owners and to those, with whom they are shared by the owner.
New IAM users should not see any AWS resources at all.
I have a software business and different unrelated customers. I manage their servers and other services on their own AWS accounts. Each has its own.
I'd like to simplify the management by having a root aws account of my company, and link different accounts to it with different payment methods. In most cases, clients use their own payment method..
What is the best way to achieve this?
There are 2 scenarios:
Clients pay for their own account: Create a cross account role in each of your customer's account that gives access to your account to do things in their account. Take a look at this tutorial - https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html#tutorial_cross-account-with-roles-3 . You will be able to use the cross account role to gain access to their account from your account by switching to their account from console. Take a look at the steps here - https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html
You pay for all the clients: In this case you can use AWS organizations in your account and add the accounts of your customer's to it. You will also need to create cross account role like in step1 so that you have access to do things in their account. This will allow to to have a single consolidated bill for all the accounts while you still get the bifurcated billing details of each account. Take a look at the tutorial here: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tutorials_basic.html
I have domains, instances, and buckets open on my AWS account - some are running databases on them.
I can't pay monthly for all of these services, because some of them aren't my own - I did them as work for others. And rather than going through the hassle of transferring the compute and database to another instance on another account, I'd like an IAM user to pay with his/her credit card for the services he owns.
Can IAM users pay monthly for services on my AWS account? If so, how?
No. There's no mechanism for what you want.
You may be interested in Amazon DevPay, which is sort of like what you're asking for. But I think you're doing contract work for individuals and DevPay is aimed more at providing an AWS-like service atop AWS and selling it to other developers.
The other direction is to make your clients create an AWS account. If you want to be fancy, you could use Consolidated Billing to create a sub-account under your control but billed to the customer. I think this is the best fit for consulting work, but getting there from your current setup will be painful.
There are some services (S3, ..) where you can let the client pay per call, bu for the rest I believe that your account is only yours. What I do is presenting the detailed billing and I let the company reimburse the costs.
Maybe you will have to migrate the environment. If your clients are not proficient aws users, you may want to build a cloud formation script that would enable them to start and access the environment in a few clicks..
G.