And welcome back into this video we'll be discussing about the multi account strategy enablers.
Now, in one of the recent organization that I have been working with, we had close to around 80 interviews
account.
Now, in order to manage so many Idalis accounts, you will need a proper planning and a strategy.
And hence, as a solutions architect, it is very important for us to know on some of the challenges
and some of the ways in which you can overcome them when you start working in enterprise.
So let's go ahead and understand more about it now.
Multiple account strategy is definitely great because it gives you the highest amount of isolation between
the resources as well as the security.
So typically what many organizations they do is they have the regional level solution.
So they have an ideology region for development instances.
They have in the region for production instances, although that can be sufficient.
But it is not a best practice because if someone creates an policy for the developer and if that is
not a very isolated developer, might have access to the production environment.
So it is always great to have multiple accounts.
So you should keep individual idalis account for development individually the second production and
avoid giving access to the developers, to the production environment except the high level read-only
access.
And it is when organization uses multiple A.W. accounts, there are certain considerations that you
need to remember, otherwise things will become messy pretty soon.
So there are four things that you need to take care of.
One is the identity account architecture.
Second is the logging account architecture.
Third is the publishing account architecture and for this, the billing structure.
So let's go in and understand each one of them.
So the first one is the identity architecture.
So let's say that you have a fight.
Either this accounts or, you know, you would not like to create individual user in each one of these
accounts.
So let's say that I have five accounts and I have a new person who has joined us this, obviously.
Now, I can add that a user name to each of these accounts, but it will soon become messy.
So it is recommended to manage all the users in a centralized place instead of adding each user in the
individual database account.
Now, this specific architecture of handling the users in a centralized place can be achieved with the
help of cross account and rules as well as with the federation will be discussing more about this in
the upcoming videos.
But for this will just have a high level overview about what each of these points really mean.
Now, the second is the logging account structure.
So basically it is very important that all the logs should be stored in a centralized place where it
can be monitored and analyzed on a regular basis.
So if you see earlier, I have a current account B now account iCloud logs are going to the central
account S3 bucket and the account of these config log is going to the central account S3 bucket.
So this is just for the representation.
However, the cloud of the config log, that AWB backflow log, all of those logs from all accounts
should be stored in a centralized S3 bucket.
Now this centralized S3 bucket is from where you can go ahead and analyze the logs in a regular basis.
So maybe if you're using solutions like Splunk, Splunk can fetch the log from this central bucket and
it can go ahead and check for this security or other anomalies.
Now, the third is the publishing account architecture.
Now, this is very important because let's say you have multiple eyewitness accounts.
I'll give you some of the real world examples like of, as we discussed, that we used to have a database
account.
Now, what developers used to do in each and every eight seconds, different team had access and some
people would consider it had instances.
Some people will launch Ubuntu, some Villines, Amazon, Linux, some Melun, Sendai's.
So there is no standardization which is happening.
And typically the security team is responsible for providing the high end image, or many organizations
often call them as a golden image.
So it is very important that if you have multiple accounts, you need to ensure that developer only
launch the instances which are security hardened and approved by the security team.
So that standardization is extremely important.
So your publishing account architecture really comes into picture where you have the easy to e-mail.
So let's say that this is ITU.
EMI is being created.
Taken by the security team, now this image can be shared across all the accounts and you can create
an policy that the developer can only launch the new instances if they are from a specific image, you
can even make use of the service catalog for such cases.
So this is the publishing account architecture and the last one is the building structure.
Now, basically, you can make use of the consolidated building feature in the organization so that
you have a single place for tracking the entire bill.
So you have a master account and these are the child accounts which are connected.
So you have a consolidated billing audio.
So the great benefit is that it is easy to track.
It is easy to see all the bills and you have the advantage of the combined usage as well.
And there is no way to know if we will be discussing about this in the relevant videos where we discuss
about the billing structure.
Indeed.
So this is the high level overview about some of these challenges that you will face typically if your
organization is having multiple are gone.
So in this video, we had a high level overview about the challenges as well as the solution that you
can architect within your organization.
Now, we'll be discussing about each of this in great detail in the upcoming videos.
I hope this high level overview video has been informative, and I look forward to seeing your next
video.