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.
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 have a use case, a user with several AWS accounts. Not all accounts/email addresses are known, not documented, change of staff. There is a bank card that is being billed. How can I determine which AWS account is generating the billing ?
Thanks for any assistance.
Take a look at the AWS Cost Explorer it allows you to see detailed information about the costs. You can see what services generated how much costs, on which account, in which region and much more with filter options.
There should be a Master / Management account if they are using AWS Organizations, and this will be able to see all child accounts through the AWS Cost Explorer Ausgefuchster mentioned.
I run a small research group at a large university that manages hundreds of GCP accounts. The university acts as the Billing Administrator, and my research group was assigned a GCP "project" for all of our work. However, for privacy reasons, they cannot give me access to the Billing API because this would allow me to see the billing details for other labs.
Because we have trainees in our lab who WILL make mistakes, I would like to setup an automated system that monitors our current GCP bill, and (1) sends notifications or (2) terminates all VMs, when that bill reaches certain predefined limits. For example, if our monthly budget is $10k, then I would like to receive a notification at $5k, another notification at $10k, and I would like to terminate all VMs at $15k.
My problem is that in order to implement a system like this, I need access to the Billing API. I have already contacted my system administrator and they have said that this is impossible. Instead, they proposed that I write a script that lists all VMs and uses the Cost Calculator to estimate my monthly GCP bill.
However, this seems a little circuitous. When I am using the Google Cloud Console, I can see the total and forecasted costs for my project, so it seems that I should be able to access this information programmatically. However, I cannot find any information on how to do this, since all solutions require me to activate the Billing API. Any ideas?
There is no API to fetch the data you see in the Google Cloud Console. You will need to export the billing data and then process each row of data to generate reports.
There are two options that I can think of:
Option 1) Ask the admin to set up billing data export to BigQuery. Grant you permission to query the billing tables. You can then query BiGQuery to generate your own cost reports.
Set up Cloud Billing data export to BigQuery
Option 2) Create a separate billing account for your project and grant you permission. A GCP ORG can have multiple Billing Accounts tied to the same Payments Account. This option supports creating budget alerts.
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
We are in the process of transferring what we currently have in our on-premises infrastructure to the cloud and taking advantage of what AWS has to offer. We are in the process of planning how we can make this process as smooth as possible, so one of the first things that came to mind was, What are the best possible solutions to implement what we currently have in our premises with users registered in AD and how we will be able to manage them, e.g. we create a new user in AD and automatically we can see that new user in our AWS environment so we don't have to manage them on premises as well as AWS and so they can sync?
The next question which I think the answer is Control Tower (and that's why I'm sending my question on this topic), but I would like to confirm and see if there are any other options out there that we might me missing.
As I said earlier, we are in the process of transferring our current on-site infrastructure to the cloud, so at this time we have three environments where we manage development: Development, Staging and Production. We thought of having each of them separated in their own AWS account so we can manage them individually but also we want a way to easy switch accounts between them and possibly get one consolidated bill for all of those three accounts but with the details in each account, and be able to easily make them communicate resources in one account to resources in another account. What would be the best solution for these challenges in AWS if someone can suggest best practices on these?
Thank you so much for your help!
For the AD connection, you can use the AWS AD Connector service. The official AWS blog has a tutorial: https://aws.amazon.com/blogs/security/how-to-connect-your-on-premises-active-directory-to-aws-using-ad-connector/
Billing for a multi-account organization is pretty straightforward, all sub-accounts pay through the root account so you won't have to worry about separation of billing.
Communicating between the environments (accounts), however, requires a bit more legwork. You can use a hub and spoke model and reach out to all environments from an individual environment, or, you can create trust relationships between roles and resources via IAM policy in different accounts and map them to one another.