To give some background here, my company has not implemented AWS Organizations. We have this problem where many of the same environments (accounts): Prod, Dev, and QA all have the same policies and users. When one policy is updated in one environment, we must either manually go into the others or run a script depending on what's being done.
Is this one of the use cases for AWS Organization? We can update one central policy and "append" that policy to the Units? If this is not the exact usage of AWS Organization, is there another way we can duplicate this action without the need to interface with the AWS API?
Thanks!
For anyone stumbling upon this question now, we now leverage AWS Control Tower for this.
Related
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.
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 have two AWS account say as Dev and Prod. In Dev account,our code build,code-pipelines and Code-deploy services is configured with S3. However, In Prod account an auto-scaling group is running for the production websites.
As per our requirement, We want to deploy the code from dev account to Prod account with cross-account deployment. Basically, The code-build and code-pipelines will execute the code and by using code-deployment it will deploy in the Prod account's Auto-scaling group.
Can someone give us some insight about to achieve the same.
Thanks
CodePipeline supports cross-account actions, however it's not currently configurable via the console and requires some extra roles to be configured.
Here's a guide on how to make it work: https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-create-cross-account.html
As of today, CodeDeploy doesn't support cross-account deployments. Depending on what your goal is, you might be able to achieve it another way.
I want to deploy a bundle in one account to another account
If your S3 bucket allows access to the second account, CodeDeploy doesn't care what account your bundle is in as long as everything can access it. Per #TimB, it looks like CodePipelines can support that behavior.
I need to initiate a deployment in one account to another
If you have a reason why the deployment must be in one account to another, you could set up the instances in the second account to be on-premise instances, though this is not a great solution.
I'm looking for way to restrict deployment to production assuming I'm not using multiple accounts for dev and prod.
My use case would go as follow (I still not sure if this is possible, pls help me on that). I want to create multiple users into a same account but allow only one user/group to exec commands like sls deploy -s prod and maybe, allow only that user/group to be the only able to create sources name prod_{name}, for example, dynamo tables name prod_users.
Is this possible? or the only way to separate concern is thought the consolidate billing and multiple accounts?
Thanks!
By default, users don't have any privileges, so you have to explicitly allow them to do something on AWS.
Simplest way to do that is to go to IAM console and create group for users that are allowed to do what you require. After naming group, next step in IAM console is to attach policy to the group. In that step, you would choose CloudFormation, EC2, RDS, ElasticBeanstalk, and whatever services you want them to access. For each service, you can choose more granulary (read, access, admin, ...). You can either choose from AWS predesigned policies, or create one of your own, if it's so specific that it isn't covered by already existing policies.
I'd like to help you further (ie. tell you what policies to include), but for that I'd need to know specific types of users and services that you want covered.
Regards,
We have multiple AWS accounts (about 15-20), one AWS account per client that we are managing, each account having VPC having dedicated setup of instances. Due to regulatory requirements all accounts needs to be isolated from each other.
What is the best way to manage account credentials for these AWS accounts? Following is what I am thinking
-For any new client
Create a new AWS account
Create AWS IAM roles (admin, developer,
tester) for newly created account using cloudformation
Using master
AWS account, assume roles created in step 2 to access other
accounts.
Is this the right approact to manage multiple accounts?
Thanks in advance.
Facilitating IAM Roles is a very common and (I think) the right approach to manage authentication for multiple accounts indeed, AWS has just recently released resp. updates that greatly help with this, see Cross-Account Access in the AWS Management Console:
Many AWS customers use separate AWS accounts (usually in conjunction with Consolidated Billing) for their development and production resources. This separation allows them to cleanly separate different types of resources and can also provide some security benefits.
Today we are making it easier for you to work productively within a multi-account (or multi-role) AWS environment by making it easy for you to switch roles within the AWS Management Console. You can now sign in to the console as an IAM user or via federated Single Sign-On and then switch the console to manage another account without having to enter (or remember) another user name and password.
Please note that this doesn't just work for the AWS Management Console, but also with the AWS Command Line Interface (AWS CLI), as greatly explored/explained in by Mitch Garnaat in Switching Roles in the AWS Management Console and AWSCLI.
Furthermore, Mitch has followed up with a dedicated new tool 'rolemodel' to help with setting things up pretty much like you outlined, which you might want to evaluate accordingly:
Rolemodel is a command line tool that helps you set up and maintain cross-account IAM roles for the purpose of using them in the new switch role capability of the AWS management console. These same cross-account roles can also be used with the AWSCLI as described here.