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
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.
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.
In our team, we are using AWS as our main cloud provider and currently, we have 3 projects hosted on their platform.
We are about to have 2 more projects in the next weeks, but first, we want to organize our projects, because our current organization is a little bit disordered.
We want our projects to be organized following these rules:
Each project must have a staging and production environment.
Each project is independent of each other so that it is not possible to see the resources of a project from within another project, i.e., VPC and S3 Buckets.
The client is responsible for paying the bills of the project (staging and production environment).
Even though the client is responsible for paying the bills, we must have access to the environments to deploy our code and to do other tasks related to development, testing, and operations.
We can assign a team of developers to each project. It should be possible for a developer to be in one or more projects at the same time. Plus, it should be possible to move our developers between projects and to remove their access from a project.
So, is it possible to organize projects in AWS under the rules previously mentioned?
If so, what are good resources to learn how to do this?
If not, what cloud providers allow to organize projects the way we want?
Thanks for your attention and time. I'm looking forward to your replies.
The fact that you want project-specific charges to go to customers and you want each project to be independent indicates that your best choice would be to use a separate AWS Account for each project (or each client).
By keeping projects in separate AWS accounts:
Each account will only have costs associated with a particular project
Resources in each account will be kept separate
User permissions in each account will be kept separate
You can create staging and production environments within the same account (see below)
You can have multiple accounts joined together by using AWS Organizations:
AWS Organizations is an account management service that enables you to consolidate multiple AWS accounts into an organization that you create and centrally manage. AWS Organizations includes account management and consolidated billing capabilities that enable you to better meet the budgetary, security, and compliance needs of your business. As an administrator of an organization, you can create accounts in your organization and invite existing accounts to join the organization.
Some companies go one step further and also keep staging and production in separate AWS accounts. They do this because they wish to keep production resources and users away from non-production resources and users. This reduces the chance of somebody accidentally changing Production when they meant to update Staging. While you can use IAM permissions to reduce such a thing from happening, keeping staging and production in separate accounts guarantees that people with only staging permissions will not be able to impact production.
Your company should maintain ownership of all of the accounts so that you can manage and control them. Each month, you will receive a consolidated bill, but it will show costs broken down by account. Thus, you will know how much to charge your clients.
The developers will need separate logins to each AWS account. So, if they wish to work on Project 1, they will need to login to the AWS account for Project 1. They then have access to the resources in Project 1, but not any of the other projects. When they wish to work on another project, they will need to re-login with credentials for the other project's AWS account. You might think that this adds extra work, but it also adds extra security and ensures that each client's resources are kept totally separate.
A final benefit of using separate accounts is that, in future, if a client wishes to take control of their systems, you can assign the AWS account to them without having to do any work to separate their resources from other clients. It is like handing over the keys of a house — they can move in without anyone having to move out.
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.
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/