Políticas de Control de Servicios en AWS para optimizar costos

De acuerdo con el enfoque FinOps as Code (FaC) uno de los mecanismos para alcanzar los objetivos de automatización de procesos de FinOps dentro de la nube. Existen 3 tipos de políticas:

Cada una de las políticas tienen un objetivo diferente como control, transparencia, y estimación precisa de costos, es posible que no todas las políticas sean aplicables, lo recomendable es validar cuáles de ellas se ajustan a las necesidades de la organización, al igual que las fases del ciclo de vida de FinOps, no es necesario implementarlas de forma seriada es mejor ejecutarlas de simultáneamente para obtener mejores resultados.

Dentro de AWS, es posible implementar de los tres tipos de políticas descritas anteriormente, aunque para este ejercicio ejecutaremos una política de bloqueo, para evitar el despliegue de instancias "costosas" en relación con el objetivo establecido, en el ambiente "test" que está construido como una cuenta vinculada a nuestra cuenta root o cuenta principal.

¿Cuáles son los requisitos previos para ejecutar?

1. Tener las cuentas organizadas en AWS Organizations
2. Activar las políticas de tipo "Políticas de Control de Servicios", para hacerlo, ingresa a AWS Organizations, y seleccionar Políticas en el panel izquierdo

Dentro de este panel, tendremos un listado de políticas admitidas, algunas de ellas están habilitadas y otras no.

Si las Políticas de Control de Servicios, se encuentran inhabilitadas , sólo debemos dar click y habilitar las políticas, una vez que ejecutemos este paso es posible crear este tipo de políticas.

Ahora que las hemos habilitado, podemos iniciar a crearlas, si retomamos un poco lo que comentamos al inicio.

El objetivo es crear una política para detener el despliegue de instancias costosas para las tareas correspondientes al ambiente de pruebas, específicamente, se definieron las instancias pertenecientes a las familias: r5 (ofrecen memoria adicional por CPU virtual), p3 (ideales para ML y HPC),y, g4 (acelera procesos de ML) en el ambiente "test" que es una cuenta vinculada que aloja este ambiente

¿Por qué se decidió bloquear estas instancias en específico y en este ambiente?
Durante los últimos meses, se detectaron picos de costos en el ambiente de pruebas por instancias que se encendieron y no se apagaban en los tiempos definidos o se trataban de instancias sobre-aprovisionadas para las tareas asignadas, como una buena práctica, se decidió bloquear estas instancias, y en el futuro se planea revisar la política para validar estas configuraciones.

Dentro de políticas de AWS Organizations, damos click en crear política:

Escribimos un nombre de la política y redactamos una breve descripción de la política creada. Dentro del cuadro de código, colocamos el contenido de la política:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringLike": {
          "ec2:InstanceType": [
            "r5.*",
            "p3.*",
            "g4.*"
          ]
        },
        "StringEquals": {
          "ec2:ResourceTag/Environment": "Test"
        }
      }
    }
  ]
}

Lo que nos indica este código, es denegar que instancias r5, p3, y g4 corran en el ambiente test, sin una condición adicional.

Ahora damos click en crear política, el siguiente paso es asignarla a una cuenta, en este caso la cuenta de test, para hacerlo, una vez que se crea la política, damos click en ella y nos dirigimos hacia la pestaña "Destinos" y damos click en adjuntar o asociar una política y seleccionamos la cuenta en la o las que deseamos que se aplique la política, en mi caso he seleccionado test

Por último, lo revisamos dentro de la consola de políticas:

Ahora, para obtener una validación más concreta entramos a la cuenta de test para intentar crear una instancia EC2 dentro de estas familias de las que hemos bloqueado:

¡No logramos lanzar la instancia!🥳 Eso quiere decir que nuestra política ha sido aplicada correctamente y con esto podremos tener un mayor control de los costos por la creación de políticas de bloqueo de este tipo de instancias en el ambiente.

Ojo, como nota, este tipo de instancia fue revisada a nivel organizacional, y todos/as estuvimos de acuerdo ya que no afectaba las funcionalidades o procesos tecnológicos, pero puede ser de otro tipo de políticas en tu proyecto o compañía 😉