So let's have a look now
at the fundamental differences
between IAM Roles and Resource Based Policies.
So for cross accounts especially
when you want to perform an API call
on an S3 bucket cross account, you have two options.
You can attach a resource based policy to a resource,
for example, an S3 bucket policy on an S3 bucket
or you can decide to use a role that can actually
access the resource.
Let's take an example as these two options.
This is the example where the user in Account A
can assume a role in Account B
and that role has the permissions to
access your Amazon S3 buckets
or similarly the user in Account A,
through a bucket policy placed
on the Amazon S3 bucket in Account B,
can access the S3 buckets.
Both of these two situations are valid
but there is a little bit of difference.
The first one is IAM role
that has access to the S3 bucket.
The second one is the S3 bucket policy that allows the user.
So what's the difference?
When you actually assume a role
you actually give up all your original permissions
and you take all the permissions assigned to the role.
This is very important. This means that we, for example,
assume a role, and this role can do whatever.
We can now do anything that the role does
but we cannot use our original permissions.
When you use a resource based policy instead
the principle does not assume a role
and therefore it does not have to give up his permissions.
If you take an example of user in Account A,
they need to scan a DynamoDB table in Account A
and then that fits in an S3 bucket in Account B.
What they can do is, we should use a resource based policy
because this way we don't have to assume a role
and we can both scan the DynamoDB table
and write to an S3 bucket in other accounts.
Resource based policies are supported
by more and more AWS services and resources over time.
We have the Amazon S3 buckets, the SNS topics,
SQS topics, the Lambda functions, and so on.
A big difference of where this comes into play
is when you use Amazon EventBridge.
Amazon EventBridge has rules, and these rules
need permission to do whatever it wants to do on the target.
We have two kinds of targets.
We have the targets that supports resource based policy
such as Lambda, SNS, SQS, CloudWatch Logs, API Gateway
and so on.
And in that case, what you should be doing is
that you should change the target resource
to have a resource based policy that allows
the EventBridge rule to do whatever it needs to do.
The second option is for example, for Kinesis data streams
or Systems Manager Run Command, or starting an ECS task
then you need to have an IAM role.
So the IAM role will be attached to the EventBridge rule
and will have the permissions to write to Kenesis.
So you may ask me, how do I know?
By looking at the documentation
but from an exam perspective
all the information you need to know is on these slides.
Remember, SNS, SQS, Lambda, are for resource based policies
and Kenesis data streams especially, is using an IAM role.
Okay, that's it for this lecture.
I hope you liked it and I will see you in the next lecture.