AWS re:Invent 2020: Looking at Amazon EKS through a networking lens

Because of its security, reliability, and scalability capabilities, Amazon Elastic Kubernetes Service (Amazon EKS) is used by organization in their most sensitive and mission-critical applications. This session focuses on how Amazon EKS networking works with an Amazon VPC and how to expose your Kubernetes application using Elastic Load Balancing load balancers. It also looks at options for more efficient IP address utilization.
Learn more about re:Invent 2020 at bit.ly/3c4NSdY
Subscribe:
More AWS videos bit.ly/2O3zS75
More AWS events videos bit.ly/316g9t4
#AWS #AWSEvents

[@ramkundala4925]

Great mental model builder

[@47lokeshkumar74]

Nice

[@tailor-mademedia1406]

This is cool, Ikenna.
I wonder if you have a similar schematic for an EKS-Fargate integration. Some potential clients may want to go serverless. If I'm not mistaken, the goal is to lock down all the de-coupled assets in the container and eliminate any routing out to the internet.
Then, leverage the architecture to render images/documents internally.
Also, wouldn't Fargate interact with the ENIs based on the config within the Fargate profile?
Lastly, would load balancing from EKS be East-West to Fargate and Fargate to the private subnet(s) be North-South?

[@pm71241]

Aside from setting up a cluster-external group of EC2 instances to proxy traffic into the cluster, is there any other way to preserve original Internet client IP for TCP (not HTTP(s)) connections through the Global Accelerator?
You can only point the GA on 4 different targets, right? ... ALB, NLB, EC2-instance or Elastic IPs.
Of those 4 only EC2-instance targets will preserve the client-IP. (though the ALB will carry it as an X-forwarded-for header).
So if you have a plain TCP connection what's the recommended way of getting it into the EKS cluster from the GA without losing the client-IP?