 Hi, everyone. All right. So just to make sure there is no feedback. OK, fantastic. All right. So good afternoon, everyone. And first of all, thank you, everyone, for joining the community today. And the topic for the presentation here, basically, is that building an enterprise-grade multi-account AWS environment. So before we begin the presentation, and here is the quick introduction about myself. And I'm Badri. I work for Macking and Financial Services. I myself am a cloud architect or cloud engineer. And I'm one of the AWS Singapore user group leader. I'm myself a community builder. I'm also very passionate towards the cloud and distributed systems in very general. I also wanted to make it clear. So this talk, what I'm delivering here, is on my personal capacity. So any of my opinions, what I express here, is personally on my own, not that of my organization. Yeah? Right. So here is the agenda for this event today. So what we will do, we will start by decoding this multi-AWS accounts with a proper design structure and the management to operate on top of it. And then we look at managing the access control across the distributed AWS accounts. We'll then discuss about managing the network connectivity across the distributed AWS accounts. And finally, we'll conclude this presentation by managing the security detection and assessment across the distributed AWS accounts. Before I dive specifically into this multi-AWS accounts, well, let's just have a quick understanding about why single-AWS account is just not enough. Well, there are a lot of these concerns boiling down to this isolation. Starting with the security, it is difficult to isolate the different parts of your infrastructure. Like, how are we going to write down the IAM policy to identify the respective teams' AWS resources? How are we going to segment different parts of the workload if it is being hosted in the single VPC in the shared environment? Or how are we going to apply a resource policy on top of the S3 buckets, perhaps if you are creating in the common AWS accounts? So it will become increasingly challenging from a security perspective. And it's also very natural that different teams have different compliance and different regulations. And especially in a shared environment, if you're hosting different teams' AWS resources, it will be extremely challenging for you to track, identify, and apply the respective compliance and the regulation on top of it. And it's also very natural that different teams have different governance requirements and different management requirements. And especially in a shared environment, and in a single AWS account, it is again, it's going to be difficult for you to track, identify, and apply that specific governance and management methodologies on those shared resources. And finally, two specific concerns. We also have challenges with the cost. And different teams have different budgets and resources. And the most vast majority of the resources, you can apply the tax and to have the cost managed. And perhaps there are resources like data transfer, but you cannot apply the tax. And you have to be very systematic in terms of allocating the charges to the different teams. And we also have increasingly challenging environment when you operate in the shared AWS account itself. And finally, so you'll also have all this quotas. We have various functional and non-functional limitations on single AWS accounts. And all these constraints, it points us towards this multi AWS account structure. Now, let's try to decode this multi AWS accounts with a proper design structure. And we'll see how to manage those multi AWS accounts, what we create in AWS. And when you're adapting this multi AWS account strategy, the very natural question what you basically have is, how many accounts you basically need. And the truth is basically is that there isn't any hard answer. It really depends on your size and the complexity of your organization. You can go about creating a different AWS accounts for different environments. Say for example, AWS account for Dell, AWS accounts for QA, AWS accounts for Prod. In that way, you have a higher, good segregation between the different resources, different nature of AWS resources in each of those AWS accounts. You can also have different AWS accounts created for each of the team in your organization. So in that way, you have a better cost tracking, better ownership, and better access control, which is dedicated for each of those teams. And you can also have AWS accounts created for each of your project initiatives. And again, that will go about having you with a better cost tracking and better access control, better ownership for that respective project in terms of operating that specific AWS account. And you can also be even more granular, right? So you can go about having this AWS accounts created by application per environment. Say for example, AppA Dev on its own AWS account, AppA QA on its own AWS account, likewise for different applications. And perhaps with this basically approach, it is basically very secure and you have a better cost tracking for each of the applications, better isolation of this AWS resources between different environments for different applications. And you will also have a better ownership and it's also easy to decommission the resources. So when the specific application is not in use, you can go ahead and scrap those resources and close the AWS account. I highlighted in green, not because this is the only valid principle, perhaps this is one of the principle what I practiced in one of my working organizations where security and the ownership and the account release lifecycle of a very priority concern, yeah? Now, boiling down all this multi-accounts what we have just discussed, if you notice like you will be ultimately ending up in two nature of AWS accounts. One, the management account, the please value create all your organization AWS accounts. Another one, what you broadly call it as subordinate accounts or a member accounts, yeah? And in the member accounts, you will be having a two nature of member accounts, one which is of very sad services in nature and another one which is self-contained which is for a specific application use case, yeah? Shared services say for example, networking. Networking is responsible for providing a network connectivity for all the AWS accounts. Security services, logging services, so those are specific things. So, now basically once you decide on your, once you decide on your account principles and once you've put out the solid principles for creating the AWS accounts, the next question what you have to answer is how are you going to group those AWS accounts? So when I say group those AWS accounts, basically is that you try to group your AWS account which are similar in nature and this similar is a very broad word and it's very subjective and it really, it basically is that each of the organization priority, you go ahead and define the similar principle. Say for example, you can group all the dev accounts into one organization unit or you can group all the QA accounts into one organization unit. Perhaps you can also consider grouping dev and QA together into non-pro-organization unit and perhaps it really depends on your maturity and how you want to group those AWS accounts together to apply this organization unit benefits on top of it. So basically is that all this grouping will provide you the benefit of managing these accounts which are similar in nature where you have a better resource segregation and you will have a centralized management on top of those grouping. Perhaps you can easily manage this compliance and governance on all those AWS accounts which are similar in nature. Say for example, you can apply the compliance policies for the specific organization unit which are similar in nature. You can have a better cost management. So when you group those AWS accounts, say for example, dev AWS accounts, so you can easily identify with that specific organization unit what is basically the charge which is consumed for all your dev AWS accounts. So cost management is going to be very simpler and finally it is basically is that you will have an automated resource creation on top of it. So let's say if you're grouping the AWS accounts which are for your dev use cases, perhaps you can automate by taking advantage of this AWS organization unit where you can systematically go ahead and have that resource created when the new account joins your dev organization unit or likewise for different organization unit as well. So it helps you with all this automation when you group those similar accounts together and you can apply all those similar automation what is needed for you to get the job done. So this is one such example like we have practiced in one of my working organizations. Perhaps you can notice that we have a high level categorization of broad and non-prod accounts. And in broad you have two different OUs, one for your accounts which are shared services in nature another one for application accounts which are self-contained in nature and likewise for non-prod. And also you can notice like there are two additional OUs which is for your innovation use cases. Basically is that there are not necessarily that innovation use cases will naturally naturally follows that level of vetting what is needed for your organization AWS accounts recommend or AWS services recommends. So perhaps you can consider providing a bit more flexibility on top of those innovation OUs to isolate that from your rest of your organization and perhaps them to have the flexibility by way of allocating that by way of categorizing them as a separate OU and you can apply all those compliance policies or the innovation related compliance policies on top of it. And likewise suspended OUs. So basically is that the whole idea is once when the specific AWS account or the specific application use cases it's done with its life cycle. You move that to the suspended OU and you apply this resource control policy in a service control policy you explicitly block all the accents what is going to take place in that specific AWS accounts. So this is one such example. So you can apply, you can basically have this thought process in trying to understand what benefits this OU provides and try to group those accounts which are similar in nature which matches your best interest for your organization itself. Now fantastic. So we have decided with this organization structure and how are we going to manage this multi AWS accounts? So one where basically we are very fortunate from the perspective that the level of ambiguity in terms of this multi-account management is greatly reduced unlike other scenarios in AWS where you will be ending up and fighting between SNS, SQS or same services providing the same use cases competing between each other. So but we are fortunate that for this multi-account management the level of ambiguity is greatly reduced, right? So you only have two options. You either use control-tevo or you self-manage this organization AWS accounts. Well, I would basically recommend perhaps if you as an organization which are very small in size and if you don't have any strong opinions right away go ahead and have this control-tevo used, right? Because it handles with all this primitive guardrails which are provided out of the box and it matches with all the best practices and it also helps you with all the automations in terms of providing you with the service catalogs and basically it offloads you all this management over here what is required for your multi AWS account management itself. So whereas the other extreme is self-manage the AWS organization accounts. Why it is really needed, right? So AWS control-tevo it comes up with its own opinions. It comes up with its own opinions when it comes to the primitive guardrails or it comes with its own opinions when it comes to how do you want to have this organization units structured, right? How are you going to group those similar AWS accounts together? So it comes with its own opinion which mostly meets across I would say like a 90% of the needs. Perhaps if you as an organization which are heavily customized, right? Which is basically, you know, fortunately or unfortunately all my working experience we have a heavy customization recommend where we try to do all the lot of account orchestration related activities in terms of like onboarding, creating appropriate IAM roles provisioning all the networking resources to have this connected across your distributed AWS accounts providing a connectivity to your on-prem accounts or providing a DevOps related accesses. So this sort of customization which not necessarily meets the control-tevo out of the box provided solution. So for such use cases you can consider using your self-managed way of doing that AWS automation accounts, yeah? Perhaps one of the things is like, you know, if you already have hundreds of AWS accounts, right? And you have self-managing perhaps you already have a well-established process. So migration effort might not be worth it, right? So if you're moving to control-tevo by the time itself. So with this, we will be moving on and once you have this, once you basically establish this multi AWS account structure the next big question is basically is that how are we going to address this access control across this distributed AWS accounts, yeah? Because creating an AWS accounts is a very cheap activity and, you know, perhaps when you start to have this hundreds of AWS accounts and what are some of the distributed distributed account challenges what you possibly have, right? So let's say if you are sticking with this very classical way, yeah? Very classical way of creating the IAM users in your own AWS account in all this distributed AWS accounts. You can imagine the complexity, right? So you can imagine the complexity what it creates. You know, in you self-managing all those hundred different AWS accounts with all the users what you're creating on top of it, yeah? So it will become increasingly difficult to manage and track the user access across the distributed accounts and it is definitely not scalable. Perhaps you will be linearly increasing your effort, right? So all the operations are fit. What is, you know, when you keep adding the, when you keep adding a new accounts when you keep adding a new users you will be basically, you know linearly increasing the efforts as and when you scale it. So this approach is definitely not scalable if you're sticking into the classical way, yeah? And you will also definitely have issues when it comes to visibility, right? So you, what is the single source of truth you could leverage on, right? So to understand how are you, how are you, you know, what different users you have created across those distributed accounts? You will definitely lack of visibility in terms of, you know, in terms of the distributed AWS accounts if you're leveraging on a very classical way, yeah? And finally, of course, we'll be having those, you know, auditing and reporting challenges. Perhaps if you're coming from a financial enterprise you will understand the seriousness behind it. So, you know, as it is going to be that there is no single point of contact for you to get you that auditing and reporting done, right? So you will be basically relying on some form on automation or to get all those, you know, all those user accesses and the required, whatever the permissions what is applied across those distributed accounts in a very some, you know, very, very imperative way, right, very imperative way of providing an automation on top of it. So all these challenges that comes with the distributed AWS accounts if you're leveraging on a very classical way. So now what is really needed for us, you know, into manage this access control across all the distributed accounts? Of course, we expect a central management, central management of all the user and access to the distributed AWS accounts. You will expect a role-based access control. Of course, for sure you will be also expecting an attribute-based access control, but very classical way, we will be relying on the role-based access control and you will be expecting a multi-factor authentication and for sure if you're coming from enterprise you already have established, you know, your own credentials, you have your own identity provider, you will naturally expect your, you know, you won't use the credentials what you've created on your own identity provider to use on top of those AWS accounts. And basically, you know, you also expect since you have already grouped those AWS accounts and you have created those AWS accounts under the AWS organization, it is natural for us to expect some sort of an integration, you know, for us to cascade it across all those accounts what you've created part of your organization. So some form of an integration is also what is naturally expected, you know, from managing the user access control for all your distributed accounts. And finally, the compliance and auditing reporting all have to happen at a one single place, right? So that's something what I feel which is very specific and which is, you know, effectively needed for managing the user access across all the distributed accounts, yeah? So now what different ways is available? Yes, of course, one is an IAM user which is very classical way, which is what we just discussed. Another thing is basically the IAM roles. What do you basically do? Like, you know, in each of AWS accounts, you associate the IAM roles for the users with the identity provider, you know, by way of doing a SAML assistant. Again, that is not manageable. You know, even if you rely on heavy automation in terms of associating that part of your account orchestration related activities in associating an IAM role for the SAML identity provider, that is also very distributed in nature. And the third option is basically is that IAM identity center, right? So this IAM identity center, which is previously called AWS Singles, I know. And this effectively, you know, this is an effective service which is put out to meet all this, you know, all this what we want, you know, in terms of centralized management for the users across the distributed accounts. And we expect identity federation with the existing identity provider. And we expect a single sign on across all those AWS accounts. So IAM identity center perhaps comes as a, you know, very specific choice from a distributed AWS account management perspective in terms of the user access itself, which you can consider using it. So ideally how it will be looking like, you will be creating an identity center in one of your management account. I believe now you can delegate this identity center into NFM member account. So so far now, so you'll be creating this identity center in your management account. And that is your central point of contact where you will be creating the users by way of integrating with the existing identity provider. And from there, you cascade it, whatever the users that has been created and what about the users being created, you will be associating a role on the management account and that gets naturally cascaded into all the distributed accounts by way of associating in the management account itself. So this basically provides us a path where we have a centralized management for all the user accesses for all of our distributed accounts. And it also naturally integrates with the AWS organization where all whatever the users and the roles what we are creating in the management account gets automatically cascaded into the member accounts. And you will be also having an integration to the existing identity provider, which is very common in all of our enterprise. And you will be also applying a role-based access control. So this is one of the natural choice when it comes to access control management for your distributed AWS account itself. So the third topic, just give me a minute. Right. So the third topic is about managing the network connectivity across all your distributed accounts. Now, if I boil down all this network connectivity that you recommend from our AWS accounts perspective. So what is something which is needed? When you create all this distributed AWS accounts, it is natural for you to expect different applications or different AWS accounts to talk between each other, yeah? So which is basically the connectivity between the VPCs. And you will also naturally expect the VPC to communicate to the data center. And you will expect the VPC to communicate to the internet. And of course, you will be having all the branches from an enterprise perspective. It is very natural that you expect the VPC to communicate between the branches, yeah? So this is some of the connectivity requirements. We'll look at the patterns later. And so what I would consider as a tenets when it comes to the network connectivity for distributed AWS accounts. You need a centralized management where you have a single point of contact to manage all your routings and your networking decisions and the visibility in terms of the routing. And of course, it needs to be very scalable because it will be ultimately creating hundreds of AWS accounts for any enterprise use case. You naturally expect a multi-region connectivity for all those distributed VPCs. And basically is that when you connect multiple VPCs, it is natural that we will expect the VPC to communicate between each other, not necessarily one-to-one, but if you are grouping three different VPCs, you naturally expect three different VPCs to communicate between each other to have a free flow of network connectivity itself. You basically expect a transitivity in terms of your traffic moment here. And finally, of course, we'll be expecting a multicast and broadcast network traffic, network packet moments across all of our distributed VPCs. And end points because not necessarily all the, okay, for those resources which are hosted outside the VPCs, perhaps it can be your partner resources or even the AWS resources, AWS resources like S3, which operates in the AWS public IP address space, which means you need to have some form of a connectivity, network connectivity to those AWS resources which are not running in your own VPC and likewise for all the partner resources which are not operating in your own VPC. So these are some of the connectivity recommends on the connectivity core tenants, whatever would be expecting in a distributed AWS account management. Yeah. Now let's try to understand what different choices they have. So I'll be talking about the VPC pairing with VPC pairing. You basically connect two different VPCs together. But of course, if you are using this VPC pairing for your distributed account use cases, you'll be ultimately creating a mess network with the VPC pairing, which is definitely not scalable. And you will lack all the single point of contact. And you will lack of transitivity. It is that VPCA can communicate to VPCB and not necessarily VPCA to VPCC by providing both connectivitys together. So transitivity is missing. And also direct kind of gateway. I'll just exclude that option. Direct kind of gateway has its own limitation in terms of it is scalable up up to 10 AWS accounts, which means when you create hundreds of AWS accounts with the hundreds of VPCs, this is definitely not a scalable approach. But it has its own merits. It has its own merits for a connectivity use case. Perhaps we will just conclude now that this is something which is not necessarily scalable from a distributed AWS account perspective with the hundreds of AWS accounts or hundreds of VPCs. So the natural choices what we have is transit gateway is basically provides you the hub and spokes out of a management. And private link, we'll look at connectivity patterns very shortly. The transit gateway, private link for you to connect for your resources in the VPC to connect to the resources, you're hosted outside the VPC. It is necessarily that AWS resources or your partner resources. So private link is needed across all your distributed accounts. Direct connectors needed for you to communicate back to the on-prem. And perhaps RAM. RAM what you can do is this is not a random access memory. This is resource access manager. Perhaps if you're using this AWS organization, the RAM allows you to share the resources necessarily like say for example, transit gateway. So you can share the transit gateway submits across distributed accounts by way of associating this resource access manager. So it helps you with all the sharing for your organization AWS accounts. Now, we put this into perspective like what is, we basically, we have a transit gateway, private link, direct connect and RAM for our network connectivity use cases for our distributed account management, yeah. Now with this in picture, basically this is a gist of it where what we naturally expect from a network connectivity perspective is sort of a hub and spoke architecture where with the hub, you create all your networking resources where it can provide you with the routing decisions and your network security bag, and a centralized management for all your network traffic moments across your distributed VPCs. And all the member accounts which communicate back to the hub, you know, which by the form of associating back to the hub account to facilitate the connectivity or the network packet moments between the distributed VPCs itself, yeah. So you can put this into picture. Now, what we are trying to have, we are allocating a separate AWS account called a network shared services where you run all your networking resources like a transit gateway and, you know, data connect. You can possibly terminate the data connect with the network shared services and, you know, endpoints. So you can basically create this endpoints in the shared services account as opposed to creating those endpoints across all the distributed accounts. Say for example, if you're creating an endpoint for S3, you know, if you're creating this endpoints for S3 across all your 100 AWS accounts, you can imagine the charges what it's going to take because ultimately it is all providing you the gateway to the underlying AWS infrastructure by way of exposing your private IP by associating elastic network interface. And then it provides you the, you know, the network connectivity path to the underlying AWS infrastructure itself. So it provides no value for us to associate into each of the AWS accounts, perhaps if effectively just the proxy. So what you basically do, like you create all those endpoints in a common AWS account, the hub account, and use the transit gateway, you know, as a transit gateway as a mechanism to expose all those, you know, expose all the traffic moments for those resources which are hosted outside of APC by way of associating the transit gateway together, yeah? So now this in picture, we'll see, we'll quickly go through some of the patterns. So we basically, you know, from a connectivity between VPC perspective. Now we, you know, we just discussed, we will be using the transit gateway, transit gateway for our hub and spoke related architecture. Now we can see for your multi-region recommends. Say for example, in this case, each of the apps will be associated part of the transit gateway, likewise for your app's portion in the different region itself. And perhaps for you to have the inter-region connectivity, what you will basically do, you will be basically doing a transit gateway pairing for it. So and this is really scalable from the perspective that you can associate hundreds of VPCs into a common transit gateway, yeah? And now let's try to expand this, you know, on top of this transit gateway. So once you establish this transit gateway as a connectivity pattern, you can basically expand the transit gateway for further use cases, you know, from a VPC to an internet. Say for example, if you wanted to communicate to, you know, internet from all your distributed VPCs, me coming in from spending most of the time and most of the time in financial services, the security is basically a main consideration, main priority, so security comes in for every topic. So what you naturally expect is basically is that you wanted to monitor the traffic moments or perhaps you wanted to whitelist the traffic moments for the, you know, for those traffic but just communicating back to the internet. So, you know, you can associate the transit gateway and from there it communicates to the common egress path and you can apply the network access firewall, you know, on top of it for you to have the host-based firewall sort of thing, yeah? And then, you know, if we expand this transit gateway pattern, you know, to our data connect use case. So now the beauty is basically is that since we have this transit gateway as pattern, you basically expand this, you know, transit gateway pattern for some of the, you know, other use cases as well like twice for, you know, on-prem. So say for example, in this case, you basically associate the direct connect, you know, into the transit gateway by way of creating a transit virtual interface. So which means this transit gateway as a pattern, it solves all the connectivity related requirements for all your distributed AWS account management, yeah? So, consideration that I have only two minutes left, we'll be just quickly going through the security at a scale for, you know, for our distributed AWS accounts perspective. So the final thing is basically managing the security at scale, you know, for our distributed AWS accounts, yeah? Again, from a security, you know, from a security at a scale, what is something which you naturally expect, right? So again, you wanted to automate the security checks and you wanted to have some intelligent threat detection, intelligent threat detection for various data sources, you know, from AWS, let's say the DNS queries, what you're still seeing to round 53 for some of the communication what is happening to, you know, happening out of your, happening out of the host, you wanted to have that monitored, you wanted to have some intelligent threat detection on top of it, or you wanted to have intelligent threat detection on top of your X3 access logs to identify any, you know, outliers or any exceptions, or you wanted to have, you wanted to have, you wanted to monitor your cloud trial logs for any outliers, for any exceptions from your natural trends itself. So that effect, you know, intelligent threat detection is something which is naturally expected for all this multitude of use cases across all of our distributed accounts. And we'll also expect a vulnerability management. We expect to track API activity and the API usage because everything happens in AWS is by way of interacting with the AWS APIs. And that's basically the beauty of AWS as well, no? So since everything happens via the API, you know, you naturally expect to monitor the API activity to understand if it is deviating from the natural, you know, your ongoing trends. And if there are any outliers, you wanted to capture, you know, on the fly. And of course, we expect to protect data at scale. You know, we wanted to preserve the data sensitivity at scale for all you distributed our AWS accounts use cases. Now, boiling down all this recommends into different services what we have in AWS which supports it. Sorry, I'll just conclude this with that. So, yeah, just one minute. Again, we expect some sort of a hub and spoke architecture, you know, like what we discussed for the network connectivity itself, yeah? So that you expect to run all your security related services into one common AWS account and try to cascade that down, you know, into all your distributed AWS accounts, you know, for you to manage those, all the security related recommends itself. So some of the services are quickly, quickly, you know, highlight, you know, what you notice here is basically the security hub, which is running all the security services AWS account. And I can also see the event bus. So event bus, you know, which is otherwise called event bridge, you know, in AWS. So you can use the event bridge as a service to funnel down all your events, you know, your cloud watch events, your API activity, your conflict events. You can funnel down all those events into a security hub to take advantage of those. Now, you know, out of the box, out of the box, you know, the security assessment, what AWS security hub provides. You can also group those controls and, you know, manage this vulnerability management with the automated security response by way of associating into the security hub itself. You can also have your own customization, you know, on top of this event bridge events, what is being funneled down across the distributed AWS accounts itself. And that concludes my talk. And I thank everyone for joining my presentation today. Yeah. Okay. Thank you to the last speaker of the day is Badri. So next up.