What should the SysOps administrator do to meet these requirements?
Create an Amazon CloudFront distribution. Configure the S3 bucket as an origin with an origin access identity (OAI). Give the OAI the s3:GetObject permission in the S3 bucket policy.
Configure static website hosting in the S3 bucket. Use Amazon Route 53 to create a DNS CNAME to point to the S3 website endpoint.
Create an Application Load Balancer (ALB). Change the protocol to HTTPS in the ALB listener configuration. Forward the traffic to the S3 bucket.
Create an accelerator in AWS Global Accelerator. Set up a listener configuration for port 443. Set the endpoint type to forward the traffic to the S3 bucket.
Explanations:
Creating a CloudFront distribution allows the S3 bucket to remain private while serving content. The OAI ensures that CloudFront can access the S3 bucket, and with the appropriate S3 bucket policy allowing the OAI permission to retrieve objects, the web application can be served securely without making the S3 bucket public.
Configuring static website hosting in the S3 bucket will expose the bucket to the public internet, which violates the company’s policy against public S3 buckets. Even with Route 53 pointing to the S3 website endpoint, the bucket would still be publicly accessible.
An Application Load Balancer (ALB) cannot directly forward traffic to an S3 bucket because S3 is not a target type for ALB. ALB is designed to route traffic to EC2 instances, containers, or IP addresses, and would require additional services to work with S3, making it an inappropriate choice for directly serving static files.
AWS Global Accelerator is designed to improve the availability and performance of applications by directing traffic through the AWS global network. However, it cannot directly route traffic to S3 buckets, as S3 is not a valid endpoint for Global Accelerator. It would still require an intermediary like an EC2 instance or ALB to serve the content.