<p>I'm using an AWS NLB to expose my Kubernetes pods to the internet. The NLB is currently using <code>instance</code> target types but I noticed there are also <code>IP</code> target types. What are the differences between an <code>instance</code> target type vs an <code>IP</code> target type from a practical point of view? When would you use one over the other?</p>
<p><a href="https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-type" rel="noreferrer">AWS's documentation</a> specifies some restrictions around using <code>IP</code> target types, namely they must be within certain CIDRs and constraints around maximums, but I'm trying to understand when you might want to use one over the other.</p>
<p>I don't know if it has any impact, but we've been having issues with our kubernetes <code>rollingUpdate</code> deployments where we're seeing downtime for the pods as they switch over (we have <code>liveness</code> and <code>readiness</code> checks there).</p>

<p>The three key use-cases for using <strong>IP target type</strong>:</p>
<ul>
<li>your target does not have to be an instance - anything with private IP address will work, including internal load balance, VPC private service, Fargate containers, databases, on-premise servers through VPN.</li>
<li>your target can be in different region, as long as you have cross-region peering between your VPCs</li>
<li>you have multiple network interfaces on your instance, so you can load distribute traffic between them, e.g. different applications on a single instance are bind to different interfaces. Each interface can be associated with different target group.</li>
</ul>
<p><strong>Instance target type</strong> is only limited instances. It should be your default choice when load balancing instances. For example, if you have instances in <strong>autoscaling group</strong> (ASG), the ASG can automatically register your instances with your load balancer. You can't do this for IP target types.</p>
