Does anyone know the differences between the company account and personal account in terms of functionality in AWS?
The Amazon AWS help page says:
Choose Company Account or Personal Account.
Note: These two account types are identical in functionality.
Seems there are no documents there to state the differences.
Because I have a client who not yet forming a company but would like to kick start the services, should we start with personal account and any possibility to transfer to company account afterwards?
There is no difference in functionality, and if you client ever gets big enough where it matters you can always contact AWS and have them change the account configuration.
IMO, your client is not risking anything by just setting up a personal account to get going, and they may never need to switch it — just make sure that the person who sets up the account isn't someone that is likely to quit and take the account with them or hold it for blackmail — the root account credentials should be controlled by the owner or other officer of the company. All other users should have IAM accounts
Related
I have recently made a program that listens to a PUB/SUB topic that is connected to a Gmail account. I have it all working fine. When a push notification arrives it will do different tasks based on the message content.
The problem is that I use a Service Account to connect to all the API's on Google Cloud Platform that I need. The Service Account allows access to ALL of our Gmail accounts in our organization. I need to somehow limit the access to a specific Gmail account.
The closest I could find to this issue was this question Impersonating list of users with Google Service Account. However, the only solution presented there was to turn my project into a marketplace app which I do not want to do.
I have tried setting up an Organizational Unit and trying to limit the scope to that somehow, but there seems to be know way (that I can find) to do it. I did try speak with Google Cloud Platform help but they didn't know the answer as it didn't quite fall under their area of expertise and referred me on to another help group, but I'm not eligible for them because I don't pay for support.
Edit: It doesn't actually appear that what I want to do is possible. I'll be going back to an OAuth2 method of authentication.
Understanding service accounts explains the possibilities:
Service accounts can be thought of as both a resource and as an identity.
When thinking of the service account as an identity, you can grant a role to a service account, allowing it to access a resource (such as a project).
When thinking of a service account as a resource, you can grant roles to other users to access or manage that service account.
Now try to fit that impracticable intent into there ...
If you need to limit the access of the service account to user-specific resources, this can only be done on the application level, not the system level - since a service account can impersonate just any user identity; eg. in order not to mess up the ownership, when uploading files on behalf of a user. If you want 1 user identity to access 1 user-specific resource, why even use a service account? And when using a service account, why not just impersonate as the correct identity? This could even be hard-coded, if it's only 1 user identity. But nevertheless, it can only be done on the application level - but cannot be configured for the service account itself.
Say I have a business and multiple DBA (doing business as), on AWS I can create a org hierarchy of the business and DBAs. I can invite the DBA accounts into the business org and link them so the business org is the payer. This keeps the operations of DBA independent and isolated with the convenience of consolidated billing for the business. This can also make it easy to transfer ownership of the DBA if desired without effecting the operations.
I was looking to setup something similar on GCP but it seems like each org is tied to a domain and there is no way to invite one org into another to link and provide billing. Is this correct or are there ways to link and provide billing for one org on behalf of the other?
Say I have a business and multiple DBA (doing business as), on AWS I
can create an org hierarchy of the business and DBAs.
You can create a similar hierarchy on Google Cloud.
I can invite the DBA accounts into the business org and link them so
the business org is the payer.
You can accomplish this with Google Cloud but in a different way. You cannot make one organization a branch/child of another organization, but you can add its members (identities) to another organization. The key to this is the members are not actually part of the organization. Identities are independent and added and removed easily.
This keeps the operations of DBA independent and isolated with the
convenience of consolidated billing for the business.
Google Cloud supports one or more billing accounts. Bill accounts can be assigned to projects independently of organizations. I can make my billing account responsible for any Google project (oversimplification).
This can also make it easy to transfer ownership of the DBA if desired
without affecting the operations.
Google does not have this flexibility without effort. In Google Cloud, I would not merge projects into an organization unless this objective was permanent. Instead, I would add the members required to access that project to IAM.
Projects independent of an organization can still participate in another organization and vice versa. Google Cloud Identity and Access Management (IAM) is very flexible. If I want bob#example.com to have access to Project ABC, I can add his email address to IAM and grant roles. You can also add an entire domain of users *#example.com to Google IAM. There are many more options.
You can move projects around inside the organization, but you cannot move projects to a different organization yourself - this requires opening a support ticket with Google Cloud Support.
I was looking to set up something similar on GCP but it seems like each
org is tied to a domain
Google Cloud is not tied to a domain name, Google G Suite is. If you plan to also use G Suite for multiple DBA, I would have separate Google accounts and not combine G Suite with my resources in Google Cloud. Note: G Suite supports multiple domains; for a single organization linking G Suite and Google Cloud is fine.
I find Google Cloud's method of organizations, folders, projects and IAM more flexible than AWS.
AWS and Google have powerful IAM systems. I know both very well, each has its positives and drawbacks.
While the answer from John tells what all might be possible, it didn't have details on how to do it. After a lot of searching online and experimenting I managed to do what I wanted. Below are the steps using the "business" and "dba" references in my question.
Create a payment profile with primary contact say
billing#businessdomain
Make sure the account type is Business and
not Individual. In my case, I some how ended up with an Individual
account. It is not allowed to change the account type once created.
Don't know why, but this was my first hurdle.
With business account type, it is possible to invite other users.
I wasn't sure
how to create a business account and if I could use the same email
for the business account type. From within GCP, I went ahead and did
the billing setup. Based on my login user which had the individual
payment profile, it defaulted the payment profile but allowed me to
create a new profile. I picked account type as Business but all
other details were same as what I had in the other personal account
that got created. Luckily, it went ahead and created a business
payment profile.
Once I had the business payment profile, I could
go ahead and invite user from my dba by specifying the email, say
billing#dbadomain
That email got an invitation and upon accepting
it, was linked to the same payment profile. This is the key! This
essentially allows payment profile associated with one domain
(organization) can be used for the billing account of another domain
(organization).
At this point, I went ahead and even closed the
payment profile with Individual account type and it seemed to have
worked. I didn't have any transactions so far and so it's like it
never need to exist. I wish it was possible to change the account
type for such profiles.
With this setup, the dba organization and its operations are done isolated and if ever it needs to change ownership, it can add a different billing method and separate out from the business org completely.
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 am a longtime Amazon.com customer, and now I am interested in using Amazon Web Services (AWS). So I have a question on creating an AWS account.
Do I have an option to create an AWS account that's completely separate from my Amazon.com account (with different email addresses)?
What would happen if I use the same email address for AWS and Amazon.com?
Soooo..... Ages ago... I made an AWS account, it will not let me log in to normal amazon.com with that account telling me every time my password is incorrect which it is not.... attempting to create a new account with same email asks me if i want to disable my old account..... so yea it seems the answer is:
YES: simply create the account from AWS.
If creating accounts at amazon.com THEN aws with same e-mail, you will have one linked account to log in to both.
On the other hand if both are created seperately on different e-mails, and somehow one gets compromised the other doesn't, but then you have two different logins to deal with.
So as it turns out they lied about it disabling my aws account, I decided to try it, and now I have two accounts under the same e-mail, with different passwords... So if you want that, create on aws first, then create with same email on amazon.com and when it says it will disable the other account, don't worry it won't, however it will require you to choose a different password.
Oh and one last thing... If I try to log into AWS with Amazon.com password it brings me to create a new AWS account and it's a pain to get out of that screen...
My Amazon Retail account was compromised last week. I closed it and guess what - no access to my Amazon AWS account. On querying this I was told (by Amazon) that you have to have an Amazon Retail account and that it has to be THE SAME account as your AWS one.
So a service that is a honeypot for criminals gives them the keys to your Web based business, and Amazon have zero interest in separating the two. That is nuts - sites are moving next week, can't take the risk.
People have been shouting about it on the Amazon forum for years, so I think that whilst there may be workarounds the fundamental principle must be correct. I can't risk playing about with workarounds for something as dumb as this.
These are both great questions
First,
Yes, you can and SHOULD create an aws root account email that is unique for your AWS account(s). While approaches may vary, and your email server may filter out what would otherwise be perfectly applicable emails, here is how I do it
I create an email account that is ONLY for my AWS root accounts.
AWS Requires EVERY AWS account to have a unique email
here is my pattern: myname.aws.accts#gmail.com
I have an admin (Organization) account, so I use the following email: myname.aws.accts+admin#gmail.com
I have one prod, one test and one dev account. Here are the following email patterns:
myname.aws.accts+prod#gmail.com; myname.aws.accts+test#gmail.com; myname.aws.accts+dev#gmail.com.
I've also used the pattern: myname.aws.accts+123456789012#gmail.com where 123456789012 represents the AWS Account number.
These are all interpreted as unique by AWS but route to the same email account: myname.aws.accts#gmail.com
One last comment. I have another client who uses MS Exchange and for some reason the email+extension#mybiz.com has the 'extension' portion filtered out, and these emails do NOT process. In this biz we worked around this by creating alias' emails that are still unique to AWS and aliased them in the exchange server to the awsadmin# email. does the job. probably not best practice, but in a pinch...
Second
Yes. You can link your AWS and amazon.com accounts to the same root user email.
DON'T DO IT
This is generally an anti-pattern. NOT best practice, and fraught with problems...
I know of no good reason to do this. Once done, it is nigh near impossible to convince AWS - AMAZON to unlink these accounts. You WONT be able to separate them yourself - they are strongly coupled once the link is made. you might succeed in separating your AWS and AMAZON account if you are a paying customer of AWS business or Enterprise level support, and even then, they may tell you to just delete the AWS account if you don't want AWS and amazon shared.
Once the two accounts - store and AWS - are created with the same email account, I believe they are forever linked via a single master Amazon account, and there seems to be no way to separate them: If you change the password or email address on one, it reflects in the other.
When my only AWS use was an unimportant VM with a website, it was no big deal, but once I start hosting higher-value stuff, it gets a lot more scary.
As far as I can tell, the only way to separate them is to create a new AWS account (with different email address) and transfer your resources from the old to the new.
This appears to be a painful exercise, you can't directly move an EC2 instance, though you can transfer a snapshot of an image, but everything else I don't know about yet. I would be surprised if I could transfer a fixed Elastic IP, which means changing an IP address I've been using for a long time.
In the short term - as far as I can tell - the only way to secure AWS from your consumer account compromise is to put MFA on the AWS account and then use IAM for access. That's not a bad idea anyway.
I'll be creating a new AWS account (with different email address) for all stuff going forward, and transitioning old-to-new as I get to it, but this looks like a miserable (and unbillable) exercise.
It's just crazy that Amazon doesn't appear to have a way to address this.
Yay for me being an early adopter?
EDIT: It might be possible to link two accounts via "Organizations"; that might give some options for migration that are a bit less painful. Not sure yet.
EDIT Nov 2022: Amazon appears to have rolled out split credentials: when I logged into my unified account - same email for store and AWS - it invited me to create a diff password for the AWS stuff. This is wonderful!
So your AWS and Amazon are the same accounts so you cannot create a separate retail account with the same address. (Though you can get around it by doing email+SOMETHING#domain.toplevel) So if your amazon.com account gets compromised, they theoretically have access to your AWS account.
To keep your AWS account secure, there are a few things you can do. Firstly and probably most importantly, you need to make sure you have MFA setup on the account. In fact, you should do this whether you use amazon.com with the same account or not.
I heavily suggest looking at the Trusted Advisor Best Practice Checks on AWS' website.
The rule of thumb here: they are not interchangeable.
If you created AWS account it will not allow you to login automatically to Amazon.com.
The same with consumer account, it doesn't provide access to AWS by default, because AWS has separate verification process.
Amazon Music account means access to consumer Amazon.com but not to AWS.
Though, I never tried to delete AWS and don't know what happens if you delete either of them, whether this causes deletion of the other or not.
I will be hosting infrastructure for several different clients. Complete, total, 100% separation of client's AWS infrastructure is necessary (leagal etc). So I need some advice on how best to structure my accounts.
I will have a master account with MFA. It will not actually ever spin-up and infrastructure. It is merely to be a top-level billing account. Then each client will have their own separate AWS account. With I guess a separate root login and separate MFA. Each client account will be linked to the Master account for consolidated billing. This is neat because if they move their business else where then we just give them the IAM details for the account and strike it off from Master and we are done.
What I am not sure of is that to set up a brand new AWS account you need a unique email account. We don't want the client to ever have to first setup the account so do we need to have a whole bunch of email aliases to use on our company domain (client#mydomain.com, client2#mydomain.com etc) and then use them to set up new AWS accounts? Is there a better way than this? It could get pretty clunky to have to have a new email alias every time a new client joins.
Second, will we need a box full of MFA devices - one for each account, or will the same device work for all accounts?
Any pointers gratefully received. Thanks
If you have a Gmail address like example#gmail.com, then you can register AWS accounts using email addresses like:
example+CUSTOMER1#gmail.com
example+CUSTOMER2#gmail.com
example+CUSTOMER3#gmail.com
and all the emails will go to your same gmail account. You could auto forward from gmail to another address.
This also works for Google Apps email addresses, if you are using that to host your company email.
Instead of physical MFA devices, you can use the Google Authenticator app on an Android or iPhone with one entry for each customer AWS account.
You mention consolidated billing in your question title, but not in your question.
Beware the following re. consolidated billing:
If you purchase reserved instances for one client, the benefit of that will be shared with all your clients, so your costs will be out of sync.
If you plan to re-charge your clients, and you want to use reserved instances, don't use consolidated billing.
As for you question:
https://support.google.com/mail/answer/12096?hl=en
Most email platforms support some form of aliasing.
You may also be interested in
http://www.nightbluefruit.com/blog/2014/02/command-line-tool-for-checking-status-of-instances-in-amazon-ec2/