Información general

Este documento describe las prácticas recomendadas para la introducción de cambios en las configuraciones de los servicios periféricos de AWS, como CloudFront, Lambda@Edge y AWS WAF. Estos cambios pueden incluir la actualización del código de CloudFront Function, la modificación de la versión ejecutable de una función de Lambda@Edge, la adición de un nuevo comportamiento de caché en CloudFront, la actualización de las reglas de WAF o la habilitación de nuevas características en CloudFront, como HTTP/3. Si tiene configuraciones relativamente estáticas y simples, y prefiere una interfaz de usuario para la administración manual, puede confiar en la consola de AWS. Sin embargo, para las configuraciones más complejas, se recomienda utilizar las canalizaciones de CI/CD para desplegar los cambios en la configuración y las actualizaciones de código de manera controlada.

Canalización de CI/CD

Infraestructura como código (IaaC)

Con las canalizaciones de CI/CD, puede mejorar los ciclos de lanzamiento de software al aumentar la velocidad del desarrollo, ofrecer una mayor calidad del código y reducir los errores humanos con la automatización. Los servicios de periferia de AWS, como CloudFront, y las funciones de periferia se pueden administrar dentro de una canalización de CI/CD con infraestructura como código (IaC). Los recursos periféricos se pueden desplegar con las API (por ejemplo, con la API de CloudFront), con la CLI de AWS o con herramientas de abstracción de nivel superior, como CloudFormation, Terraform y Cloud Development Kit (CDK) de AWS.

IaC basada en CDK

El CDK, basado en CloudFormation, brinda el nivel más alto de abstracción al permitir desplegar los recursos de AWS con un lenguaje de programación. Por ejemplo, las siguientes tres líneas de código de JavaScript pueden desplegar un bucket de S3 con CloudFront como origen:

const myBucket = new s3.Bucket(this, 'myBucket');
new cloudfront.Distribution(this, 'myDist', {
  defaultBehavior: { origin: new origins.S3Origin(myBucket) },
});

Consulte la biblioteca de componentes del CDK para ver los constructos reutilizables que puede incluir en el código del CDK.

Despliegue y orquestación

En la canalización de CI/CD, necesitará un repositorio como AWS CodeCommit para almacenar el código (código de CDK, código de funciones periféricas), una herramienta como AWS CodeDeploy para desplegar la infraestructura y una herramienta de orquestación como AWS CodePipeline para administrar los pasos de la canalización. En esta publicación del blog, se muestra el uso de las herramientas de desarrollo de AWS para desplegar una canalización de CI/CD para CloudFront, pero también puede utilizar las herramientas de CI/CD que prefiera. Al crear una canalización de CI/CD para los servicios periféricos de AWS, considere las siguientes limitaciones:

  • CloudFront, CloudFront Functions y las ACL web de AWS WAF regionales se pueden implementar desde cualquier región de AWS
  • Lambda@Edge y las ACL web de AWS WAF para CloudFront solo se pueden implementar desde la región us-east-1 (Norte de Virginia).
  • Las políticas de Firewall Manager deben implementarse en la cuenta de AWS del administrador de Firewall Manager.

Pruebas y ensayo

Se puede probar la configuración de periferia a diferentes niveles. En primer lugar, puede replicar la infraestructura, como una distribución de CloudFront con una ACL web de AWS WAF, en cuentas de prueba. Esto puede hacerse durante la fase de desarrollo o para ejecutar las pruebas funcionales automatizadas antes de pasar a la producción. Tenga en cuenta que no puede usar dos distribuciones de CloudFront con el mismo CNAME. Por lo tanto, debe diferenciar la configuración de CNAME para el recurso de CloudFront según la fase de CI/CD. Por ejemplo, puede utilizar el nombre de dominio de CloudFront (como xyz.cloudfront.net) para la fase de desarrollo, un CNAME dedicado para el ensayo (como ensayo.www.ejemplo.com) y el CNAME público para el despliegue de la producción (como www.ejemplo.com). También puede diferenciar los controles de seguridad por etapa, como restringir el acceso a IP específicas con AWS WAF para la fase de ensayo.

Después de que su nueva configuración supere las pruebas, puede implementar el enfoque del lanzamiento de valor controlado con la característica de despliegue continuo de CloudFront para poner a prueba el cambio de la producción en una pequeña parte de su tráfico. Con esta característica, puede crear una configuración diferente para la distribución de la producción y enviar solo una parte del tráfico global a ella. Tiene dos opciones para dirigir el tráfico a la nueva configuración: utilizar un encabezado de petición específica, lo cual es útil para las pruebas sintéticas, o utilizar una política ponderada para dirigir un porcentaje configurable de tráfico a la nueva configuración, con la opción de habilitar la fidelidad. En la versión actual de esta característica, solo puede probar cambios en un subconjunto de los parámetros de la configuración de CloudFront. Consulte la documentación para comprender mejor lo que puede poner a prueba con esta característica.

Configuración dinámica

Considere un escenario en el que varios equipos introducen cambios en la configuración de CloudFront, pero un solo equipo administra la canalización de CI/CD para todos los equipos. Por ejemplo, distintos equipos administran microservicios por separado, en el que todos ellos expongan sus API en el dominio principal alojado por una única distribución de CloudFront. Si permite que cada equipo acceda a la configuración completa de la distribución de CloudFront, aumentará el radio de explosión de un único cambio contaminado. Por el contrario, si solo permite que el equipo de CI/CD haga cambios en la distribución de CloudFront, disminuirá la velocidad de desarrollo e iniciará un cuello de botella en el ciclo de vida de lanzamiento. En su lugar, puede generar, de manera dinámica, la configuración a partir de configuraciones parciales propias de cada equipo de microservicios. En una implementación sencilla, cada equipo puede administrar la configuración de su propia ruta (el almacenamiento en caché, las funciones periféricas, etc.) en un archivo basado en texto alojado en un bucket de S3. En la canalización de CI/CD, puede introducir un paso adicional para crear, de manera dinámica, la configuración final de CloudFront con los distintos archivos de configuración parcial.

Despliegue de AWS WAF y AWS Shield

Los servicios Shield y WAF pueden desplegarse, con las mismas herramientas descritas anteriormente, en una canalización de CI/CD.

Sin embargo, se recomienda utilizar AWS Firewall Manager para implementar reglas de WAF y protecciones de Shield por las siguientes ventajas:

  • Facilita la aplicación de la gobernanza de seguridad central, como el despliegue de las reglas centrales en combinación con reglas administradas por equipos de aplicaciones
  • Ofrece un despliegue más rápido, lo cual es crucial para corregir las vulnerabilidades críticas con AWS WAF.
  • Simplifica el despliegue entre cuentas y las canalizaciones de CI/CD heterogéneas, como las heredadas de adquisiciones. Sin embargo, con este enfoque, debe administrar las desviaciones si utiliza una canalización de CI/CD con detección de desviaciones.

Además, puede utilizar una canalización de CI/CD para realizar cambios en las políticas de Firewall Manager desde la cuenta de administrador, las cuales Firewall Manager luego desplegará en toda la organización de AWS, como lo demostró OLX.

Puede utilizar distintas estrategias para el despliegue de las reglas de WAF de forma segura en el entorno de producción. Puede agregar nuevas reglas a una ACL web existente en modo de recuento y, a continuación, cambiarla a modo de bloqueo. Sin embargo, con este enfoque, tiene que prestar atención a la WCU máxima de su ACL web. Otro enfoque es desplegar los cambios en una ACL web de ensayo y probar los cambios en un entorno de ensayo.

Recursos

¿Le resultó útil esta página?

 Comentarios