If the AZ goes down, then new instances are spun up in a different AZ, if necessary. As soon as the first AZ comes back to life, auto scaling will try to launch the instances there and try rebalancing the load appropriately. This is the only time the number of instances can go above max capacity specified (for a short amount of time). As soon as a certain amount of capacity is available in AZ 1, it will start terminating the instances in AZ 2. 

Instances that fail can be seamlessly replaced using auto-scaling while other instances continue to operate. Although auto-replacement of instances works really well, storing application state or caching locally on your instances can lead to problems hard to detect. 

Health checks are performed periodically and the instances are marked as unhealthy or healthy. Unhealthy instances are terminated and replaced (if new number of instances < minimum or < desired capacity). The EC2 instance status is unhealthy when the instance state is not "running" or the system health check is "impaired". Instances are determined to be unhealthy when ELB health check results in "OutOfService" (or the EC2 health check fails). You can also define your own health checks to mark individual instances as "unhealthy". You can also integrate instance statuses with an external monitoring systems.

TCP- and / or HTTP-based heartbeats can be created for this purpose. However, it is important to consider the depth and accuracy of your health checks because deep-in-the-stack health checks can lead to situations where you can get excessive number of false positives and false negatives in your results.  It is worthwhile to approach the implementation of health checks, iteratively, to arrive at the right set that meet your goals.