- Okay, so now let's review a use case,
using roles for cross-account access.
So in this use case, what we're looking at
are leveraging multiple accounts in one organization,
multiple AWS accounts.
This is a a very common practice.
A lot of organizations will do this;
split up different resources between different accounts.
This is also considered a best practice,
and recommended by AWS to do this.
Now, how you split your resources up
between accounts is totally up to you.
This is just one example, you don't necessarily
have to do it this way.
But in this example, what we're going to do
is put our development resources over here
in what we might call a development account,
and that's completely arbitrary.
That's just what we've chosen to name it.
Again, there's nothing in Amazon Web Services
that says we have to call it that.
We're going to put our production resources
in a production account.
Now, the key here is what we call the payer account.
So, our initial account that we opened,
we might call that the payer account,
and within that account, again we will have
no users, no groups, no roles.
We will have no resources deployed,
and the only thing that we use that account for,
is for paying the bill.
So again, that's what we call the payer account.
The other two accounts are what we call the linked accounts.
These are the counts in which we create
and manage our resources, and the course.
Again the payer account is just the account
we use to pay the bill.
So again, here in the development account,
just one way to use this, is here
we would add our users, our groups, and our roles.
We would add our development resources,
and in the production account, we won't have any users.
So, no users or groups.
In order to get access into production,
we will leverage roles, and we're going to
review an example of how to do that coming up.
Now, the way that you link these accounts
are completely up to you.
You might separate further into
different types of environments.
You might have an account for QA,
an account for testing.
You might split them by department or business unit.
Perhaps you want finance and accounting, resources in one.
You might want engineering or research and development
resources in another one.
Again, it's completely up to you.
Now, moving forward from this example,
what we're going to look at is how
this actually continues to work
at the user and role level.
So in our development account, we have our user.
In this particular case, our user is jane.doe,
and in our production account, notice we have
a separate account number up here.
We have a role.
So again, in our production account, in this
particular example, we will not have
any users over here; we just have a role.
So, when Jane wants to do things, perform actions
on production resources, what she will need to do
is assume a role in order to do that.
So, here we have a role called admin.
You can see that this role in this particular example,
it's allowed to terminate ec2 instances,
but only in perhaps a particular region.
Whatever region that is.
Maybe it's only in US west, and it's not US east.
We also have what we call a trust relationship.
Essentially what we're saying is that
when we create this role for cross-account access,
we're going to specify that we are trusting...
Again, we're trusting the development account
as an account that we allow to assume that role.
What we're also going to do is
give this user, we're giving Jane Doe
the ability to assume that role.
So you can see here that we're going
to allow her to assume that role,
and notice that we are specifying here
the account number of the production role.
So, again, what we have as a user
in our development account, is assuming a role
that is trusted by the production account,
and once Jane Doe assumes that role,
she will then be allowed to perform these actions
on resources within the production account.
So let's look at how this actually works.
Our user Jane Doe, in this particular example
will use the AWS command line tools
to assume this particular role.
So, we're using the STS service,
the security token service, and we're
calling the action "assume role."
And, as we've seen, we've already given
the Jane Doe user the permission
to perform this particular action.
So, she's calling the security token service
saying, I want to assume the admin role
in the production account.
The security token service will return,
again, temporary credentials to the Jane Doe user,
then she can use those temporary credentials
to perform another action.
In this particular case, perhaps Jane
has determined that she needs to terminate
a particular instance in the production account.
So again, she might use the AWS command line tools,
leveraging the ec2 service to terminate
instances, leveraging these temporary credentials.
And in doing so, she can then terminate
this particular ec2 instance.
So again, that's just one example of leveraging roles
to allow a user in one account to
access resources in another account.
And perhaps you do that,
it could be an account that you own.
It could be a third-party account, such as
a customer or a vendor as well.
So again, using roles for cross-account access,
are a really powerful and flexible way
to achieve a higher degree of security
within your Amazon Web Services environment.