Which solution meets these requirements and is MOST secure?
Configure a public Application Load Balancer (ALB) with multiple redundant Amazon EC2 instances in public subnets. Configure Amazon CloudFront to deliver HTTPS content using the public ALB as the origin.
Configure a public Application Load Balancer with multiple redundant Amazon EC2 instances in private subnets. Configure Amazon CloudFront to deliver HTTPS content using the EC2 instances as the origin.
Configure a public Application Load Balancer (ALB) with multiple redundant Amazon EC2 instances in private subnets. Configure Amazon CloudFront to deliver HTTPS content using the public ALB as the origin.
Configure a public Application Load Balancer with multiple redundant Amazon EC2 instances in public subnets. Configure Amazon CloudFront to deliver HTTPS content using the EC2 instances as the origin.
Explanations:
Using a public ALB with EC2 instances in public subnets exposes the application layer directly to the internet, increasing security risks. Additionally, using the ALB as the origin in CloudFront can introduce latency.
Configuring EC2 instances in private subnets with a public ALB does not allow for direct access to the instances, but this setup does not utilize CloudFront optimally, as it should have used the ALB as the origin for enhanced security and better architecture.
This option places the EC2 instances in private subnets for security and uses a public ALB to handle incoming requests, with CloudFront using the ALB as the origin. This setup ensures that the web layer is not directly exposed to the internet, thus enhancing security while still allowing low-latency content delivery through CloudFront.
Using a public ALB with EC2 instances in public subnets exposes the application directly to the internet, which is less secure. Additionally, CloudFront should be using the ALB as the origin, not the EC2 instances directly, to optimize delivery and security.