With your new policy created, the next steps would be to attach it to either an IAM user or group and test it out. But how do you effectively test your new policy without having to make any actual calls or requests? That's where the new IAM Policy Simulator comes into play!

The IAM Policy Simulator is used to evaluate IAM policies in order to determine the most effective set of permissions and actions that you can specify without making any actual resource calls whatsoever. The policy simulator internally leverages the same policy evaluation engine that processes real requests to AWS resources; however, it does not make any actual service request itself. Because of this nature, the policy simulator is unable to report any responses from the generated requests. All you get as a result is whether the policy would allow or deny a particular action. Here are a few ways using which you can leverage the IAM Policy Simulator:

• You can use the IAM Policy Simulator to test policies that are attached to existing users, groups and roles.
• You can also use the simulator to test policies that are not attached yet to your resources by simply copying and executing them against the simulator
• The simulator can also be used to test policies attached to various AWS resources such as Amazon S3 buckets, Amazon EC2 instances, and so on.
• You can even use the simulator to test out real world scenarios by passing various context keys such as IP addresses or usernames that are passed alongside the conditions of a policy, and much more!

To get started with the IAM Policy Simulator, simply select this URL https://policysim.aws.amazon.com/. The policy simulator is a separate entity that runs outside your standard AWS Console. Use your standard AWS IAM credentials to log in to the policy simulator if asked:

1. Once logged in, you can use the simulator to test and validate your existing user, group and even role-based policies. To start with, let us test the policy we created in our earlier section of this chapter! To do so, from the Users, Groups, and Roles section, select the Users from the drop-down list. You should see a list of users present in your AWS account.

2. Select the appropriate User that was used to attach the policy. In my case, the username was joe. Once selected, you will be shown all the policies that the user is currently associated with, in this case, we should see the custom S3 access policy that we created in the earlier section as shown in the following screenshot:

3. Select the policy to view its details. You can even choose to modify and test the policy here using the inbuilt policy editor, however do note that changes made to the policy here are not reflected in the actual policy.
4. With the policy selected, we are now ready to test it using the IAM Policy Simulator section. Here's a snippet of the policy that we are going to test:

        { 
            "Sid": "VisualEditor0", 
            "Effect": "Allow", 
            "Action": [ 
                "s3:PutObject", 
                "s3:GetObject", 
                "s3:ListBucket", 
                "s3:DeleteObject" 
            ], 
            "Resource": [ 
                "arn:aws:s3:::useast-prod-stuff-01", 
                "arn:aws:s3:::useast-prod-stuff-01/Dummy" 
            ], 
            "Condition": { 
                "IpAddress": { 
                    "aws:SourceIp": "10.0.0.0/24" 
                }, 
                "ForAllValues:StringEqualsIfExists": { 
                    "aws:username": "joe" 
                } 
            } 
        } 
          . . . . . .  
 
            "Resource": "*", 
            "Condition": { 
                "IpAddress": { 
                    "aws:SourceIp": "10.0.0.0/24" 
                }, 
                "ForAllValues:StringEqualsIfExists": { 
                    "aws:username": "joe" 
                } 
            } 
        } 

As per our policy, only the user joe has the s3:PutObject, s3:GetObject, s3:ListBucket, s3:DeleteObject rights to the useast-prod-stuff-01 bucket and that too if Joe is accessing the bucket from his organization's internal network (10.0.0.0/24).

5. To test the same, from the Select service drop-down list, select Amazon S3 option. Next, match either of the actions using the Select actions drop-down list. In this case, I've only selected the s3:PutObject action.
6. Once completed, from the Global Settings section, type in the adjacent values against the condition keys that appear in the policy. In this case, type in the username and the sourceip as depicted in the following screenshot:

7. Next, from the Action Settings and Results section, expand on the Resource and type in the ARN of the resource against which the policy needs to be tested. In this case, this has to be the ARN of the S3 bucket arn:aws:s3:::useast-prod-stuff-01. Once done, select the Run Simulation option.

With the simulation running, you should get either allowed or denied results based on the values you provide during the simulation. Feel free to change the actions as well as the condition keys and re-run the simulation. With each attempt, you can fine tune and troubleshoot your policy without having to actually pass any real requests to your resources.

You can also use the same policy simulator to test out new policies that are not yet attached to resources. To do so, you will first need to toggle from the current (default) mode of Existing policies to New Policy using the Mode option provided at the very top of the simulator.

Once the New Policy option is selected, you can use the Policy Sandbox to create new policies and test them out the same way we did a while back. Remember, however, that policies created or edited here are not reflected back in AWS IAM.

With this, we come towards the end of this section. In the next section, we will be looking at how you can leverage AWS Organizations to effectively manage multiple AWS accounts with relative ease.