AWS para MSP: gestión de Amazon Web Services para tus clientes

Según el informe «State of the MSP» de Kaseya de 2026, los servicios en la nube y de alojamiento figuran entre las principales fuentes de ingresos para el 34 % de los MSP. Amazon Web Services es la plataforma dominante que sustenta una parte significativa de esa carga de trabajo.

La gestión de AWS para los clientes difiere de la gestión interna. Eres responsable de entornos sobre los que no tienes un control total, de estructuras de facturación que requieren una atención constante para evitar sorpresas en los costes y de configuraciones de seguridad que cambian a medida que crecen los clientes. Sin el enfoque y las herramientas adecuadas, la gestión de AWS para los clientes puede convertirse en uno de los servicios más exigentes desde el punto de vista operativo que ofrece un MSP.

Esta guía aborda lo que los MSP deben saber para gestionar de forma rentable los entornos de los clientes de AWS: control de costes, configuración de seguridad, estrategia de copias de seguridad y los escollos operativos que hacen que AWS resulte más complicado de lo que parece. La plataforma de Kaseya es utilizada por MSP de más de 170 países para gestionar precisamente estos entornos, lo que nos permite tener una visión clara de en qué aspectos la gestión de clientes de AWS funciona y en cuáles falla.

Por qué los MSP gestionan entornos de AWS

La mayoría de los clientes de pymes y del mercado medio que se pasan a una infraestructura en la nube acaban optando por AWS. A algunos les orientó un consultor. Otros necesitaban una aplicación específica que lo requería. Muchos simplemente se decantaron por AWS debido a su presencia en el mercado. Sea cual sea el motivo, el resultado es el mismo: la gestión de AWS forma ahora parte del entorno estándar del cliente que deben tener en cuenta managed services .

Tres factores contribuyen al crecimiento de esta línea de servicios.

Alojamiento de aplicaciones. Los clientes ejecutan aplicaciones de negocio, servidores web, bases de datos y entornos de desarrollo en instancias de EC2 y managed services RDS y Lambda. La gestión de estos elementos es tan necesaria desde el punto de vista operativo como la de los servidores locales.

Almacenamiento y copias de seguridad. Los clientes almacenan datos en buckets de S3, utilizan volúmenes EBS conectados a instancias de cómputo y recurren cada vez más a AWS como parte de su arquitectura de copias de seguridad. Saber qué está protegido y qué no, y cómo es el proceso de recuperación, es una responsabilidad fundamental de los MSP.

Requisitos de cumplimiento normativo. Los clientes sujetos a regulación en los sectores sanitario, financiero y público suelen tener cargas de trabajo en AWS que deben cumplir las mismas normas que la infraestructura local. Las normas HIPAA, PCI DSS y CMMC se aplican a los entornos alojados en AWS cuando estos gestionan datos sujetos a dichas normas.

Un proveedor de servicios gestionados (MSP) típico que gestione entre 20 y 50 clientes se encontrará con que los entornos de AWS estarán presentes en la mayoría de esas cuentas en un plazo de dos o tres años, según la trayectoria de adopción actual. Ahora es el momento adecuado para incluir esto en tus contratos de servicio, antes de que un cliente te pregunte por qué su bucket de S3 quedó expuesto.

Comprender el modelo de responsabilidad compartida de AWS

El concepto más importante en la gestión de AWS es el modelo de responsabilidad compartida. El error más habitual que cometen los MSP es explicárselo mal a los clientes o no explicárselo en absoluto.

AWS es responsable de la seguridad de la nube: la infraestructura física, el hipervisor, la estructura de red y la infraestructura de servicios gestionados. El cliente, junto con su proveedor de servicios gestionados (MSP), es responsable de la seguridad dentro de la nube. Esto incluye las actualizaciones del sistema operativo, la configuración de red (grupos de seguridad, NACL, diseño de VPC), la gestión de identidades y accesos, el cifrado de datos y la seguridad a nivel de aplicación.

Las implicaciones prácticas son claras:

• Una instancia de EC2 que ejecute un sistema operativo sin parches es responsabilidad del cliente, no de AWS.
• Un depósito de S3 mal configurado para el acceso público es responsabilidad del cliente.
• Los roles de IAM con permisos excesivos son responsabilidad del cliente.
• Las vulnerabilidades de las aplicaciones que se ejecutan en la infraestructura de AWS son responsabilidad del cliente.

Los administradores de sistemas que gestionan entornos de AWS deben aplicar parches a los sistemas operativos de las instancias EC2 del mismo modo que lo harían con los servidores locales. VSA admite la aplicación de parches del sistema operativo y de terceros para instancias de Windows y Linux, incluidas las instancias EC2 en las que se ha implementado el agente de VSA, utilizando la misma automatización basada en políticas que se emplea para los terminales locales.

Esto también es importante en lo que respecta a los términos del contrato. Si tu managed services no define explícitamente quién es responsable de la aplicación de parches del sistema operativo y de la gestión de identidades y accesos (IAM) para las cargas de trabajo alojadas en AWS, existe una laguna en materia de responsabilidad. Documenta esto claramente en IT Glue adapta la redacción de tu SLA antes de que un incidente te obligue a abordar el tema.

Gestión de costes de AWS: dónde pierden margen los MSP

La facturación de AWS es compleja. Sin una gestión adecuada, resulta costosa. Los problemas de costes más habituales en los entornos de AWS gestionados por MSP se pueden clasificar en cuatro categorías.

Errores en el dimensionamiento adecuado. Los clientes sobreaprovechan las instancias de EC2 durante la implementación inicial y nunca reducen su tamaño. Un cliente que utiliza una instancia t3.xlarge para una carga de trabajo que solo requiere una t3.medium está pagando aproximadamente el doble del coste de computación necesario. Las revisiones periódicas del dimensionamiento adecuado, con el apoyo de AWS Cost Explorer y las métricas de CloudWatch, permiten detectar estas oportunidades antes de que mermen el margen de beneficio.

Infrautilización de instancias reservadas y planes de ahorro. AWS ofrece descuentos de hasta el 72 % en instancias reservadas y planes de ahorro en comparación con los precios bajo demanda. Los proveedores de servicios gestionados (MSP) que administran entornos de AWS deben identificar qué cargas de trabajo son lo suficientemente estables como para comprometerse con los precios reservados y, a continuación, adquirir las reservas en nombre del cliente o aconsejarle que lo haga como parte de una revisión trimestral formal.

Recursos desasignados. Es frecuente que los clientes dejen en funcionamiento volúmenes de EBS, direcciones IP elásticas y equilibradores de carga después de haber eliminado los recursos asociados. Estos recursos no aportan ningún valor operativo, pero siguen generando costes. Una revisión mensual de la optimización de costes debería incluir comprobaciones de recursos desasignados. Se tarda menos de una hora y, a menudo, permite detectar cientos de dólares en gastos innecesarios cada mes.

Costes de salida. La transferencia de datos fuera de AWS se factura a tarifas que pueden pillar por sorpresa a los clientes. Las aplicaciones con un elevado tráfico de salida, los sistemas de copia de seguridad que transfieren datos a otros destinos y las cargas de trabajo relacionadas con la CDN pueden generar costes de salida que superen los costes de computación. Es importante conocer el perfil de salida del entorno de cada cliente antes de que reciba la factura.

La oportunidad que ofrece el modelo MSP en este caso es real. Considerar la gestión de costes de AWS como un servicio de asesoramiento proactivo genera un valor real para el cliente y favorece las conversaciones comerciales sobre la ampliación managed services . Un proveedor de servicios gestionados (MSP) que detecta un gasto evitable de 500 dólares al mes en AWS se convierte en un asesor de confianza. Quien no lo detecte, se convierte en la persona que ha permitido que el cliente malgaste dinero.

Configuración de seguridad en entornos de clientes de AWS

AWS ofrece sólidas funciones de seguridad, pero es necesario configurarlas correctamente. Las brechas de seguridad más habituales en los entornos de AWS gestionados por MSP siguen un patrón predecible.

Concesión excesiva de permisos en IAM. El principio del mínimo privilegio es más difícil de aplicar en AWS que en un entorno de directorios tradicional, ya que las funciones, las políticas y los límites de permisos de IAM son más complejos de auditar. Es habitual encontrar usuarios y funciones de servicio con acceso de administrador cuando en realidad solo necesitan permisos específicos para el servicio. Las revisiones periódicas de los accesos de IAM y la herramienta AWS IAM Access Analyzer permiten detectar estas deficiencias antes de que se conviertan en vectores de seguridad.

Depósitos públicos de S3. Por defecto, los depósitos de S3 son privados, pero los cambios en la configuración o las plantillas de infraestructura como código pueden exponerlos públicamente sin querer. AWS ofrece controles de acceso público tanto a nivel de depósito como de cuenta. Activarlos a nivel de cuenta evita la exposición accidental.

Falta el cifrado en reposo. Los volúmenes EBS, los buckets de S3 y las instancias de RDS deben tener el cifrado activado. AWS KMS ofrece un servicio de cifrado gestionado por claves. Activar el cifrado predeterminado a nivel de cuenta garantiza que los nuevos recursos se cifren, salvo que se anule explícitamente esta configuración, lo cual constituye una base de referencia sensata para cualquier entorno de cliente que maneje datos empresariales.

Grupos de seguridad permisivos. Los grupos de seguridad que permiten el acceso entrante sin restricciones (0.0.0.0/0) en los puertos 22 (SSH) o 3389 (RDP) exponen las instancias directamente a Internet. Estos se detectan en casi todas las evaluaciones de seguridad de AWS y son fáciles de corregir. Deben cerrarse como medida básica desde el primer día en cualquier nuevo proyecto con un cliente.

CloudTrail no está habilitado. AWS CloudTrail es el registro de auditoría de la actividad de las API de AWS. Sin él, la investigación de incidentes se ve muy limitada. CloudTrail debe estar habilitado en todas las regiones, y los registros deben almacenarse en un bucket de S3 independiente y con acceso restringido. Se trata de un requisito básico ineludible para cualquier entorno en el que su MSP sea responsable de la seguridad.

Copias de seguridad y recuperación en AWS

El modelo de responsabilidad compartida implica que AWS no realiza copias de seguridad de la mayoría de los recursos de forma predeterminada. Las instancias de EC2, los volúmenes de EBS y las bases de datos de RDS requieren una configuración explícita de las copias de seguridad.

AWS Backup es el servicio nativo de AWS para la gestión de copias de seguridad, compatible con EC2, EBS, RDS, DynamoDB, EFS y otros servicios. Ofrece gestión centralizada de políticas, copias entre regiones y cuentas, e informes de cumplimiento normativo de las copias de seguridad. Para los proveedores de servicios gestionados (MSP) que administran múltiples entornos de AWS de sus clientes, la función de gestión entre cuentas (disponible a través de AWS Organizations) permite gestionar las políticas de copia de seguridad en todas las cuentas de los clientes desde una consola central.

Lo que AWS Backup no cubre: los datos de S3 (protegidos mediante el control de versiones y la replicación, en lugar de mediante copias de seguridad tradicionales), las aplicaciones SaaS que se ejecutan en la infraestructura de AWS y las copias de seguridad con consistencia de aplicaciones para aplicaciones complejas de varios niveles. Datto BCDR puede complementar a AWS Backup en aquellas cargas de trabajo en las que se requiera la capacidad de recuperación a nivel de imagen o un RTO más rápido.

Pruebas de recuperación. Aquí se aplica el mismo principio que en las copias de seguridad locales: una copia de seguridad que no se ha probado no es una copia de seguridad. AWS Backup admite pruebas de restauración con validación automatizada. Esto debería formar parte del contrato de servicio gestionado de cualquier entorno de AWS en el que la capacidad de recuperación sea un compromiso contractual. Prográmala, ejecútala y documenta los resultados en IT Glue.

Supervisión de entornos de AWS a gran escala

AWS CloudWatch ofrece supervisión nativa de los recursos de AWS: métricas, registros, alarmas y paneles de control. Para los proveedores de servicios gestionados (MSP) que gestionan múltiples entornos de AWS de sus clientes, el reto consiste en integrar la supervisión de AWS con la supervisión de entornos locales y de otras nubes en una vista operativa unificada.

La supervisión basada en agentes de VSA abarca las instancias de EC2 en las que se ha implementado el agente, ofreciendo las mismas capacidades de supervisión de puntos finales, gestión de alertas y automatización que se utilizan para los servidores locales. Para la supervisión de AWS a nivel de infraestructura (estado de los servicios, alertas de facturación, eventos de CloudTrail), las herramientas nativas de AWS o las integraciones de supervisión específicas de AWS complementan al agente de VSA.

El objetivo es disponer de una única vista operativa. El centro de operaciones de red (NOC) de un proveedor de servicios gestionados (MSP) no debería tener que alternar entre la consola de VSA y las consolas individuales de AWS de cada cliente para conocer el estado del entorno gestionado. Cada cambio de contexto aumenta la latencia en la respuesta a incidentes y aumenta el riesgo de que pasen desapercibidas algunas deficiencias.

Cómo ayuda Kaseya a gestionar los clientes de AWS

Datto RMM / VSA se encarga de la aplicación de parches, la supervisión y la automatización del sistema operativo en servidores que ejecutan Windows o Linux. Se instala una sola vez y se gestiona junto con los terminales locales desde la misma consola.

Datto BCDR complementa a AWS Backup para aquellas cargas de trabajo que requieren una recuperación a nivel de imagen, virtualización instantánea o un RTO más rápido que el que ofrece la restauración nativa de AWS.

IT Glue almacena la documentación de los entornos AWS de los clientes: arquitectura de VPC, estructura de IAM, configuraciones de grupos de seguridad, guías de recuperación ante desastres y credenciales de acceso, con aislamiento por cliente y acceso controlado.

Compliance Manager GRC supervisa la implementación de controles y genera pruebas de cumplimiento para clientes con cargas de trabajo de AWS reguladas (HIPAA, PCI DSS, CMMC), tanto en entornos locales como en la nube.

Kaseya Intelligence AWS: operaciones autónomas en la nube

La gestión de entornos de AWS implica lidiar con cambios constantes: nuevas instancias, operaciones de escalado, desviaciones en la configuración, alertas de seguridad de AWS Security Hub y tareas de copia de seguridad que deben validarse en todas las regiones. La carga de trabajo manual que supone mantenerse al día con todo ello a gran escala es considerable.

Kaseya Intelligence, el motor de inteligencia artificial que impulsa Kaseya 365, automatiza la fase de respuesta. En lugar de alertar a un técnico sobre un hallazgo y esperar a que se tomen medidas, se encarga de ejecutar las siguientes acciones: aplicar parches, aislar el sistema, comprobar que las copias de seguridad estén completas y validar el resultado. Para los proveedores de servicios gestionados (MSP) que administran entornos de AWS para múltiples clientes, ese ciclo de ejecución es lo que evita que la fatiga por alertas se convierta en una brecha de seguridad.

Descubre Kaseya Intelligence