Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

812
Views
Cloudfront a s3 redirigir al subdominio dando error de Acceso denegado

Tengo una configuración de sitio web estático en aws s3 usando Cloudfront y la ruta 53. Actualmente puedo acceder correctamente al sitio a través de https://www.example.com

Estoy tratando de redirigir http://example.com y https://example.com a https://www.example.com ( http://www.example.com ya redirige correctamente).

Parece que la única forma de configurar esto es con dos distribuciones frente a la nube y dos cubos s3 (y dos registros de alias A en la ruta 53).

Configuré un cubo de example.com para redirigir a www.example.com usando el protocolo https.

Una de las distribuciones de cloudfront apunta al depósito www.example.com con redirección de http a https y el objeto raíz predeterminado es index.html y el nombre de dominio alternativo es www.example.com . Las otras distribuciones de cloudfront apuntan al depósito de example.com con no hay redireccionamiento de http a https y nada establecido en el objeto raíz predeterminado (también probé index.html pero eso no ayudó) y el nombre de dominio alternativo como example.com .

Ambas distribuciones usan la misma configuración de certificado en ACM que cubre *.example.com y example.com (otras configuraciones usan los valores predeterminados).

No tengo claro por qué recibo un error de acceso denegado cuando intento acceder a través de https://example.com (o http://example.com ) y qué problema tiene mi configuración.

 <Error> <Code>AccessDenied</Code> <Message>Access Denied</Message> <RequestId>....</RequestId> <HostId>.....</HostId> </Error>

Actualización con más detalles sobre los cubos:

Como se menciona a continuación en los comentarios, el depósito s3 del dominio raíz redirige correctamente sin frente a la nube. Al volver a agregar Cloudfront, reaparecen los errores de acceso denegado.

ambos cubos tienen acceso público, es decir Block all public access está desactivado.

La política de depósito para ambos se establece en:

 { "Version": "2012-10-17", "Id": "Policy1595518880784", "Statement": [ { "Sid": "Stmt1595518834954", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::example.com/*" } ] }

y para el depósito de subdominio tiene un ..:::www.example.com/* en el recurso.

El origen de los depósitos que se usa en cloudfront es example.com.s3.amazonaws.com y www.example.com.s3.amazonaws.com

over 4 years ago · Santiago Trujillo
3 answers
Answer question

0

El problema está en la distribución frente a la nube frente al depósito de redireccionamiento. Aunque el autocompletado del origen para el depósito www en cloudfront funciona bien, no funciona para el depósito de redirección. En su lugar, debe agregar esto manualmente y no debe ser del formato s3 rest api sino de la versión del sitio estático. Entonces, en su lugar, ingrese algo del formulario example.com.s3-website-us-east-1.amazonaws.com Esto parece un poco como un error en la consola de aws y no debería autocompletar los nombres de depósito no válidos frente a los depósitos de redirección de s3 .

over 4 years ago · Santiago Trujillo Report

0

Para solucionar los errores de acceso denegado, debe saber si el nombre de dominio de origen de su distribución es un punto final de sitio web de S3 o un punto final de API REST de S3. Prueba esto:

  1. Abra la consola de CloudFront.
  2. Elija su distribución de CloudFront y luego seleccione Configuración de distribución.
  3. Elija la pestaña Orígenes y Grupos de origen.
  4. Revise el nombre de dominio en Ruta y nombre de dominio de origen y, a continuación, determine el tipo de extremo según el formato del nombre de dominio.

Tenga en cuenta que los extremos de la API REST utilizan este formato:

AWSDOC-EXAMPLE-BUCKET.s3.amazonaws.com

Los puntos finales del sitio web utilizan este formato:

AWSDOC-EXAMPLE-BUCKET.s3-website-us-east-1.amazonaws.com

Además, no olvide que si su distribución utiliza un punto final de sitio web, verifique los siguientes requisitos para evitar errores de acceso denegado:

  • Los objetos en el cubo deben ser de acceso público.
  • AWS Key Management Service (AWS KMS) no puede cifrar los objetos del depósito.
  • La política del depósito debe permitir el acceso a s3:GetObject.
  • Si la política del depósito otorga acceso público, la cuenta de AWS propietaria del depósito también debe ser propietaria del objeto.
  • Los objetos solicitados deben existir en el depósito.
  • El acceso público al bloque de Amazon S3 debe estar deshabilitado.
  • Si el Solicitante paga está habilitado, la solicitud debe incluir el parámetro de solicitud de pago.

Finalmente, es posible que desee consultar estas publicaciones:

¿Cómo uso CloudFront para servir un sitio web estático alojado en Amazon S3?

Estoy usando un punto final de API REST de S3 como origen de mi distribución de CloudFront. ¿Por qué recibo errores de acceso denegado 403?

over 4 years ago · Santiago Trujillo Report

0

La razón de esto es que cuando su distribución de CloudFront se conecta a su depósito S3, reenviará el encabezado del Host .

Si su depósito es example.com.s3.amazonaws.com , espera que el encabezado del host sea example.com.s3.amazonaws.com o example.com . Si recibe un encabezado de host de www.example.com , se rechazará porque el depósito S3 no es para ese dominio.

Estos nombres de depósitos deben coincidir exactamente con su nombre de dominio . En este ejemplo, el nombre de dominio es ejemplo.com. Usted aloja su contenido fuera del depósito del dominio raíz (example.com). Creas una solicitud de redireccionamiento para el grupo de subdominios ( www.example.com ). Si alguien ingresa a www.example.com en su navegador, es redirigido a example.com y ve el contenido que está alojado en el depósito de Amazon S3 con ese nombre.

Desafortunadamente, la solución es que está utilizando cubos S3 separados con distribuciones de CloudFront separadas.

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!