I haven't implemented this yet myself, but I'm looking into using the On-the-fly Reconfiguration of NGiNX Plus. I'm thinking that either the AMI, or the configuration management (Puppet, Salt, or such) that sets up an Auto Scaling Group instance, could reach the NGiNX reconfiguraiton API (perhaps, via an internal Route53 domain name so no fixed IP would need to be used), and add itself to the upstream cluster for the reverse proxy. After that NGiNX's built-in health check would then take over for that [added] instance, and drop it in case it becomes unavailable. This seems the cleanest solution and there is no delay in adding the instance, and hardly any delay in dropping it since NGiNX Plus features out-of-band health check.
This approach avoids needing to set up an auto-discovery system (Consul, Serf, or such) which for smaller setups often seems like much overhead both in the terms of setup/administration as well as required EC2 instances. Consul, for example, requires minimum of three instances to be stable. Serf could perhaps run on the ASG instances themselves, but there's still the overhead of maintaining it, and if the ASG scales down to one or two instances, you'd lose the quorum.
Finally, this could be combined with automatic notification of Auto Scaling Group changes, perhaps on the NGiNX server(s) that is/are used for load balancing. A listener triggered by such notification (this may be what Upendra also referred to) could then instantly add the new instance to NGiNX via the On-the-fly modification API. Besides the cost of NGiNX Plus, this makes one wonder why would anyone use Elastic Load Balancer with its numerous issues in the first place.