Do ALB and Fargate get Nitro's native encryption-in-transit?

I would generally recommend controlling encryption explicitly in situations where it's considered important to have encryption.

One practical point I'd like to add to the advice offered by others is that when an ALB or NLB is configured with a target group set to use TLS, the load balancer won't validate the target's TLS certificate in any way. The load balancer will accept self-signed certificates just as well as ones issued by a public CA, and it won't care if the certificate is expired or if the name is "localhost", an IP address, or anything else generally not acceptable.

The reasoning is that the physical and logical layer security measures in VPCs are a massively more effective defence against man-in-the-middle attacks than a strategy relying on authenticating with TLS certificates based on the expectation that their private keys would be kept secret for the one or more years that the certificate is valid, despite having to be stored in a file on a virtual server's disks, included in backups, possibly exported inadvertently by operators, and so on.

This is documented here for ALBs but also applies to NLBs: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#target-group-routing-configuration

This generally makes it effortless and maintenance-free simply to enable TLS encryption for connections between ALBs/NLBs and their targets, without having to consider certificate issuance or renewals. Explicitly enabling TLS also ensures that traffic is always encrypted in transit for the entire distance between the AWS resource where one end of the TLS connection is configured (like your ALB), all the way to the middleware or operating system layer on the EC2 instance where TLS is set to be terminated. Any middleware/application components that might take an interest would also see connections arriving over TLS instead of cleartext HTTP.

1. Traffic from ALB to EC2 is not encrypted by default. In the majority of systems, it's enough to have traffic encrypted only between the end-user and the Load Balancer, then traffic between the Load Balancer and the EC2 instance is not encrypted in order to offload EC2 CPU. If you need end-to-end encryption, your EC2 must also listen to the HTTPS port. Here is an article how to implement this: https://faun.pub/end-to-end-ssl-encryption-with-aws-application-load-balancer-b43db918bd9e

2. No. The same as the previous case

Hello,

By default, traffic is automatically encrypted at the physical layer between the following Nitro instance types: C5n, G4, I3en, M5dn, M5n, P3dn, R5dn, and R5n but traffic isn't encrypted when it's routed through a transit gateway, load balancer, or similar intermediary according to this documentation: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit

This link explains about some of the ways to achieve encryption in transit for various scenarios: https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/security-network.html#security-network-encryption