Reemplazo de SFTP por S3?

Con toda esta tendencia de migración hacia la nube, varios clientes que tienen sus instancias en la nube me fueron solicitando instalarlos servicios de SFTP para la transferencia de archivos para reemplazar los que tienen on-premise, el dilema es: Aun conviene instalar servicios de SFTP?

No voy a hacer un típico pros y contras porque cada caso de uso y flujo de trabajo es distinto. Mi idea es pensar un poco la situación, y cada uno saque lo que le sirve del post.

Cuando instalamos un servicio de SFTP, hay que hacerlo sobre un servidor, ya sea Windows, o ya sea Linux. Una vez hecho esto, hay que crear los usuarios locales o del directorio LDAP que prefieran, asignarle sus permisos correspondientes y asignarle un espacio en un disco del servidor para almacenar lo que los distintos usuarios van subiendo.

Hasta el momento, esta era la operatoria normal de uno de los clientes donde decidimos reemplazar el servicio por S3, pero porque?

En un servidor, la disponibilidad de los archivos depende de la salud del sistema operativo, de sus parches, que el espacio en disco asignado alcance o incrementarlo cada vez que sea necesario, y lo mas importante, en la nube, un disco de bloque es MAS CARO que un storage de Objeto (S3 ejemplo, o Blob en Azure)

Ejemplo:

Disco AWS EBS: General Purpose GP2 USD 0,1/GB

S3: Almacenamiento Standard USD 0,023/GB en los primeros 50 GB.

Como verán, no hace falta que les saque cuentas para entender la diferencia de precios, ademas pensemos que:

  • Con un almacenamiento de objeto como S3 no tenemos que preocuparnos tanto por la disponibilidad del servicio
  • El espacio utilizado porque es ilimitado
  • Pago solo por uso, no por el espacio total alocado como es el en caso de un EBS.
  • Con unos pocos clicks, es posible replicar el bucket entero a otra región.
  • Integración nativa con miles de servicios, tanto de AWS, como de terceros.
  • Es posible aplicar políticas de acceso en una gran variedad.
  • Versionado
  • Políticas de ciclo de vida
  • Y miles de ventajas mas.

Por ende, al momento de resolver este dilema, fuimos por S3 y como lo hicimos?

  • Creamos los buckets necesarios para cada caso de uso.
  • Creamos usuarios de IAM solo con acceso programático
  • A dichos usuarios les aplicamos políticas para que cada uno acceda al su bucket correspondiente y no pueda ver el resto.
  • Distribuimos las access keys y secret keys correspondientes y listo. Esto fue todo.

Como reemplazo de FileZila que usaban los clientes para acceder al bucket y subir archivos, usamos S3 browsers como Cyberduck o WinSCP (SI, ACEPTA S3), ya que por AWS CLI no es tan amigable para un usuario final.

DIAGRAMA:

POLÍTICAS PARA LOS USUARIOS:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": "arn:aws:s3:::nombre-del-bucket"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:GetObject",
                "s3:GetObjectAcl",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::nombre-del-bucket/*"
        }
    ]
}

WIN SCP:

CYBERDUCK:

Y eso es todo gente!… Espero que a alguien le haya servido.

Luego, al momento de descargar la informacion del lado del servidor donde necesiten esa información, las posibilidades son infinitas, pueden consumir la informacion directamente desde el S3, o programar una tarea con AWS-CLI para descargar los archivos cuando lo necesiten.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

Close Bitnami banner
Bitnami