Hey everybody, welcome to "This is My Architecture."
My name is Peter, I'm here with Siba from Publicis Sapient.
>> Good to have you here. >> Thank you, Peter.
All right, Siba before we talk about the board, what do you guys do?
So Publicis Sapient has been helping our clients in all things digital for over two decades.
We help our clients in their journey of digital business transformation.
All right, so I know you've built this pretty cool, account generation engine.
Right, so tell me what the reason was to build this and take me through how it works.
So, technology is changing very fast,
and in our journey to help our clients,
in that additional business transformation story,
we need our engineers to be equipped with newer technologies, tools and solutions.
So we need our engineers to be learning and experimenting on those.
And we need a platform for that.
All right, so you wanted to provide dedicated accounts to each of your engineers to test things out, right?
So, how does this whole work, show me?
So, at the end, the account creation process is fairly simple.
We kept it very straightforward.
We have a user portal through which the user submits an account provisioning request.
The API Gateway, listens to the request
and forwards it to a Validate Lambda function,
The Validate Lambda function actually verifies a few information
like email, domain, so that, the request is coming from within the organization.
Once it does that it,
it sends a notification to the user
acknowledging that,
the request has been received, and then forwards it to
create Lambda function.
The Create function actually creates and provisions the account.
- Ok, understood.
So first and foremost, the validation part is interesting,
to make sure that not everyone is allowed to create those accounts
under being validated with API Gateway, comes like a first class citizen in here,
and you use SQS to continue the flow.
Now, the creation is interesting, what's happening right here?
So creation is where actually the account is provisioned.
In the Create process, we identify the master account,
we use a multi-master account strategy.
We identify the least algorithm,
least-used algorithm to find the master account in which the child account needs to be created.
We configure the account, we assign the account, an organization unit,
and create budget alerts.
And finally, send a notification to the user and share the credentials.
All right.
so, two things, actually three things that I'm interested in, first of all,
the kind of the governance of those accounts you see organization plays a role in here.
And then we have the Budget Control.
Yeah, so what happens on the organization side?
So, what we have taken advantage of our organization is that
we have an active account and we have an inactive OU.
We have active OU and inactive OU,
Active OU is where all the accounts are hosted.
And all the policies on security and cost are enforced on active OU.
Inactive OU is essentially a denial service
when an account is not in use , it is in a deny OU.
Ok, so first, we've looked around using IM policies
to manage the whole governance,
but we were lucky that SCP was launched around the same time.
>> Sure. >> And, you know, we took advantage of it
so that we can centrally control and manage all the governance.
- Perfect, perfect.
Ok, so you were able to see which services are made available to your users eventually.
One thing we have not talked about yet is the confirmation part, so it's part of the blueprinting, right?
Yeah, so the Create process actually uses CloudFormation,
to provision the account and create budget alerts and all of that,
within the, within the SCP we have restricted the services that user can use.
We have also limited the kind of instance types that user can use.
For example, reserved instances are forbidden.
We have also restricted marketplace AMIs.
Alright, so all of this is done within SCP.
>> Ok. >> Ok, perfect.
So then the last part of asked already,
which is the Budget Control, right?
At some stage, if i'm gonna, you know, limit the usage of service.
>> Yah. >> What's going on here?
So, we take a advantage, we use budget alarms and a SES to kind of
manage the, monitor the budget.
We have configured alerts to have 50%, 70% and 90% of usage.
And once the user is continuously notified.
Once the user gets to 100% budget usage
his account is actually moved to the inactive OU that I referred earlier, when all services are denied.
And, you know, after certain hours, you know, we completely remove the account
so that, you know we don't end up consuming the budget. - Alright. Ok, perfect.
- So you removed those accounts that are not in use anymore.
Ok, perfect, Siba. Thank you very much for, you know,
shedding light on how you use
organizations and how you're going to, you know,
implement budget control to make sure that accounts are not abused at some stage.
Right. So, thank you very much for this, and thank you for watching "This is My Architecture."