MemberDecember 14, 2023 at 7:47 pm
Hi. I saw the following question on Bonus Question Set 5:
A company has a designated AWS account for each project of its development team. All of these AWS accounts are linked to the main AWS account under the same AWS Organizations. The CFO allocates a budget for each project owner. Each project owner is allowed to provision any cloud resources that they need but all resources should have the Project tag which is used for cost allocation. After a recent audit, several team members are not adding the Project tag on their Amazon EC2 instances which results in inaccurate cost reports.
– Apply an SCP to the AWS Organization that will deny the ec2:runInstances action if the Project tag is not applied.
– Create an IAM policy on each project account that will deny the ec2:runInstances action if the Project tag is not applied.
– Configure an AWS Config aggregator for the AWS organization to generate a
list of all EC2 instances without the Project tag.
One INCORRECT answer + explanation:
The option that says: Create an AWS Config rule on each project account to flag any resources if the Project tag is not applied is
incorrect. This is possible but you will have to configure several AWS
accounts under the organization. It is better to use an aggregator on
AWS Config instead when scanning multiple AWS accounts.
The same could be said about applying both an SCP to the (root of the) AWS Organization and creating an IAM Policy on each project account. The existence of the SCP that denies the ec2:runInstances action makes the IAM Policy unnecessary. Plus I would argue that configuring this policy on multiple users in multiple accounts is more work than creating an AWS Config rule on each account.
Can someone please explain to me why creating an IAM policy on each account is a correct answer here but not creating an AWS Config rule? Thanks!
MemberJanuary 5, 2024 at 12:36 am
I also think config rule is the correct answer. If we are already adding SCP deny then no point to put it on individual account.
AdministratorJanuary 15, 2024 at 12:17 pm
Thanks for your feedback.
The key difference between the two approaches lies in the enforcement of the rules and the timing of their application.
IAM Policy: An IAM policy that denies the
ec2:runInstancesaction if the Project tag is not applied, is enforced at the time of resource creation. This means that if a user tries to create an EC2 instance without the required Project tag, the action will be denied and the resource will not be created. This is a proactive approach that prevents the creation of improperly tagged resources in the first place.
AWS Config Rule: On the other hand, an AWS Config rule that flags any resources if the Project tag is not applied is a reactive approach. The rule checks for compliance after the resource has been created. If a resource is found to be non-compliant (i.e., it does not have the required Project tag), it is flagged for review. However, the resource is still created and may incur costs until it is reviewed and corrected.
In this scenario, the goal is to prevent the creation of resources that do not have the required Project tag to ensure accurate cost reports. Therefore, applying an IAM policy that denies the creation of such resources is a more effective solution. The AWS Config rule, while useful for identifying non-compliant resources, does not prevent their creation and may result in inaccurate cost reports until the non-compliance is rectified.
I hope this helps! Let me know if you have any further questions.
JR @ Tutorials Dojo
Log in to reply.