AWS re:Inforce 2019: Managing Multi-Account AWS Environments Using AWS Organizations (FND314)

all right good morning can everyone hear me okay cool this is such an interesting setup it's my first time doing one of these so I've been talking to some folks and they said that it's also a little bit it was a little bit different for them too so we'll go through this experience together although I'm sure you've already been through it on Tuesday as well as on Wednesday cool so my name is Ray I'm a senior product manager here on the AWS identity team specifically covering AWS organizations and AWS accounts and for the next hour or so we're going to be talking about managing governing multi account AWS environments using AWS organizations so to give a little bit of an overview of what we're going to cover in the next hour the first thing we're going to talk about a little bit is what are AWS accounts because sort of the definition and how customers are using those has evolved a little bit over time so we'll baseline a little bit on that we'll talk about why you should be using a multi account AWS environment as a best practice will introduce AWS organizations as a service and talk about and then talk about the advanced management and governance capabilities that you're able to get in AWS organizations to the degree that we can do audience participation here if I could see a show of hands how many folks are currently using AWS organizations today in their company or for those stem cells okay and how many people aren't using AWS organizations if you wouldn't mind raising your hand awesome the folks that have their hands just up right now if you wouldn't mind leaving them up real quick and of those folks how many of you do manage multiple accounts and get a single bill at the end of the month if you would keep them up everybody else put them down okay cool all right thanks everyone awesome cool before we get started there were a couple of related breakouts that I wanted to point you to the first one unfortunately happened just before this so if you were on the red stage on 9:30 then you probably saw it which was talking about using analytics to set access control controls an AWS the nice thing is all of these talks will be on YouTube after 24 hours so if you missed it I definitely would go ahead and check that out there's another talk coming up at 2:00 p.m. on enforcing security invariants in AWS organizations this is being presented by Becky Weiss who's a senior principal engineer here at AWS and I definitely would recommend going to see that talk she's a fantastic speaker but if you're not able to that will also be available on YouTube and finally another feature that we launched recently on Monday actually is a feature called service quotas and so there may be a seed or two left in a breakout session on viewing and managing your AWS service quotas or limits and so that's from 3:30 to 4:30 in the breakout room and so if that's something that you're interested in we'll give a little bit of overview on that as well but if that's something that you're interested in you may be able to still find a standby seat for that session cool and so the first thing that we're going to talk about is what is an AWS account and so when AWS started over a decade ago it started with one customer having a single account with the email address and password and they were able to log into this account launch the resources for their applications and they were perfectly fine and happy over time enterprises and other companies discovered that this model of an account per person didn't quite fit within their business use cases they were discovering that an application had projects in them which meant multiple people were accessing them and so over time the concept of an AWS account has evolved today when we think about an AWS account we consider them as compartments for AWS resources so those are things like Amazon s3 buckets ec2 instances or dime ODB databases and you control access to these resources using AWS Identity and Access Management principles which are users and roles and so how I describe using a single account environment versus multi multiple account environments is this so say for example on the left side I've got a container with sporting equipment in it and so I've got my trophies my football equipment baseball equipment and soccer and so if I'm trying to go look for all of my trophy equipment or all of my trophies it's gonna be really hard to find and retrieve the trophies because I have to dig through all of the other sporting equipment that I have a better model is to categorize each of these types of equipment into its own container and so here on the right side I now have my trophies in a container football equipment baseball and soccer and their own containers so if I'm looking for my trophies I can just go straight to the trophy container and you could think of this the same way with your AWS accounts and that if you're looking for specific types of resources they've already been categorized into their own container and so why you should be using multiple accounts the first one is you can group your resources for categorization and discovery this enables you to very easily find all of the resources for a particular application or workload because they'll all be sitting together in a single AWS account you can improve your security posture with the logical boundary and so you can create a logic AWS account per application so you have for example your development account your pre-production account and your product count and the resources use for those different environments are logically separated into separate AWS accounts you can limit the blast radius in case of unauthorized access so for example if an unfortunate thing were to happen and one of your accounts were potentially not potentially compromised the only thing that the compromiser will be able to do would be to affect the resources that are currently sitting in that account and so you can make sure that you protect the rest of your business with that logical isolation boundary and finally it's more easy to manage user access to different environments so previously if you're operating all of this in one account for me ray if you need to give me access to specific project resources we'll have to start listing out all of the resources that I need access to and so if you need to add additional access for me for new resources you have to go and do that manually but with an account with all of your resources segmented into different accounts now what you can do is just to save ray has access to these AWS accounts and you know that all of the resources for the projects that I need to work on are inside of those accounts automatically and so I was talking to a customer recently and I heard this really good quote about how you should think about categorizing your stuff into different accounts and so the quote was if Team A can't support team B's application when they're paged in at 2:00 in the morning then it's a probably a strong indicator that those resources or applications shouldn't be sharing the same account and so this way you can segment out those application workloads into multiple accounts and ensure that the team's again have access to only the resources that they need access to and so that brings us to the topic of the presentation which is I've got all of these AWS accounts with all of my different applications I need a way to centrally manage all of these and so that brings us to AWS organizations which is our service for providing central governance and management across AWS accounts so within AWS organizations we provide you with a couple of key feature areas the first one is the ability to manage and define your organization accounts we allow you to centrally control access and permissions we allow you to audit monitor and secure your environments for compliance share resources across accounts and then centrally manage costs and billing across all of the accounts that you control a common question that I get asked a lot is what's the difference between AWS organizations in AWS control tower which is a brand new service that just hit general availability on Monday and so the way we like to think about it is a dub use control tower provides a well automated setup of a secure well architected environment and it actually abstracts multiple AWS services including AWS organizations and so we'd recommend you to use control tower if you're looking for automated deployment of a multi account environment with AWS best practices one caveat though is today control tower needs to be deployed on a new environment that doesn't already have a to be s organizations so if you're already using AWS organizations you're gonna either need to start a new environment deployment or stick with just using organizations and so organizations we'd recommend it's best suited if you want to define your own custom multi account environment and use all of the advanced management and governance capabilities that we provide through the service and so there's no right or wrong service to use it all really depends on your specific business use case and what level of automation that you want to be engaged with the other question that customers ask me all the time is migrating from consolidated billing organizations to all features organizations so for those of you that kept your hands raised that said that you weren't using organizations but received a consolidated bill for multiple accounts earlier will surprise you're actually using AWS organizations behind the scenes this is a legacy mode of organizations that only provides you with the billing features and so if you want to take advantage of all of the advanced management and governance capabilities available within organizations you're going to have to migrate your organization and so a lot of customers come to me concerned that during that migration process something will change to their organization and I want to assure you that no changes occur to your organization when you migrate it from the legacy mode to the full features mode and the way I like to describe what that migration process looks like the customers is this today your organization you're looking down a hallway and there are a set of doors and today you only have keys to unlock one of the doors and the rest of the doors are currently locked so when you migrate your organization to all features all we do is to give you a set of keys to allow you to unlock the other functionality available within the service but you don't have to enable them and the doors don't automatically open or get enabled until the time in which you choose to do so and so you can look at our list of capabilities and decide maybe I want to use one of the advanced management capabilities today or I want to go ahead and enable all of them and turn them all on but they don't turn on automatically when you first migrate over it's completely up to you to decide which capabilities are suited for your business the next thing that I want to talk about is an account strategy with AWS organizations but before we do that I want to sort of level set so that we're on the same playing field on a couple of terms that we use when were describing organizations the first one is the organization which is all of the accounts that you currently managing and control and one in your organization and you have the AWS account which is the smallest unit of management in an organization and your AWS account can only sit in one organization at a time we have the concept of a master account here denoted by the blue star which is the account that you use to create your AWS organization and also serves as that central consolidated payer that pays for all of the accounts inside of your organization and you use it as a central management and governance hub where you do all of your management activities for the entire organization we have this concept called organizational units or OU's in organizations and it allows you to logically group AWS accounts within an organization we also have the concept of a policy which is a document describing a set of controls that you can apply to a selected set of accounts you can see here I've got the policy as the policy documents we'll go more into sort of how you use policies a little later on in the session so with AWS accounts and organizational units you can first segment your applications and workloads into individual AWS accounts for categorization you can then group these accounts into organizational units to simplify management and to group accounts that are similar together so you can discover them you can create multiple organizational units within your organization and you can also nest these organizational units inside other organizational units to start forming a trio hary hierarchy and so what that looks like is this and so for example here I've got an example organization and I've got a set of high of top-level organizational units here I've got my application services individual information security chin and my infrastructure organizational unit I've got some organizational units nested under as well as accounts in all of these and so this is one example of what we were recommend as a way to structure your to think about structuring your organization for your business so on the left side we've got the application services organizational unit and these are accounts that host resources to support your applications and we've gone ahead and grouped them together so these are the things that provide for example your business to customers and so you can audit and apply security policies including service control policies to this entire group to secure the entire group your individual app or ghen eyes a tional unit is the set of accounts that are owned and access by employees and so some examples of things that you may have here are accounts for sharing business data via s3 trying out new services or you know you've got some engineers building software in their own individual test account so you've got those grouped all together you've got your information security organizational unit which are accounts that provide auditing and remediation access actions across a broad range of accounts and you audit and manage these separately than the rest of your organization we also have an exception organizational unit and over time as you develop your business use cases you may discover some accounts that don't quite fit in with the security grouping and auditing models that you've defined for the rest of your organization so you can group all of these special accounts together to have a customized security stance so you know where they are and then you can go ahead and audit and secure these accounts as required finally I've got my infrastructure organizational unit on the side and this is all the stuff that runs my back-end business and so these are things like DNS build tools code repositories or other internal tools I've got those accounts supporting those workloads all grouped together and so when you think about organizing your service accounts into organizational units there are a couple of questions that you need to think about or you may want to think about the first one is how many business units do you foresee yourself growing into because you want to start with and with the organization design that allows you to scale as your business scales over time you want to think about the commonalities across account guardrails so for example there's a high likelihood that all of your production accounts may require the same type of security policies applied to them so it may make sense to group those together so you can apply the policies across all of those accounts and finally how much can you go ahead and automate grouping similar accounts means that you can then go ahead and perform similar tasks or the same tasks across all of these accounts at one time instead of looking for them in different places to have to run your automation tasks on them independently and so you can see over here I've introduced two different ways in which you can think about grouping your accounts in this case under the application services oh you on the left side we talked about grouping them my business unit so over here I may have Department Y and Department Z and all of the accounts owned by Department Y grouped together and all of the accounts on my department Z grouped together this gives me a really good way of looking at my organization and very quickly seeing all of the accounts that are owned by a particular business unit and all of the accounts are owned by another business unit on the right hand side I've got a second option which is by environment type where you can see I've split my accounts into my production accounts and my development accounts so this is a particularly good way of doing it because now it's a high likelihood that all of my production accounts I'd want to secure them similarly and so I can apply security policies to the entire production group and the same thing with my development accounts I may want to secure them a little differently and I can go ahead and apply security policies to all of those accounts together a couple of other things on food for thought today the organization can be no more than five levels deep and so if you're beginning to architect your organization and you see you see yourself developing an organizational architecture that includes twenty or more levels or a lot of levels there's a high likelihood that you're getting too complex and this is going to end up being extremely difficult to manage in the future what we've discovered talking to customers is that using those broad categories to apply governance and management capabilities across the top and so being a lot easier for them to scale and provides a better experience for them when they think about managing their organization and so today we've got enterprise and other customers that are managing hundreds or in the small thousands of accounts but they're growing all the time and so it's just as important for them to be able to scale the organization as it would be for you and so if you're at the stage in your company's growth where you're starting to model how you will architect the structure of a thousand of accounts we probably recommend you reach out and work with one of our solutions architects because they'll be able to provide you with all of their experience working across a breadth of customers in architecting also and also being able to architect large scale AWS environments and so they can bring that experience to leverage for your business the next section that I want to talk about is all of the capabilities available within AWS organizations the first group of capabilities is being able to manage and define your organization and accounts and so with in AWS organizations we enable you to create new AWS accounts programmatically so now you can spin up AWS accounts using the console the CLI or the API and these accounts automatically get created inside of your organization and you can start using them right away we enable you to group accounts into OU's for management and I just talked about ways in which you can think about beginning to structure your organization using AWS CloudFormation stack sets you can centrally provision accounts within your organization and you can a provision these accounts to your specifications and then update multiple accounts at the same time if you decide to change your provisioning and so you can define these define these configurations centrally and then have them deployed out to accounts in your organization all in one go some new functionality that we just recently launched about a couple weeks ago we announced the ability to tag AWS accounts in your organization and so now you can attach additional metadata such as who a project who a project what the project of this account is or who the owner of this account is to the account itself so now you can use these additionally for additional categorized categorization and grouping capabilities additionally as of Monday we announced new feet a new feature that allows you to manage service quotas for new accounts using AWS service quotas and so using a predefined quota request template new accounts that you request in your organization can automatically get quota quota increases automatically requested for those accounts so that as soon as that account spins up it's already well on its journey to be provisioned in terms of quotas the same way as your existing production accounts and so what that template looks like is something like this and so over on the left side I can go ahead and select the region for the quota increase request the service and the quota so you can see over here my template I've added three different quotas for my production account I want 1337 ACM certificates I want 10 M for 16 X large instances for ec2 and I want to make sure that the managed policies / role in this account are 20 and so when I create a new AWS account in my organization these limit increased requests get automatically submitted and then once those get accepted then you'll be able to start using your account with those limit with those quotas faster and so if you're interested in learning more about this new service I highly recommend you go and check out its new console page it's just console dot aws.amazon.com slash service quotas play around with it the service goes a lot beyond just what's provide what the organization capabilities is using the service you can also view and see how close you are to hitting certain quotas as well as aah as well as requesting additional quota limiting quota increases through the service itself so I'd definitely check that out within organizations we also provide you with the ability to control access and permissions within your organization and so one of the cool features available is that you can now deploy consul and CLI access to accounts for your employees all from a single location using AWS single sign-on and so how that works is with AWS single sign-on you go ahead and enable the service you can connect it to your existing identity store whether that's manage Active Directory using AWS directory services 8 using a t-connector you can connect to an on-prem Active Directory or you can use the default directory built into the AWS single sign-on service you enable the service to have access to your organization so it can go ahead and perform actions on your behalf and then you're able to manage your user permissions centrally and so now if I'm trying to say Rea me I need access to this set of accounts all you have to say is Rea out of my identity store needs access to these accounts and I wanted to grant him these set of permissions in these accounts and AW a single sign-on will deploy all of that on the back end for you so me as an end user all I have to do is go to a login page I can log in see all of the list of AWS accounts that I have the ability that to log into and one-click button I'm in the console or I can go ahead and copy command line interface credentials to use in the CLI if say for example I need access to more accounts or the vice versa I'm done with the project and access needs to be taken away from me all you have to do is to go to the central location change the accounts that I have access to or modify my permissions in AWS at single sign-on will automatically provision that for you so you can see as you scale to more and more employees this becomes extremely helpful because now you only have to go to one place instead of accessing every single account in order to deploy those permissions for your users additionally we enable you to define permissions based on membership inside of an organization using the AWS principle org ID condition key and so a good example of that is say for example I've got an Amazon s3 bucket that I only want users inside my organization to be able to put objects into and so now I can write an s3 bucket policy that looks like this and you can see over here I specified the condition of string equals principle org ID with the organization ID of my organization and so now if somebody now the only people that are allowed to put resources into my s3 bucket are those that are already members of my organization this context key or this conditional contact condition key can be used in other places as well across iam policies additionally within organizations one of our flagship features is the ability to author find grade and permission guardrails across accounts using service control policies and what was recently announced back in March is service control policies now support resource and conditional elements in the policies which gives you even more control over the permission guardrails that you're authoring and so to dive a little bit deeper into service control policies we've got this information here so service control policies define the maximum available permissions for I am entities in an account but it's important to note that service control policies don't grant permissions to users so service control policies work in conjunction with the IAM permission policies attached directly to your users and roles and basically provide the information of exactly what a user is allowed to do so with the service control policy it provides the outer boundary of anything that can be done in the account the iam permission says what me as an individual user can do in an account and the my ability to do work is the intersection of those two and we'll talk about that a little later on I can attach service control policies to the organization route organizational units and individual accounts as you see here so I've got a policy attached to the top of my organization which affects all accounts a policy attached to information security which governs everything underneath it and then a policy specifically attached to account five over there that provides additional guardrails specifically for that account and I can also apply these policies across my organization as they see fit in relation to my business use cases and so with service control policies here's an example of how that functions together so on the left hand side I've defined a service control policy on an account that grants me access to ec2 and s3 am i I am permissions for me as a user says Ray has access to ec2 and SQS and so if I'm sitting in account that these both apply to the resulting permissions is the intersection of those two policies and so the only thing that I will be allowed to do is ec2 because that's the only service that's been defined in the service control policy as well as in my specific I am permissions of what I'm allowed to do in that account so for authoring service control policies you've got two different options in the path that you want to pursue and they both have their own use cases the first one is a whitelist policy where you only allow specific actions and so in this case I've written a policy that says I want to allow ec2 directory service and s3 and so the only services that users in my account no matter if they're signed in with the root credentials or they have an administrator policy with star star attached to them they're only going to be allowed to use the service ec2 directory service and s3 a good example of customers that have successfully used these whitelist policies are those that are trying to ensure for example if they're in the healthcare based that their users are only using the services that are already validated as being HIPAA compliant so they can they can ensure that their users aren't launching anything that's not HIPAA compliant in their organization a thing to note though is that resource and conditionals are only supported on the deny statements today so if you want that additional level of granularity you'll have to write blacklist policies for your organization so with the blacklist policy it blocks specific actions that you don't want users to perform in your organization while granting your users at least in the permission guardrail potentially the ability to access all other services and so in this particular policy I basically written a deny policy that says I want to deny the ability for cus customers or my end users to leave the organization of the account that they're in to remove the account from the organization as well as the ability to terminate ec2 instances in my org and so an example where this policy might be a good place to attach is if you have say for example production accounts where you want to make sure that that production account doesn't walk off on you whether by accident or on purpose and you want to make sure that the ec2 instances that are running your business aren't accidentally shut down by somebody calling an API command in the wrong account you can apply this policy to your production workflows to ensure that those actions aren't performed and so the caveat to mention with the blacklist policy is you also require an allow star policy to avoid denying access to all services so the way the policy language is evaluated is an explicit and I trumps everything followed by an implicit deny where something's not listed followed by an explicit allow so if I don't explicitly allow the services that I'm not trying to deny they'll automatically be implicitly denied by default and that could have an impact on your end-users so make sure to double check that when you're writing a blacklist policy by default when you turn on service control policies an allow star star policy or a full access policy is already attached to every node in your organization to ensure that when you initially turn on service control policies it does it doesn't automatically shut down your organization at the point in time when you enable those policies so if you want to go ahead and use the whitelist policy you'll go ahead and swap those policies out for your individual and customize a lob policy and for the blacklist policy you can just go ahead and write your specific denies because that allows start policy already exists for your convenience let's talk about a couple more complex use cases for service control policies that are correct that are directly tied to customer use cases that we worked with so over here for example I've written a policy that denies access to AWS based on the requested region and so an example of where you would use this policy is to ensure that accounts can only launch resources in the AWS s European region so you can have improved compliance with gdpr regulations so over here the important part about this policy is that I've written that deny star if string not equals the requested region of EU central 1 and EU west 1 and so now when I try to launch anything outside of those two regions I will automatically get denied an important thing to note is I also have a not action here with a couple of services listed including I am organization's route 53 cloud front and support these services are what we consider Global Services and are based out of u.s. East one so if you didn't include this non-action your ability to use those services would be impacted and so that not action is there to ensure that those services will continue to run in the accounts that this policy is applied to this isn't a comprehensive list of all of the global all of the global services that we have so make sure to double check what if you're writing a policy like this that the services that you need access to aren't currently being blocked by not being included in this policy on the second set of policies here I've written a policy service control policy to prevent I M principles from making changes to a common administrative IM role so this is really powerful say for example you're a central IT administrator and you want an administrative role in all of the accounts in your organization so you can log in to provide management or auditing there's a likelihood that if there is a user in that account that has access to iam they can potentially change something related to that role so that you would not be able to access it or your access may be impacted and so this service control policy ensures that that administrative role that you have isn't able to be changed at the local level even by the root use by the root credentials and so over here you can see I've denied a set of iam permissions that I don't want to be modified and I've specified the resource as being with the star any role that is defined as AWS - administrator - role and I can attach this to the root of my organization and ensure that all accounts are automatically protected for the role that I have for administration the second group of capabilities that we have in organizations is the ability to audit monitor and secure your environments so you can aggregate AWS config data in a central location for compliance and auditing of your accounts you can centrally create provision and modify web application firewalls to secure your applications using web application AWS firewall manager you can accept business agreements for all of the accounts in your organization using AWS artifact you can allow organization wide notification publishing using a Debus cloud watch events so with AWS cloud watch events it's what we consider organizations aware so now in space instead of specifying all the accounts that can write to a central event bus you can now just specify the org ID and automatically grant permissions for any account in your organization to automatically right to that centralized event bus it makes it a lot simpler but you do still have to setup the actions in the individual individual accounts to write to that event bus but it simplifies the process of not having to list out every single account that you want to grant permissions to and finally we enable you to centrally enable audit logging using AWS cloud trail which I want to go into a little bit further so with the AWS cloud drone organizations you can ensure that all of your AWS acts a double US accounts have audit logging enabled centrally this also includes new accounts that join your organization will automatically get cloud trail provision on them as soon as they join your organization a big thing about this is you can prevent your auditing from being modified in an account because it's a centrally managed resource an end-user in the account no matter what permissions have they have can't go ahead and delete or modify or turn off logging in that account so you can ensure that your audit logs are always comprehensive and finally you can have all your audit logs consolidated in one place in a single bucket and you can even query off of the central bucket using AWS athena so now you can write queries against the information that's stored in your audit log bucket which is super cool and so I want to show you how easy it is to set up an organization an organization trail using the CLI so the first thing that I need to do is to create my s3 bucket for storing logs inside and securing it it's a little bit long to talk about the bucket policy that you need to do and the s3 policy sorry and and creating the s3 bucket but we've got great documentation here for you on our AWS documentation so there is a link that I have on the slide if you want to take a photo this presentation will also be available on YouTube as well as these raw deck slides will also be available on SlideShare if you don't get a chance to take it or you don't want to type that whole thing in that will all be available for you as a hyperlink wait a few moments I see a couple people still taking photos cool so now that I've created my Amazon s3 bucket and my bucket policy I'm ready to start creating my organization trail the first thing I want to do is to make sure that all features is enabled in my organization if you remember what I talked about previously there are there's a legacy mode and then the full-featured mode of organizations so in order to use this functionality you need to be in that full-featured mode for organizations so I run the CLI command and I get an error which says that all features is already enabled on my organization so I'm good to go so now the next thing that I want to do is I need to give cloud trail the ability to perform actions within my organization so I need to extend that trust to cloud trail and so what I want to do is to run the next command which enables AWS service access for cloud trail I go ahead and run that and it runs successfully and so now I'm all set up and ready to create my organization trail and so I would call to create trail you can see a couple things here I've supplied the name of the trail I want to create which is Ray SMA organization trail demo supplied the name of the s3 bucket that I created previously which is Ray SMA organization trail demo as well and I've specified a couple of parameters that say that this is an organization trail and it is a multi region trail because I want to turn this on for all regions in all accounts in my organization I go ahead and run the CLI command and it comes back with some information you can see here the name that I described has been returned to me I'm given the name of the trail horn and it's a multi region trail and there's the name of the s3 bucket that it's currently being written to so now I've created my organization trail but there's that one final step that's probably the most important part is that I need to turn this trail on so that login will start so I go ahead and call the start logging command supply the name of my organization trail arm and then press GO and you can see here I've called the command it was successful and now logging is being provided across my organization so I can go ahead and validate that that has been turned on in my organization by navigating over to the console but you can also call the CLI command but here in the console you can see that I've got my trail name Ray SMA organization trail demo it's turned on in all regions it's an organization trail I can see the s3 bucket that it's writing to and a status is good to go which means I've successfully set up the organization trail if you're already doing multi account logging in your existing organizations you can set up this organization trail alongside the one that you already have and so they can live together until which point you decide to cut over or you can keep them running together at the same time and so that's one of the cool things about this feature the next place where we provide you with functionality is the ability to share resources across accounts in your organization and so now you can centrally define critical resources and make them available to all of the accounts in your organization that are logically isolated we provide you with functionality through manage Active Directory so now you can authenticate against your central identity store for applications that are deployed in other accounts an example of this is being able to do a seamless domain join for ec2 instances that are sitting in any number of accounts in your organization with AWS Service Catalog which is new we allow you to centrally manage catalogs and provision them centrally and ensure that users in all of the individual accounts in your organization have access to the software that they require to do their business you can also centrally change these catalogs as well as deploy new catalogs all from a central location and have them show up in the accounts in your organization and finally using a service called Amazon resource access manager you can share resources such as VPC transit gateway and subnets license manager configurations and route 53 resolver rules so an example of where you would use resource access manager is ensuring application resources across your accounts are created on your Amazon virtual private cloud VPC subnets by centrally defining your subnets and then sharing them with all of the accounts in your organization so you can ensure that the same subnet is be is made available in all of your accounts and so I'd like to talk a little bit more about resource access manager and how easy it is to use to share resources so the first thing that I need to do is to create a resource share so I provide a name of my resource share which is organizations demo license share I go ahead and choose a license configuration this is the thing that I want to share my license configuration and I go ahead and select that as the resource for resource access manager the next thing is I can go ahead and select what entities in my account I want to be able to share it with and so in this case I'm selecting my entire organization because I want my entire organization to have access to this license manager configuration but I can just as well select certain oh use in my organization as well as individual accounts to share it with in my work and so once I hit share you can see here that my resource share has been created organizations demo license share with the ID the owner is the account that I'm in and I'm don't allow external accounts to access it and the status is active and so when I login to one of the member accounts of my organization I can see here that resources that have been shared with my account include the one that I just created and the owner account is the account of the of the management account that I use to create this and additionally if I go into license manager I can see the resource that got shared with me the demo license configuration available in license manager as if that resource was sitting in this account itself and so as an end user it's completely seamless for me to be able to access those resources that I need to run my day-to-day business as well as as an administrator you're able to centrally manage and control what is being shared across your organization all from a single place the last area that we provide capabilities in is being able to centrally manage costs and billing across your organization you're able to consolidate usage across all of your accounts in a single bill and so at the end of the month all of your accounts are grouped together for our i sharing volume discounts and enterprise discount programs if you have them they or edp's you can manage your tax settings across accounts from a central tax console so you can set the tax information for all your accounts in your organization at the same time and finally you can gain insights and manage spending across your organization using AWS budgets and AWS cost Explorer and so an example of what you can do with AWS cost Explorer with your organization is I've built a graph here that it enables me to view the monthly cost by member account of my organization so each one of these individual lines is the recorded spend for an account in my organization and I can use this graph to see how the trends have spen are changing for accounts of my organization as well as to identify and respond to Peaks and spending for my organization up excuse me for accounts in my organization you can build a whole bunch of different graphs with AWS cost Explorer so if you haven't already taken a look at the insights that it can provide I'd recommend you go and check it out as well and so finally to recap what we talked about over the last hour AWS organizations enables you to group your workloads into multiple containers or accounts so you can have logical separation categorization and have security best practices you can construct your organization to meet your business needs and enable advanced management and governance capabilities across your environment or AWS organization including things like central access management using single sign-on request quota increases for new accounts using service quotas defined security guard rails using service control policies set up organization wide logging using cloud trail or share resources across your organization using AWS resource access manager that's all the content that I have for you guys today so thank you so much for coming out and listening over the last hour if you have questions I know this format is a little different I'll be downstairs right by the stage so you can feel free to come up and ask any QA so my contact information is also on the screen if you have further questions later and please remember to submit your application surveys when you get a chance your feedback is very helpful in improving these sessions thank you

Channel: Amazon Web Services

Views: 41,352

Rating: 4.9551568 out of 5

Keywords: AWS, Amazon Web Services, Cloud, cloud computing, AWS Cloud, AWS re:Inforce, AWS re:Inforce 2019, security, identity, compliance, cloud security, AWS security, cloud security community, learning conference, Detective Controls, Infrastructure Security, Data Protection, Incident Response, Governance, Risk, Compliance, security best practices, The Foundation, AWS re:Inforce 2019 Sessions, Session, FND314, Raymond Ma, 300 - Advanced

Id: fxo67UeeN1A

Length: 46min 51sec (2811 seconds)

Published: Wed Jun 26 2019