IAM Policy - Allow execute-api on resource with variable

From the information you've provided, it seems that you're attempting to grant permissions to a resource with a path variable (appointment_id), while denying other resources under the same root path (appointment/*). The tricky part about this in IAM is that path variables aren't inherently supported.

In IAM policies, when specifying resources, wildcards (*) can be used to represent one or more characters. But there's no built-in method for excluding certain patterns using the wildcard syntax. AWS does not currently support variable substitution in IAM policies, and thus you can't use a placeholder for the appointment_id in your policy.

However, you might consider adjusting your API routes to help facilitate permissions. If all of the appointment/{appointment_id} routes are read operations (GET), and all other appointment/* routes are modification operations (POST, PUT, DELETE, etc.), you could differentiate between the two in your IAM policy by HTTP verb:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "execute-api:Invoke",
      "Resource": [
        "arn:aws:execute-api:ap-southeast-1:551253161854:5i72ewjb4d/dev/GET/appointment/*"
      ]
    },
    {
      "Effect": "Deny",
      "Action": "execute-api:Invoke",
      "Resource": [
        "arn:aws:execute-api:ap-southeast-1:551253161854:5i72ewjb4d/dev/POST/appointment/*",
        "arn:aws:execute-api:ap-southeast-1:551253161854:5i72ewjb4d/dev/PUT/appointment/*",
        "arn:aws:execute-api:ap-southeast-1:551253161854:5i72ewjb4d/dev/DELETE/appointment/*"
      ]
    }
  ]
}

This policy allows GET requests to any resource under /appointment/, but denies POST, PUT, and DELETE requests to those same resources. This works if your API is structured to have all modifications under separate routes.

For a more granular access control to your APIs, you may want to consider using AWS API Gateway resource policies or Lambda authorizers, as IAM policies may not provide the granularity you're looking for. If you do this, you'd be able to write custom logic to allow or deny access to certain routes. For instance, with a Lambda authorizer, you could extract the appointment_id from the path parameters and determine if the current user should have access to it.

If the answer is helpful, please click "Accept Answer" and upvote it.