Can we alter/deny some of the ephemeral ports used by Nat gateways (1024-65535 )?

So the problem is your customer is looking at NACL's and thinking they are traditional firewall rules and they are not. NACL is a stateless firewall meaning that you have to define all the required ports both inbound and outbound. Now the trouble with this is that most Protocols do not stick to a single Port number. Take web traffic for example, when you request a webpage your computer sends a request to web servers on port 80 or 443. The webserver captures the request and then sends you a response that tells your computer what port it needs to use for this communication session. The server does this because multiple people can't communicate on a single port so to handle more than one client it moves known traffic to the dynamic port ranges.

Think of it like you walk into a DMV (or other government building that handles multiple functions) the first person you see asks you what you are here for. After you respond they give you a ticket with a number on it. That ticket tells you what window to go to in order to complete the task you are there for. the service on port 80/443 is the first person who hands you a ticket and the windows is the higher level port used to completed the session.

So that being said when using a stateless firewall, like the NCAL's, since the firewall doesn't track sessions you have to open the dynamic port range to allow for proper communication. This lack of tracking and requirement to open so many ports when using NACL's is the reason we dont recommend using them for fine grain access control. NACL's should be used for broad stroke control like allowing access to the IP addresses of your internal production network to the AWS prod but denying any access from the user or Dev IP space. Not to mention the fact that NACL's only control traffic at a subnet level so traffic between instances inside the same subnet wont ever be evaluated by the NACL.

The better option for control in almost all scenarios is to use security groups as your main control point as it is statefull and controls traffic at a the elastic networking interface. Security groups are a deny all by default, you have to define the ports that the service uses to initiate the session (80/443 in the above example) as well as where that traffic is from, for inbound rules, or where it is going, for outbound rules. Being stateful, the security group is smart enough to understand the session so now when the server responds to the client telling him talk on a higher dynamic port the security group dynamically opens that port for communication between the client and server. It than keeps tracking the session until either the client or server closes the session at witch time the security group no longer allows communication over that port.

This is an oversimplification of an IP session and how the NACL's and Security groups work but hopefully it gives you enough information to take back to the customer and help them design a better architecture (limiting NACL usage). Feel free to hit me up on chime if you need some additional support.