Resolver conflictos con mysql-devel en AWS Linux Amazon 2018.03

logo de aws cloud

Problemas al instarl mysql-devel en una Linux Amazon 1? Yo también los he tenido. Mi EC2 es una Linux Amazon 1 con estas características.

uname -ar
Linux ip-10-0-101-105 4.14.193-113.317.amzn1.x86_64 #1 SMP Thu Sep 3 19:08:08 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
cat /etc/system-release
Amazon Linux AMI release 2018.03

La distribución Linux Amazon 1 está ya en EOL, no debería estar usándola pero como por otro lado en AWS Beanstalk aún no hay una versión 8.1 de PHP pues así estamos.

The Amazon Linux AMI ended its standard support on December 31, 2020 and has entered a maintenance support phase. A list of supported and unsupported packages along with additional information is now available here.

https://aws.amazon.com/es/blogs/aws/update-on-amazon-linux-ami-end-of-life/

Continue reading “Resolver conflictos con mysql-devel en AWS Linux Amazon 2018.03”

Securizar S3 bucket website endpoint

logo de aws cloud

Hace algunas semanas me llegó este mensaje por parte de AWS

We are writing to notify you that you have configured your S3 bucket(s) to be publicly accessible, and this may be a larger audience than you intended. By default, S3 buckets allow only the account owner to access the contents of a bucket; however, customers can configure S3 buckets to permit public access. Public buckets are accessible by anyone on the Internet, and content in them may be indexed by search engines. We recommend enabling the S3 Block Public Access feature on buckets if public access is not required. S3 bucket permissions should never allow “Principal”:”*” unless you intend to grant public access to your data. Additionally, S3 bucket ACLs should be appropriately scoped to prevent unintended access to “Authenticated Users” (anyone with an AWS account) or “Everyone” (anyone with Internet access) unless your use case requires it. For AWS’s definition of “Public Access,” please see The Meaning of “Public” [1].

Más aburrido que ver “Los lunes al sol” doblado al iraní. Lo sé.

Continue reading “Securizar S3 bucket website endpoint”

Un WordPress en AWS – ¿Cómo implementarlo? – Parte 3

logo de aws cloud

CloudFront

Sobre el tema de la seguridad hablé un poco sobre esto en el siguiente post. Digamos que sería seguridad a nivel de aplicación, por decirlo de alguna manera. Pero luego queda el problema de como queremos lidiar con los ataques diarios que va a sufrir un WordPress. Algunos como los ataques de fuerza bruta o XMLRPC los traté en el post que comenté en link anterior. Pero aún así me faltaba una herramienta para poder mitigar esos ataques, banear los agresores, etc. Entonces comenté que posiblemente habían opciones rápidas de implementar (a priori) como Sucuri. Sin embargo, el propósito de estos posts y mi intención inicial era profundizar sobre el conocimiento de la infraestructura y servicios de AWS para albergar un WordPress. En este sentido aquí es donde entra CloudFront. Y como este post iba de la infraestructura pues voy a explicar (brevemente) el cambio en la infraestructura para poder implementar la CDN, cambios a realizar y alguna medición de rendimiento para poder ver el efecto tiempo después.

Continue reading “Un WordPress en AWS – ¿Cómo implementarlo? – Parte 3”

Route53, cuándo escoger Alias?

logo de aws cloud

El alias es un tipo de registro especial dentro de nuestra zona pública o privada dentro de Route53. El alias es un concepto que escapa de los fundamentos clásicos de DNS y solo atañe dentro de la nube de AWS.

Al final, ese alias que utilizamos en nuestra zona no dejará de ser un A o un CNAME de cara al resto de servidores DNS. En vez de una dirección IP o un nombre de dominio, un registro alias contiene un puntero a una distribución de CloudFront, un entorno de ElasticBeanstalk environment, un ELB ya sea Classic, Application o Network, un bucket de S3 configurado como web hosting estático o otro registro Route53 en la misma zona hosteada.

Continue reading “Route53, cuándo escoger Alias?”

Un WordPress en AWS – ¿Cómo implementarlo? – Parte 1

logo de aws cloud

Siempre he utilizado Wodpress como una especie de bloc de notas menos un breve tiempo que me moví a Evernote. Tiempo después, quise recuperar el blog. Por entonces ya tenía curiosidad de probar algo en el cloud y el blog era una forma útil de hacerlo. Utilizaba Linode por entonces.

Si estáis interesados en saber como podéis desplegar un WordPress en AWS quizá este post os ayude en algo.

En este post hablaré sobre todo de la infraestructura, más que del propio WordPress en si mismo.

Continue reading “Un WordPress en AWS – ¿Cómo implementarlo? – Parte 1”

AWS Best Practice – VPC Endpoints

logo de aws cloud

Una buena práctica es evitar que nuestro tráfico abandone la red de AWS, siempre que sea posible. Con VPC Endpoints podemos lograrlo.

Un Punto de conexión VPC le permite conectar de forma privada su VPC a los servicios de AWS compatibles y a servicios de punto de enlace de la VPC basados en AWS PrivateLink sin necesidad de una gateway de Internet, un dispositivo NAT, una conexión de VPN o una conexión de AWS Direct Connect. Las instancias de su VPC no necesitan direcciones IP públicas para comunicarse con los recursos del servicio. El tráfico entre su VPC y el servicio no sale de la red de Amazon.

Continue reading “AWS Best Practice – VPC Endpoints”

Redirigir HTTP a HTTPS en Beanstalk sin LoadBalancer

logo de aws cloud

La forma más común de hacer las redirecciones de HTTP a HTTPS en entornos en producción pasa por añadir una regla en el ELB o ALB y de esta forma todo nuestro tráfico es redirigido a nuestra aplicación sin tener que configurar nada dentro de nuestro container o instancia.

¿Pero y si no tenemos ELB/ALB? En mi caso, solo tengo una instancia para este blog porque no tiene sentido asumir el coste del balanceador y dado que muchos posts en google hablan sobre como hacerlo con ELB/ALB vamos a ver como se hace si no disponemos de esta pieza.

Continue reading “Redirigir HTTP a HTTPS en Beanstalk sin LoadBalancer”