Solution 1:

T2 instances should be absolutely avoided in scenarios where your applications consistently consume their credits, precisely due to this kind of issues with the CPU credits system provided by AWS. If your application is CPU intensive in a consistent way, you should better go for C3/C4 instances, which have the same CPU/Memory ratios (except t2.large which, is equivalent to M4.large).

Autoscaling works because you assume that the capacity of your cluster is consistent and proportional to the number of instances, which may be not be true when using T2 instances in some scenarios. Once some of your ASG instances (not necessarilly all of them, due to different launch dates, autoscaling events, etc.) starve their credits, all of the metrics THOSE INSTANCES submit to Cloudwatch are degrading the consistency of the ASG metrics, rendering them useless to take good decisions for Autoscaling.

Solution 2:

My approach is to scale before you run out of CPU credits. A simple way is to define a minimum acceptable credit balance, for me this is 50.

You can do this within CloudWatch. 'Create Alarm', EC2 Metrics-> By Auto Scaling Group.

Select CPUCreditBalance, minimum of 50. This way I can take action when a single instance is likely to become slow before the load balancer removes it from circulation, even if the average balance is within acceptable bounds.

You can create a notification or auto scale.