You are mixing things up.
If have instance/service sitting in a private subnet and you need this instance to have outbound access to the Internet, then you need some NATing/PATing service. In case of AWS, you can either attach NAT Gateway to your VPC or launch NAT instance in a public subnet in the same VPC and configure route tables accordingly. API Gateway has nothing to do with that.
API Gateway helps you build serverless, secure and highly available REST APIs which you can send an HTTP/HTTPS requests to. Can you configure some API Gateway resource/method to point to an external service? Sure you can. But API Gateway cannot be targeted in your route table. Why? Simply because route tables operate on the 3rd layer of ISO OSI model (routing via IP addresses) and API Gateway operates on Layer 7 of ISO OSI model (application layer).
So here are things that you can do.
- instance (private subnet) -> NAT instance -> Internet Gateway -> external service
- instance (private subnet) -> NAT Gateway -> Internet Gateway -> external service
- instance (private subnet) -> NAT instance/gateway -> Internet Gateway -> API Gateway -> external service
Or you can even launch a private API Gateway that will operate only inside of your VPC but again, it has nothing to do with granting access to the Internet.
About the security, we are not talking here about someone trying to access your resources (inbound access) but about you/your resources trying to access some external service. You can and should control this via firewalls such as NACLs, Security Groups and even OS level firewalls. API gateway's security works the other way around, it protects you from malicious incoming requests/DDOS attacks and unauthorized use of your resources.
In short, if there already exists an external service that you know that you want to access from inside of your private subnet, then API Gateway is completely useless to you.