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.
Related
Dear AWS and Cloud Gurus,
I am tasked with the design of a new AWS account structure that is to serve as a development and runtime environment for multiple development teams. The goal here is that multiple individual teams can work on different projects, each in their own AWS account but make use of some shared services and inherit certain elements from a top-level account.
An example for a shared service inherited from the top-level account would be billing. An example for a shared service on the same hierarchy would be authentication and authorisation services.
The projects the different teams work on are all accessible in the end through a unified platform / portal. The user logs onto that portal and can then execute different functions or even start complete applications which are actually developed by the different teams in their respective account.
Now my question is this: What would be a best practise approach on this? Should all teams work in a shared repository, or should each have their own code repository in their own account? Shall the deployment be done into a central account or should the teams deploy within their own account and the app is called from the portal from this account then?
I will try to picture this:
As you can see, there are essentially 5 different AWS Accounts:
The root/masdter Account holds the billing information and also allows for central administration of quotas
Then there are 4 AWS Accounts each with it's own Code Repository and independent access points. 3 of these hold different applications (developed as SPAs) while the forth provides a central navigation page (aka Dashboard) and also provides SSO to the other applications.
Is this setup feasible, given there are different, independent application development teams involved but the applications they provide are in the very end used from a central platform for the end user? How would you go about this?
With the kindest regards,
Chris
I have a client with an AWS account already supporting an existing production environment. They've contracted with us to build a new and large ecosystem of software but do not want to give us administrative control of their existing account. The solution we're going with to solve this is an AWS Organization and a new AWS Account for this new software.
My question is, will logging into their existing AWS Account and creating a new Organization be disruptive to existing production systems? I'm sure the answer is no, but I want to be validated beforehand.
Of course if we create SCPs and OUs we can disrupt services but I'm just asking about the act of creating the Organization.
I've done a ton of looking and even asked someone with several AWS certifications that wasn't sure of this so I hope someone here can provide some info on this
Thanks
Well, I can't say for sure if it will be disruptive for someone else, but as expected, for us at least, there were no production interruptions from creating an Organization (without any OUs and SCPs) and then adding a new AWS Account under that organization.
For context, our client has a few EC2 instances running, an RDS database of some type and some SQS queues among other services in their account.
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.
We are developing a custom application, API architecture, related services and processes, based on a LAMP stack and all relevant AWS services: Elastic Beanstalk, EC2, S3, ELB, RDS, API Gateway, Lambda, SNS etc. We would propose to manage the app and all related infrastructure for a flat monthly rate to our client base. We would handle all payment details with Amazon directly for all clients. We are essentially building out a multi-tenant application on AWS. We want to be able to service the AWS infrastructure for potentially 1000s of accounts/clients.
Here is the question: What are the pros/cons of:
Option A) hosting all services in a single AWS account using carefully structured IAM roles, users, and permissions, and co-mingling customer data while insuring logical and secure separation of customer data within the account?
- VS -
Option B) creating a unique AWS for each account each client, and manage each account via a local profile. In this approach, all data is fully segregated, but we have to manage common activities (user management, code deployment, operations) across 100s of discrete accounts. There is a data security advantage, but it is feasible to manage that many accounts? Any tools or processes for doing it this way? Each company technician would need a login across every account.
The isolation of option B improves security for each client, as any potential security breach would be limited to a single account. But would code deployments be a nightmare? But what about configuration management?
Is there an account federation service that would help manage option B? Or am I nuts for even considering option B?
Lots to think about, but IMO, in this instance, security trumps all other concerns and that would make me choose option B with the little I know about your setup.
Just think what would happen to your business if the 'master' account was compromised - by a hacker (internal or external) - your clients would be running for the door.
Having lots of accounts to manage is an obstacle, but if treat your infrastructure as code, your code-deployments and everything else can be automated - with 1000s of accounts you will have no choice but to put those systems in place.