NAT Gateway for outbound request

Using a NAT Gateway in conjunction with a VPC is indeed a safe and recommended approach for allowing your Lambda function to make outbound requests to the Apple App Store API while maintaining isolation from the internet.

Here's how this setup would work:

1. Place your Lambda function in a private subnet within your VPC. This ensures that the function is not directly accessible from the internet.

2. Create a NAT Gateway in a public subnet of your VPC. The NAT Gateway will allow your Lambda function to initiate outbound connections to the internet (in this case, to the Apple App Store API) while preventing unsolicited inbound connections.

3. Configure the route table for your Lambda function's private subnet to direct internet-bound traffic (0.0.0.0/0) to the NAT Gateway.

4. Ensure that the security group associated with your Lambda function allows outbound HTTPS traffic (port 443) to the Apple App Store API.

This configuration provides several security benefits:

1. Your Lambda function remains in a private subnet, inaccessible from the internet.
2. The NAT Gateway only allows outbound connections initiated by your resources (like your Lambda function) and their corresponding responses. It doesn't allow any unsolicited inbound connections from the internet.
3. All outbound traffic appears to come from the NAT Gateway's IP address, providing an additional layer of abstraction.

By using this setup, you can safely make outbound requests to the Apple App Store API while keeping your Lambda function isolated from direct internet access. This approach balances the need for external communication with strong security practices, making it a safe choice for your project.
Sources
AWS Lambda function not connecting to external services | AWS re:Post
NAT gateways - Amazon Virtual Private Cloud

Connecting your Lambda function to your VPC can help to improve security by giving you dedicated, fixed IP addresses for connecting to the internet and possibly to your internal resources. However, you'd have to configure IP address or source VPC restrictions for some services, at least, in order for the Lambda function being placed in the VPC to provide any significant security benefit.

Note that NAT gateways incur fixed per-hour costs for both the NAT gateway and its public IPv4 address(es). There are also per-gigabyte fees for all traffic passing through the NAT gateway.

Apple requires all applications sold on Apple Store to support IPv6 networks, so I'd guess they're very likely also to support IPv6 for their own APIs. You can check that by checking if they have an AAAA type DNS record for the hostname you're calling. If IPv6 is supported, you could add IPv6 support to your VPC and configure the private subnets to which your Lambda function is attached as dual-stack subnets, with both AWS-assigned IPv6 addresses and private IPv4 addresses, both of which are free of charge. Instead of a NAT gateway, you'd create an egress-only internet gateway (EIGW) as the next hop towards the internet in your private subnet's route table. The design is described here: https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html

An egress-only internet gateway doesn't incur fixed fees or traffic processing fees, and the public IPv6 addresses for your VPC are free, so using IPv6 only for internet traffic, if supported by the APIs, would save money and conserve public IPv4 address space. Of course, this only works if you don't need to call any IPv4-only services or APIs.