SCP bad error messaging

Question

## Service Control Policies uninformative error messages
Hello, I am testing out implementing company-wide SCPs to enforce resources being created with the correct tags. When in effect, I noticed that the error messaging when being blocked from creating resources is confusing and does not point to tags being the issue at all.  The error messages are also different for each resource.

From a systems admin perspective, this seems like it will create much more harm than good. The "insufficient permissions" error messaging will prompt developers to ask for more permissions when that is not the issue at all.

Is there any way to customize error messaging for service control policies? Or maybe someone has come up with a better solution on how to enforce tagging with good error messaging?

![Enter image description here](/media/postImages/original/IMihSUiywYSIqqeCs03_wkgw)
![Enter image description here](/media/postImages/original/IMGGSGDjtwSTuyTS2joFMPoQ)

Answer

The message is encoded for security purposes. The user may already have the permissions to decode it, but it won't be shown decoded in the console. 
In order to decode the message, open CloudShell and use the following command:
```
aws sts decode-authorization-message --encoded-message  \
--output text | jq '.'
```
When using CloudShell, it will assume privileges that are allocated to the logged in user / role.
To decode an authorization status message, a user must be granted permissions through an IAM policy to request the DecodeAuthorizationMessage (`sts:DecodeAuthorizationMessage` ) action.

![Decoded Message](/media/postImages/original/IM68H_IKIiRK6JYZ-TKC3NAQ)

Give your SCP statements meaningful  `sids (Statement IDs)` to make it easier to figure out what is failing, otherwise you will have to evaluate the message once it is decode to figure out the root cause. You can use the `--query` flag to retrieve the parts of the message that are relevant to you.

You cannot customize the error message. You can get more information about the failed request without decoding the message by looking through your CloudTrail logs, however I would advice against granting permissions to read the CloudTrail logs in general. Granting permissions to decode sts authorization messages is the best compromise, in my opinion.

SCP bad error messaging

Service Control Policies uninformative error messages

Relevant content