These things are possible... but this gets at another aspect of AWS's design in particular.
I do a lot of my AWS work in CloudFormation. When I hit a wall, the answer is pretty much always to stand up an EC2 instance that can speak SNS, grant it larger-than-necessary permissions to my VPC, teach CloudFormation about it as a custom resource type, and have it serve as a proxy for the not-configurable-enough resource, allowing it to assert its own policy and make third-party calls before making the real callback into your VPC [or not.] It's the AWS equivalent of writing a factory method to wrap a badly-written constructor.
To generalize that thought: IAM "users" are made to either be people (e.g. your developers, your ops people), or representative tokens for entire third-party organizations (e.g. a CI bot.) Despite the existence of IAM roles, IAM isn't really made to assert "machine-agent"-granular permissions.
Instead, what you really want is to imagine a third-party service running in the AWS cloud that does exactly what you want. You would grant that third-party's IAM user overly-wide permission to play with your VPC, but trust it to only do what it should, because, obviously, you have a business relationship and it would be dumb of them to abuse it.
As soon as you can see what API needs to exist, you can turn around and become that very same imaginary third-party: make a separate AWS account, stand up an API server in it that takes requests to do what your "clients" want, and then, in turn, make requests to the AWS APIs on their behalf to accomplish those things.
AWS isn't a high-level framework; it's a kit of low-level tools. (This is really what the PaaS vs IaaS distinction implies, I think.) AWS is built assuming that you're willing and able to take their tools and pipe/script them together to build the higher-level components you need. And, since AWS is for web services, that assumption comes in the form of expecting you to be able to pipe, hook, or wrap any of their APIs to/with/in your own API.
I do a lot of my AWS work in CloudFormation. When I hit a wall, the answer is pretty much always to stand up an EC2 instance that can speak SNS, grant it larger-than-necessary permissions to my VPC, teach CloudFormation about it as a custom resource type, and have it serve as a proxy for the not-configurable-enough resource, allowing it to assert its own policy and make third-party calls before making the real callback into your VPC [or not.] It's the AWS equivalent of writing a factory method to wrap a badly-written constructor.
To generalize that thought: IAM "users" are made to either be people (e.g. your developers, your ops people), or representative tokens for entire third-party organizations (e.g. a CI bot.) Despite the existence of IAM roles, IAM isn't really made to assert "machine-agent"-granular permissions.
Instead, what you really want is to imagine a third-party service running in the AWS cloud that does exactly what you want. You would grant that third-party's IAM user overly-wide permission to play with your VPC, but trust it to only do what it should, because, obviously, you have a business relationship and it would be dumb of them to abuse it.
As soon as you can see what API needs to exist, you can turn around and become that very same imaginary third-party: make a separate AWS account, stand up an API server in it that takes requests to do what your "clients" want, and then, in turn, make requests to the AWS APIs on their behalf to accomplish those things.
AWS isn't a high-level framework; it's a kit of low-level tools. (This is really what the PaaS vs IaaS distinction implies, I think.) AWS is built assuming that you're willing and able to take their tools and pipe/script them together to build the higher-level components you need. And, since AWS is for web services, that assumption comes in the form of expecting you to be able to pipe, hook, or wrap any of their APIs to/with/in your own API.