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
Related
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.
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.
We manage environments for different customers.
On Microsoft Azure is possible to the same user to be part of different Directories and Subscriptions.
It's all matter of invites and permissions.
Is it possible to use the same (email) account to manage environments in different organizations on AWS?
You can create an IAM user for the same person (email address) in multiple AWS accounts. To log into a different account, the person would use the login screen that corresponds to the account they want to access. This is how it works if you are creating IAM users in an account. They would not be linked, so to see a different account they would need to go to a different login url--and likely a separate password even though the email address may be the same. Essentially, they would be separate users in separate accounts, with no linkage.
For enterprises, you can use things like SAML authentication where users would authenticate with their own company, then go to a link like https://signin.aws.amazon.com/saml which will show all of the accounts to which they have access. Then it is just a matter of picking the account to which you want to connect.
See
https://aws.amazon.com/single-sign-on/?org_product_ft_sso
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html
I know i can create roles and switch between them and I've done a bit a research and it seems the answer is no but I just wanted to make sure.
So i was hoping that when a account joins my organisation, there would be some way for me to use my master account to login to the new OU, e.g. without me having to login and create new roles / users etc. Is this possible?
In order to access the new account from your existing “master” account, the new account that joins your org needs to have a role which allows cross-account access from your master account.
Its worth noting that many organizations automate the creation of accounts, and then use CloudFormation to configure the account (which you could use to create a cross account role for you to use to access the new account). You can learn more about this in the AWS tutorial here.
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.