Precios, gestión de costos y gobernanza en la nube

Una factura de la nube se construye a partir de unidades de tarificación. El cómputo puede cobrarse por segundo u hora, el almacenamiento por GB·mes y las solicitudes por cada 1000 o millón de operaciones. Las funciones sin servidor suelen combinar un cargo por invocación con el tiempo de ejecución multiplicado por la memoria asignada. Asignar más memoria cambia el cargo por memoria y tiempo.

Relaciona la cantidad con la tarifa

Para una máquina virtual con una tarifa de ejemplo de 0,10 u.m. por hora, un mes de 730 horas cuesta 73 u.m. Ejecutarla durante 10 horas en cada uno de 22 días laborables supone 220 horas y cuesta 22 u.m. Su disco de 100 GB a 0,08 u.m. por GB·mes añade 8 u.m. en cualquiera de los dos casos si permanece aprovisionado todo el mes. El cómputo programado más el almacenamiento conservado suman 30 u.m.

La convención de 730 horas promedia las 8760 horas anuales entre 12 meses; los meses naturales varían. Muchas máquinas virtuales se facturan por segundo con un mínimo de un minuto, mientras que otros productos se facturan por minuto u hora.

La capacidad inactiva también puede costar dinero

La capacidad aprovisionada es la capacidad reservada para tu recurso. Una máquina virtual en ejecución o una base de datos aprovisionada genera cargos por su tamaño y tiempo incluso cuando realiza poco trabajo. Las solicitudes de objetos y las invocaciones de funciones siguen el uso de forma más directa. Un disco aprovisionado se cobra por su tamaño asignado, no solo por los archivos escritos en él.

Detener una instancia de AWS EC2 pone fin a su cargo de cómputo. En Azure, la máquina virtual debe detenerse y desasignarse para que termine la facturación de cómputo. Apagar su sistema operativo la deja asignada y facturada. Los discos y las instantáneas siguen siendo recursos facturables por separado; las direcciones IP públicas conservadas también pueden generar cargos.

Compara configuraciones equivalentes

Una comparación de precios debe mantener constantes las vCPU, la memoria, la región, el sistema operativo y el modelo de compra. Las imágenes de Windows Server o SQL Server pueden incluir una licencia de software en su tarifa. Las licencias existentes elegibles pueden reducir la tarifa. La región afecta al precio, la latencia y la residencia de los datos.

El software de un mercado de productos y servicios en la nube añade cargos de terceros a la factura del proveedor. La conversión de moneda y los impuestos pueden cambiar después el total de la factura. AWS Pricing Calculator excluye los impuestos; las facturas pueden añadir impuestos sobre las ventas, IVA o GST según el lugar de facturación y la situación del cliente.

Entiende las ofertas gratuitas

Las ofertas gratuitas incluyen cantidades mensuales recurrentes, pruebas de duración limitada y créditos. AWS ofrece a las cuentas nuevas hasta 200 u.m. en créditos. Su plan Free se cierra al cabo de seis meses o cuando se agotan los créditos, lo que ocurra primero, salvo que se actualice a un plan Paid. Las cuentas de pago generan cargos normales por encima de sus cantidades gratuitas o después de que se agoten los créditos. Configura una alerta de presupuesto para una cuenta de prueba de pago, aunque sus primeras cargas de trabajo entren en una oferta gratuita.

Estima conjuntamente la cantidad de almacenamiento, las operaciones, la recuperación, la retención, la redundancia y el movimiento de datos.

Calcula el precio según cómo se usarán los datos

Los niveles de objetos de acceso frecuente incluyen Amazon S3 Standard, Azure Blob hot y Google Cloud Storage Standard. Cobran más por el almacenamiento que los niveles más fríos y no tienen cargo por recuperación. Las opciones más frías incluyen S3 Standard-IA y las clases Glacier, Azure cool, cold y archive, y Google Nearline, Coldline y Archive. Estas ofrecen almacenamiento más barato a cambio de cargos por recuperación y, para algunos productos de archivo, una demora de horas en la restauración.

Con tarifas de ejemplo, 10 000 GB en un nivel estándar a 0,023 u.m. por GB·mes cuestan 230 u.m. al mes. Un nivel de archivo a 0,002 u.m. cuesta 20 u.m. por almacenamiento. Recuperar 2000 GB a 0,02 u.m. por GB añade 40 u.m., para un total de 60 u.m. antes de las operaciones y otros cargos aplicables. Recuperar los 10 000 GB añade 200 u.m., con lo que esos dos componentes suman 220 u.m. La recuperación frecuente puede eliminar el ahorro, mientras que las demoras de restauración pueden descartar el archivo.

Ten en cuenta la retención y la capacidad

Una duración mínima de almacenamiento significa que la eliminación o el traslado anticipados pueden generar un cargo por el tiempo restante. Google Coldline tiene un mínimo de 90 días; Azure archive tiene un mínimo de 180 días. Si eliminas un objeto después de 30 días en un nivel de 90 días, los 60 días restantes se siguen cobrando.

Los discos de bloques suelen cobrarse por el tamaño aprovisionado y, a veces, por el rendimiento aprovisionado. Un disco de 500 GB con 50 GB escritos sigue tarificándose como 500 GB. El almacenamiento de objetos se cobra por los datos almacenados. Las instantáneas y copias de seguridad añaden sus propios cargos por datos almacenados. La redundancia añade copias y una copia en una segunda región puede añadir tanto almacenamiento como transferencia.

Sigue la dirección de la transferencia

La entrada de datos es la llegada de datos; la salida de datos es su envío hacia fuera. La entrada desde internet suele ser gratuita, incluidos los datos ordinarios transferidos desde internet a AWS. La salida a internet suele tener un precio por GB, con tramos y cantidades gratuitas. Las copias entre regiones también se cobran, normalmente como tráfico saliente de la región de origen.

Para una aplicación de ejemplo, enviar 2000 GB a usuarios de internet a 0,09 u.m. por GB cuesta 180 u.m. Replicar 500 GB a otra región a 0,02 u.m. añade 10 u.m. Recibir 300 GB de cargas sin cargo añade cero. El subtotal de transferencia es de 190 u.m. La factura de almacenamiento de los datos replicados es independiente.

La transferencia entre zonas también puede costar dinero. En AWS, el tráfico de EC2 entre zonas de disponibilidad puede generar cargos en ambos lados de la transferencia; otros servicios tienen sus propias reglas y exenciones. El tráfico mediante direcciones privadas dentro de una zona suele ser gratuito. Sigue cada ruta por los servicios reales y consulta sus páginas de precios, incluidas las cantidades gratuitas. Incluye las transferencias de salida al planificar una futura migración a otro proveedor.

La tarifa por hora más baja solo es útil cuando sus condiciones se ajustan a la carga de trabajo. Compara la flexibilidad, una obligación a largo plazo y la capacidad de tolerar interrupciones antes de elegir un modelo de compra.

Uso flexible o compromiso constante

El precio bajo demanda no requiere un compromiso a largo plazo: pagas la tarifa normal por el tiempo usado. Es adecuado para cargas de trabajo cortas, inciertas y cambiantes. Un compromiso reduce la tarifa a cambio de una obligación de uno o tres años. Un plazo de tres años ofrece un descuento mayor que uno de un año. Los compromisos de recursos coinciden con atributos como el tipo de recurso y la región; los compromisos de gasto cubren el uso elegible hasta un importe por hora.

AWS usa Reserved Instances y Savings Plans; Azure ofrece Reservations y el savings plan para cómputo. Google Cloud ofrece descuentos por compromiso de uso basados en recursos y en gasto. AWS anuncia ahorros de hasta el 72 % para Reserved Instances y Savings Plans. El ahorro máximo anunciado no es el ahorro de todas las configuraciones.

Un compromiso se paga por cada hora de su plazo, incluidas las horas sin usar. A 10 u.m. por hora durante un año, la obligación es de 87 600 u.m. Si una hora contiene solo 8 u.m. de uso elegible a las tarifas del plan, esa hora sigue costando 10 u.m. Las 2 u.m. no usadas no pueden trasladarse a una hora de mucho uso. El uso que supera el compromiso se cobra a tarifas bajo demanda.

Calcula el punto de equilibrio

Una máquina virtual de ejemplo cuesta 0,20 u.m. por hora bajo demanda o 0,13 u.m. por hora con un compromiso de un año. El compromiso cuesta 1138,80 u.m. por 8760 horas. El uso bajo demanda durante todo el año cuesta 1752 u.m., con un ahorro de 613,20 u.m., o el 35 %.

Para alcanzar el punto de equilibrio, las horas bajo demanda deben costar 1138,80 u.m.: divide entre 0,20 u.m. para obtener 5694 horas. Eso es el 65 % del año. Por encima del 65 % de uso, conviene el compromiso; al 65 %, los totales son iguales. Una carga de trabajo que solo se usa en días laborables durante 2080 horas cuesta solo 416 u.m. bajo demanda. Asume un compromiso para una demanda base medida, no para el máximo que una carga de trabajo alcanza brevemente.

Las opciones de pago de AWS son All Upfront, Partial Upfront y No Upfront; los pagos adelantados mayores suelen mejorar el descuento. Los savings plans de Azure tienen el mismo costo total tanto si se pagan mensualmente como por adelantado y no se pueden cancelar ni reembolsar.

Conoce qué promete una reserva

Una instancia reservada de AWS es una ventaja de facturación, no un servidor físico dedicado. La coincidencia incluye atributos de la instancia, región, sistema operativo y tenencia. Las reservas regionales se aplican en todas las zonas de la región; las zonales también reservan capacidad en una zona elegida. Las Standard Reserved Instances se pueden modificar, pero no intercambiar; las Convertible se pueden intercambiar por atributos diferentes con un descuento menor. Al terminar el plazo, las instancias en ejecución continúan a tarifas bajo demanda.

Usa capacidad interrumpible cuando el trabajo pueda reiniciarse

La capacidad interrumpible usa capacidad sobrante que el proveedor puede recuperar. AWS anuncia hasta un 90 % de descuento y Google Cloud hasta un 91 %. AWS suele dar un aviso de interrupción con dos minutos de antelación; Azure da un aviso, sin garantizarlo, hasta 30 segundos antes.

Con tarifas de ejemplo, 400 horas de cómputo cuestan 80 u.m. bajo demanda a 0,20 u.m. o 24 u.m. con capacidad interrumpible a 0,06 u.m. Si los reintentos aumentan el trabajo un 10 % hasta 440 horas, la capacidad interrumpible cuesta 26,40 u.m. Los trabajos por lotes, el renderizado, las compilaciones y los análisis que pueden reiniciarse pueden encajar con esta capacidad; una única base de datos que debe permanecer disponible no. Una combinación útil es usar compromisos para la demanda constante, precios bajo demanda para la demanda variable y capacidad interrumpible para los trabajos que pueden reiniciarse.

Los descuentos por uso continuado de Google son diferentes: los tipos de máquina elegibles, incluidos N1 y N2, pueden obtener descuentos automáticos después de más del 25 % de uso mensual sin compromiso, hasta un 20 % o un 30 % según el tipo.

Tres necesidades distintas pueden justificar una opción de compra especial: hardware exclusivo, capacidad garantizada o licencias de software elegibles. Identifica primero la necesidad y luego compara el costo de la opción que la cubre.

Compartir un servidor o controlar un host

En la tenencia compartida, las máquinas virtuales de distintos clientes ocupan el mismo servidor físico, aisladas por el hipervisor. Es la opción económica habitual para muchas cargas de trabajo. Las instancias dedicadas de AWS se ejecutan en hardware usado por un solo cliente, pero no permiten que ese cliente controle su ubicación en un host ni vea el servidor físico.

Un host dedicado proporciona un servidor completo y visibilidad de sus zócalos y núcleos. AWS Dedicated Hosts, Azure Dedicated Host y Google Cloud sole-tenant nodes cubren esta necesidad. Los clientes pueden controlar la ubicación de las máquinas virtuales en ese host. Los requisitos normativos de tenencia exclusiva y las licencias vinculadas a núcleos o zócalos físicos pueden hacer que esta opción sea útil.

Se factura el host completo incluso cuando está parcialmente vacío. A una tarifa de ejemplo de 5 u.m. por hora, un host cuesta 3650 u.m. en un mes de 730 horas. Si admite 12 máquinas virtuales, el costo por hora del host promedia unas 0,42 u.m. por máquina virtual cuando está lleno. Con solo cuatro máquinas virtuales, promedia 1,25 u.m. Es la misma factura del host dividida entre menos máquinas útiles. Compara la ocupación prevista además de la tarifa anunciada del host.

Reservar capacidad es una compra diferente

Una reserva de capacidad mantiene disponible capacidad de cómputo que coincide con los requisitos para cuando se necesite. AWS y Azure ofrecen reservas de capacidad zonales bajo demanda. Las reservas de Google Cloud también son zonales y su ámbito de consumo depende de la reserva y del servicio. Especifica los atributos y la ubicación requeridos de la máquina.

Una reserva de capacidad genera cargos por la capacidad reservada incluso mientras no se usa. Por sí sola no crea un descuento; una ventaja compatible por compromiso de uso puede reducir la factura. Tampoco hace que el host físico sea exclusivo de un cliente. Para un evento planificado o una sede de recuperación, pregunta por separado si la capacidad debe estar disponible y si vale la pena una tarifa menor por compromiso.

Esta distinción también explica la terminología de AWS. Una instancia reservada regional proporciona un descuento de facturación. Una instancia reservada zonal combina un descuento de facturación con una reserva de capacidad. Un host dedicado responde a la cuestión de la tenencia. Aunque tengan nombres similares, estas opciones no son intercambiables.

Comprueba si el software es elegible

Las imágenes con licencia incluida incorporan la licencia de software en la tarifa de la nube. El uso de licencias propias, o BYOL, utiliza licencias elegibles que el cliente ya posee. La elegibilidad depende de las condiciones del software; poseer una licencia no establece por sí solo el derecho a usarla en cualquier servidor de la nube.

La Ventaja híbrida de Azure admite licencias elegibles de Windows Server y SQL Server con Software Assurance o suscripciones aptas. AWS License Manager ayuda a supervisar el uso de licencias. Algunas licencias requieren un host físico conocido, lo que puede convertir el alojamiento dedicado en parte de la decisión sobre licencias.

Supón que un equipo necesita un precio menor para un servicio que funciona continuamente, pero no tiene una norma de tenencia exclusiva. Un compromiso con tenencia compartida responde a su objetivo de precio. Si, en cambio, el equipo necesita capacidad garantizada en una zona para un lanzamiento, añade una reserva de capacidad. Si una licencia debe vincularse a núcleos físicos, evalúa un host dedicado y su ocupación. Precio, disponibilidad y tenencia son características distintas que deben elegirse de forma deliberada.

El costo total de propiedad, o TCO, suma los costos de poseer y ejecutar un sistema durante un período elegido, a menudo de tres a cinco años. Ofrece una comparación más justa que colocar una factura de la nube junto al precio de compra del hardware. Ambas opciones deben prestar el mismo servicio requerido durante el mismo período.

Separa los costos de compra de los de funcionamiento

El gasto de capital, o CapEx, compra activos como servidores y edificios que se usan y deprecian durante varios años. El gasto operativo, u OpEx, paga servicios continuos y costos de funcionamiento. La nube traslada gran parte del gasto de compras adelantadas de hardware a cargos recurrentes por servicios.

Un centro de datos propio tiene muchos costos fijos incluso cuando se usa poco. Los cargos por uso de la nube pueden crecer o reducirse, pero los compromisos y los recursos aprovisionados siguen creando obligaciones. Un cambio en el tipo de gasto afecta al flujo de caja y a la flexibilidad; aun así, hay que calcular su costo total.

Para los sistemas locales, incluye hardware, licencias, espacio, electricidad, refrigeración, mantenimiento, seguridad física, tiempo del personal, renovaciones, capacidad para picos y recuperación ante desastres. Para la nube, incluye cómputo, almacenamiento, transferencia, servicios administrados, soporte técnico, tiempo del personal, formación y migración. Durante una migración, la organización puede pagar por ambos entornos a la vez.

El tiempo del personal es un dato que debe estimarse a partir de las responsabilidades reales. Un proveedor de servicios en la nube administra el hardware físico, pero el cliente sigue administrando las configuraciones, los datos, las decisiones de seguridad y los sistemas operativos de las máquinas virtuales. Evalúa el trabajo y las competencias necesarios en lugar de suponer que los costos de personal desaparecen.

Elabora una comparación paso a paso

1. Fija el alcance del servicio y el período de comparación.
2. Inventaría los servidores y el almacenamiento existentes y la utilización medida.
3. Suma los costos de compra y funcionamiento de la infraestructura local.
4. Dimensiona el sistema de la nube según la demanda observada y calcula el precio de sus componentes.
5. Añade la migración, la formación y cualquier período de funcionamiento simultáneo.
6. Compara los totales y después comprueba los supuestos de crecimiento y dimensionamiento.

Considera un ejemplo de tres años. En la infraestructura local, el hardware cuesta 60 000 u.m. Los costos anuales son 9000 u.m. de electricidad y refrigeración, 6000 u.m. de espacio, 40 000 u.m. de personal, 10 000 u.m. de licencias y 5000 u.m. de mantenimiento. Esos costos anuales suman 70 000 u.m. Tres años cuestan 60 000 u.m. más 210 000 u.m., lo que da 270 000 u.m.

La alternativa en la nube usa 3500 u.m. mensuales de cómputo y almacenamiento, 300 u.m. de transferencia y 350 u.m. de soporte técnico. Las 4150 u.m. mensuales se convierten en 149 400 u.m. durante 36 meses. Añade 60 000 u.m. por tres años de tiempo del personal y 25 000 u.m. de migración: 234 400 u.m. La diferencia es de 35 600 u.m., cerca del 13 % del total de la infraestructura local.

Comprueba qué podría cambiar el resultado

Una configuración mayor en la nube, un crecimiento más rápido o más salida de datos pueden reducir ese ahorro. Un compromiso puede reducir las tarifas, pero añade una obligación. Copiar la capacidad máxima comprada a la nube puede sobreestimar lo necesario; la utilización medida permite dimensionar adecuadamente la estimación.

AWS Migration Evaluator, el caso empresarial de Azure Migrate y Google Cloud Migration Center ayudan a inventariar sistemas y comparar costos. Sus resultados dependen del inventario y de los supuestos introducidos. Mantén las ventajas difíciles de valorar en dinero, como una entrega más rápida, el alcance global, la elasticidad y la resiliencia, junto al cálculo económico. Las economías de escala ayudan a los proveedores a reducir costos, pero una carga de trabajo constante realojada sin cambios y con tarifas bajo demanda puede seguir costando tanto como su alternativa local, o más.

Una calculadora de precios convierte una configuración prevista en la nube en un cargo estimado. AWS, Azure y Google Cloud proporcionan calculadoras web gratuitas. Introduce todos los componentes y un uso realista antes de comparar diseños.

Inventaría todos los componentes

Empieza por la arquitectura: máquinas virtuales de la aplicación, base de datos, discos, datos de objetos, solicitudes, copias de seguridad y rutas de transferencia. Incluye los entornos de desarrollo y prueba, no solo el de producción. Elige una región, un sistema operativo, tamaños de recursos, horas de funcionamiento y un modelo de precios para cada servicio. Añade el plan de soporte técnico por separado si aún no está incluido.

Usa la misma base temporal en todo el cálculo. Usa 730 horas para un mes estimado de funcionamiento continuo. Un sistema de prueba usado en días laborables necesita su horario real, mientras que los discos conservados pueden necesitar un mes completo de almacenamiento. Convierte los recuentos de solicitudes a millones antes de aplicar una tarifa por millón.

Suma las partidas

Para una pequeña aplicación web, usa estas tarifas de ejemplo y cantidades mensuales:

El total de estas cuatro partidas es 325,26 u.m. mensuales, o 3903,12 u.m. anuales. Añade a este subtotal las copias de seguridad, el soporte técnico y los demás servicios necesarios.

Si un compromiso de un año reduce solo la tarifa de las máquinas virtuales en un 35 %, la partida de máquinas virtuales pasa a ser 140,16 u.m. multiplicadas por 0,65, o 91,104 u.m. antes de redondear. Suma la base de datos, el almacenamiento y la salida de datos sin cambios para obtener 276,204 u.m., expresadas como 276,20 u.m. mensuales. Aplicar el 35 % a toda la estimación descontaría incorrectamente servicios que quedan fuera de esa oferta para máquinas virtuales.

Registra qué significa la estimación

Revisa juntos los cargos mensuales, los pagos adelantados y los totales anuales. Una oferta pagada totalmente por adelantado puede mostrar una factura recurrente pequeña y, al mismo tiempo, requerir dinero al inicio. Registra la fecha, la región, la configuración, las horas, la transferencia, el plazo del compromiso y la base de precios. Las estimaciones públicas usan tarifas de lista; algunas calculadoras pueden usar precios negociados. La calculadora de Google puede usar precios contractuales cuando está vinculada a una cuenta de facturación elegible.

AWS Pricing Calculator excluye los impuestos. Las listas de precios y las API, como AWS Price List API y Azure Retail Prices API, proporcionan tarifas para herramientas y scripts; las tarifas pueden cambiar después de guardar una estimación.

Agrupa la estimación por carga de trabajo, guarda un enlace para compartir y expórtala para su revisión. AWS admite exportaciones CSV y PDF. Después de la implementación, compara cada partida principal con el informe de costos. Investiga las diferencias entre las horas, el almacenamiento y la transferencia reales y las cantidades guardadas.

Una entidad central de facturación puede pagar las cuentas, suscripciones o proyectos separados de varios equipos. Haz seguimiento tanto de la entidad pagadora como de la persona responsable de los recursos.

Identifica la entidad pagadora

En AWS, una organización de AWS Organizations tiene una cuenta de administración que paga las cuentas miembro mediante facturación consolidada. En Azure, las suscripciones están bajo una cuenta de facturación; bajo un Microsoft Customer Agreement, los perfiles de facturación y las secciones de factura organizan el pago. En Google Cloud, cada proyecto está vinculado a una cuenta de facturación de Cloud Billing que paga sus cargos.

Una factura suele cubrir un mes natural. Sus agrupaciones por servicio, tipo de uso, región y cuenta o proyecto explican los cargos. Los créditos, reembolsos e impuestos afectan al importe adeudado. Las partidas detalladas relacionan una cantidad medida con una tarifa y, cuando está disponible, con un recurso.

Combina el uso elegible para obtener precios por volumen

La facturación consolidada de AWS no tiene cargo adicional y combina el uso elegible para los tramos por volumen. Considera estas tarifas de ejemplo de almacenamiento: 0,023 u.m. por GB·mes para los primeros 50 000 GB y 0,022 u.m. por encima de esa cantidad. Tres cuentas almacenan 20 000 GB cada una durante un mes.

Facturadas por separado, cada una paga 460 u.m. y el total combinado es de 1380 u.m. El uso consolidado es de 60 000 GB: los primeros 50 000 cuestan 1150 u.m. y los 10 000 restantes cuestan 220 u.m. El total consolidado es de 1370 u.m.

Solo la cantidad que supera el límite del tramo recibe la tarifa menor. Tarificar los 60 000 GB completos a 0,022 u.m. daría 1320 u.m. y extendería incorrectamente el tramo más barato al uso anterior.

Sigue las ventajas compartidas por compromiso de uso

Las ventajas de Reserved Instances y Savings Plans también pueden compartirse entre cuentas elegibles. Si la cuenta A posee una instancia reservada pero no tiene uso coincidente durante una hora, una instancia en ejecución de la cuenta B que coincida puede recibir la ventaja. La cuenta de administración puede desactivar la opción de compartir para determinadas cuentas.

La factura mostrada de una cuenta miembro es, por tanto, una vista informativa de los cargos y las ventajas asignadas. Aplica la regla central de asignación cuando otro equipo consume la ventaja comprada.

Las cuentas, suscripciones o proyectos separados hacen visible la responsabilidad porque los cargos ya pertenecen a esos ámbitos. Las etiquetas dividen los costos con más detalle dentro de ellos, por ejemplo por aplicación o entorno.

El acceso a la facturación sigue necesitando permisos. Da a quienes consultan costos la capacidad de inspeccionar informes sin concederles también el derecho a cambiar datos de pago o comprar compromisos. Separa la consulta de costos, los cambios de pago y las compras de compromisos mediante permisos de mínimo privilegio.

Usa los informes de costos para encontrar el servicio, el recurso y la persona responsable de un cambio de gasto.

Elige una vista útil

AWS Cost Explorer, el análisis de costos de Microsoft Cost Management y los informes de Google Cloud Billing muestran el gasto a lo largo del tiempo. Filtra y agrupa por servicio, cuenta o proyecto, región, tipo de uso y etiquetas. Las previsiones proyectan costos futuros a partir de patrones de uso anteriores.

Para un análisis detallado, exporta los registros de facturación. Los datos de AWS Cost and Usage Report pueden entregarse mediante AWS Data Exports a S3, las exportaciones de Azure Cost Management escriben en una cuenta de almacenamiento y las exportaciones de facturación de Google Cloud van a BigQuery. Estos conjuntos de datos permiten a los analistas consultar identificadores de recursos, cantidades y etiquetas o crear sus propios paneles de control.

Separa el momento del pago del costo a lo largo del tiempo

Una vista de costos reales muestra los cargos en el período facturado. Una vista de costos amortizados distribuye los cargos adelantados por compromiso durante el plazo. Si un compromiso de un año cuesta 8760 u.m. por adelantado, el mes de compra muestra 8760 u.m. en una vista de costos reales. Una vista mensual amortizada sencilla lo distribuye como unas 730 u.m. al mes.

Usa los costos reales para ver cuándo se paga y los costos amortizados para comparar períodos; una compra anticipada no es un aumento repentino del uso.

Profundiza en el cambio mayor

Supón que la factura sube de 10 000 u.m. a 12 000 u.m. El aumento de 2000 u.m. es el 20 % del mes anterior. Agrupar por servicio revela:

La transferencia explica 1900 u.m. del aumento neto de 2000 u.m., o el 95 %. Empieza ahí: agrupa la transferencia por región, después por cuenta o etiqueta y luego inspecciona el recurso y el tipo de uso. Una ruta de replicación en aumento necesita una respuesta distinta de un aumento de las descargas de los clientes. Asigna una persona responsable y una acción después de localizar la causa.

Ten en cuenta el retraso y los cambios ocultos

Los informes de facturación van por detrás de la actividad de los recursos. Los datos de presupuesto de AWS se actualizan hasta tres veces al día; los datos de costos de Azure suelen llegar en un plazo de 8 a 24 horas. Una carga de trabajo nueva puede estar generando gasto antes de que aparezca su costo. Compara períodos y vistas de costos equivalentes al comprobar una alerta.

Las herramientas de anomalías identifican patrones de gasto inusuales. AWS Cost Anomaly Detection, las alertas de anomalías de Microsoft Cost Management y la detección de anomalías de Google Cloud pueden señalar un clúster olvidado o un aumento repentino de la transferencia. Los servicios de recomendaciones como AWS Trusted Advisor, Azure Advisor y Google Cloud Recommender sugieren ahorros que conviene investigar.

Un total estable puede ocultar un crecimiento de la base de datos compensado por una caída de los costos de las máquinas virtuales. Compara los cambios de los servicios junto con las agrupaciones por cuenta y etiqueta para identificar tanto el uso como la responsabilidad.

Un presupuesto establece una cantidad prevista para un período y un ámbito. Las alertas comparan el costo o el uso con ese plan. Ayudan a alguien a responder antes de la factura final, por lo que su ámbito, umbrales y destinatario son tan importantes como su importe.

Define el ámbito y el propósito

AWS Budgets, los presupuestos de Microsoft Cost Management y los presupuestos de Google Cloud Billing pueden supervisar una cuenta o una parte más reducida. Algunos ejemplos son una suscripción o un grupo de recursos de Azure, un proyecto de Google o un filtro por servicio o etiqueta. Azure admite reinicios mensuales, trimestrales y anuales; AWS también admite períodos personalizados, como la duración de un proyecto.

AWS ofrece presupuestos de costos y uso, además de presupuestos de utilización y cobertura de Reserved Instances y Savings Plans. La utilización indica cuánto del compromiso comprado se usa. La cobertura indica cuánto uso elegible recibe una ventaja por compromiso. Un equipo puede tener una utilización alta pero una cobertura baja si un compromiso pequeño se usa por completo en una carga de trabajo mucho mayor.

Usa umbrales de costo real y previsto

Una alerta de costo real compara el gasto acumulado con un umbral. Una alerta de costo previsto compara el gasto esperado para todo el período con un umbral. Los umbrales predeterminados sugeridos por Google incluyen el 50 %, el 90 % y el 100 %; elige niveles que dejen tiempo para que responda la persona responsable.

Para un presupuesto mensual de 5000 u.m., un umbral de costo real del 80 % son 4000 u.m. El día 12 de un mes de 30 días, el gasto es de 2400 u.m. Eso es el 48 % del presupuesto, por lo que no se ha alcanzado el umbral de costo real. Al ritmo actual de 200 u.m. diarias, una previsión sencilla alcanza 6000 u.m., o el 120 % del presupuesto. Un umbral de costo previsto del 100 % avisa ahora.

El presupuesto restante es de 2600 u.m. para 18 días. Divide para obtener unas 144,44 u.m. al día. Este es el ritmo medio restante necesario para cumplir el plan; reducir el ritmo futuro no elimina los cargos ya generados.

Decide qué ocurre después de la alerta

Un presupuesto ordinario es una alerta, no una detención predeterminada del gasto. Las notificaciones de presupuesto de Azure no afectan a los recursos. Los presupuestos de Google que solo generan alertas no limitan el consumo. Los datos de facturación llegan con retraso, por lo que los costos pueden superar un umbral antes de que la notificación llegue a alguien.

La automatización requiere configuración. Las acciones de presupuesto de AWS pueden aplicar políticas de IAM o de control de servicios, o detener instancias de EC2 y RDS. Los grupos de acciones de Azure pueden invocar Functions, Logic Apps o webhooks. Las notificaciones de Google Pub/Sub pueden activar automatizaciones; Google también ofrece presupuestos con límite de gasto configurados por separado que pausan servicios compatibles en un proyecto.

Elige la acción teniendo en cuenta las necesidades de disponibilidad de la carga de trabajo. Detener automáticamente un sistema de prueba puede ser aceptable; detener la única base de datos de producción puede causar una caída costosa. Comprueba el ámbito y los permisos de una acción automatizada antes de depender de ella.

Asigna una persona responsable al presupuesto

Las notificaciones pueden llegar al correo electrónico, a temas de AWS SNS y aplicaciones de chat, a grupos de acciones de Azure y a la aplicación móvil, o a canales de Google Pub/Sub y Cloud Monitoring. Designa a la persona o al equipo que debe investigar y define cómo se gestionan las alertas urgentes. Una bandeja de entrada compartida solo es útil cuando alguien es responsable de responder. Durante las revisiones periódicas, comprueba que el ámbito sigue correspondiendo a la carga de trabajo y que los destinatarios siguen teniendo autoridad para actuar.

Una etiqueta es un par clave-valor asociado a un recurso, como «Environment = Production» o «CostCenter = 4410». Las etiquetas conectan los recursos técnicos con las personas y los fines de negocio que están detrás de sus costos. AWS y Azure usan tags para esto; Google Cloud usa labels para desgloses de facturación y tags separados principalmente para políticas condicionales.

Establece un estándar común

Entre las claves útiles están CostCenter, Owner, Environment, Project y Application. Define los nombres y valores permitidos y aplícalos al crear recursos. «Environment = Production» y «environment = prod» pueden dividir en dos un grupo que se pretendía mantener unido. Las claves y los valores de las etiquetas de AWS distinguen entre mayúsculas y minúsculas. Los nombres de las etiquetas de Azure no las distinguen en las operaciones, pero los valores sí.

La separación de cuentas proporciona un ámbito general de responsabilidad; las etiquetas añaden detalle dentro de él. Una cuenta compartida podría contener recursos «Application = Orders» y «Application = Search», lo que permite que un informe de costos separe esas aplicaciones sin moverlas.

Haz que las etiquetas se puedan usar en la facturación

En AWS, una cuenta de administración o independiente debe activar las etiquetas como etiquetas de asignación de costos en Billing and Cost Management. Las etiquetas definidas por el usuario aparecen junto a las generadas por AWS con el prefijo «aws:», como «aws:createdBy». La activación y disponibilidad pueden tardar, incluidas hasta 24 horas en aparecer. Una aplicación retroactiva solicitada puede aplicar las etiquetas a hasta 12 meses de datos de costos anteriores de recursos que ya las tenían.

Los recursos de Azure no heredan de forma predeterminada las etiquetas del grupo de recursos o de la suscripción. Azure Policy puede añadir o heredar etiquetas en los recursos. La herencia de etiquetas de Cost Management aplica etiquetas de niveles superiores a los registros de uso; esa función de informes es diferente de escribir etiquetas en los propios recursos. Azure permite hasta 50 etiquetas por recurso, grupo de recursos o suscripción.

Asigna explícitamente los costos compartidos y los que faltan

No todos los tipos de recursos admiten etiquetas, y las tarifas de soporte técnico, los impuestos y algunos cargos de transferencia pueden carecer de una etiqueta de recurso. Mantén una categoría sin asignar y acuerda cómo distribuir los costos realmente compartidos.

Supón que los cargos de recursos suman 5000 u.m.: el equipo A tiene 3000 u.m., el equipo B 1500 u.m. y 500 u.m. están sin etiquetar. Los costos etiquetados suman 4500 u.m. Una tarifa de soporte técnico separada de 400 u.m. se asigna en proporción a los costos etiquetados. Al equipo A le corresponden 3000 u.m. divididas entre 4500 u.m. de la tarifa, o 266,67 u.m. Al equipo B le corresponden 133,33 u.m. La factura completa es de 5400 u.m., y las 500 u.m. sin etiquetar quedan pendientes de que las personas responsables las resuelvan. No las distribuyas sin más como si se conociera a su responsable.

La presentación de costos sin imputación interna informa de los costos a un equipo para que los conozca. La imputación interna de costos carga esos costos a su presupuesto interno. Ambas necesitan responsables de recursos fiables y un método de asignación que explique los cargos compartidos.

Mantén las etiquetas precisas y seguras

Aplica el estándar mediante infraestructura como código y procesos de creación de recursos. Las políticas de etiquetas de AWS normalizan las claves y los valores admitidos; usa controles adicionales para detectar o impedir la falta de etiquetas. Azure Policy puede exigir una etiqueta, añadir un valor o denegar una creación que incumpla las normas. Supervisa la cobertura de etiquetas como la proporción del costo pertinente que lleva las etiquetas requeridas e investiga la falta de cobertura.

Las etiquetas aparecen como texto en claro en informes, registros y exportaciones. No incluyas contraseñas, datos personales ni otros valores sensibles en ellas. Una etiqueta por sí sola es un metadato; las reglas de acceso necesitan una política independiente que la use.

La gobernanza de la nube combina reglas, procesos y controles. Un control preventivo bloquea una acción no deseada, un control de detección informa de un problema y un control correctivo lo corrige. Relaciona el control con el requisito real: quién puede actuar, qué estado de un recurso está permitido o qué debe protegerse frente a cambios accidentales.

Aplica reglas de recursos de Azure

El RBAC de Azure controla quién puede realizar acciones. Azure Policy comprueba las propiedades de los recursos independientemente de quién envíe la solicitud. Un Contributor puede tener permiso para crear máquinas virtuales, pero una directiva Allowed locations aún puede denegar una región no aprobada.

Una definición de directiva contiene una regla y un efecto. Una iniciativa agrupa definiciones. Una asignación aplica una de ellas a un grupo de administración, una suscripción, un grupo de recursos o un recurso; los ámbitos inferiores la heredan, con las exclusiones configuradas.

El efecto determina la respuesta. audit registra el incumplimiento; deny bloquea un cambio que incumple las normas. modify y append pueden cambiar una solicitud, por ejemplo añadiendo una etiqueta. auditIfNotExists comprueba recursos relacionados y deployIfNotExists puede implementarlos. denyAction bloquea acciones especificadas, como la eliminación; disabled desactiva la evaluación. Los recursos existentes pueden necesitar tareas de corrección. Las evaluaciones se realizan ante cambios pertinentes y en exámenes que normalmente se ejecutan cada 24 horas. Empieza con audit cuando necesites entender el impacto de una asignación antes de aplicar deny.

Protege los recursos frente a cambios accidentales

Los bloqueos de Azure se aplican en el ámbito de suscripción, grupo de recursos o recurso y se heredan. CanNotDelete, mostrado como Delete en el portal, permite leer y modificar, pero bloquea la eliminación. ReadOnly solo permite leer y puede bloquear operaciones de administración inesperadas, como iniciar una máquina virtual o listar claves de almacenamiento.

Solo los roles con permisos de bloqueo, como Owner o User Access Administrator, pueden administrar bloqueos. Un bloqueo puede impedir una acción que de otro modo estaría permitida, pero alguien autorizado a quitarlo puede eliminar esa protección. Los bloqueos protegen las operaciones de administración, no los datos almacenados: un bloqueo de cuenta de almacenamiento no impide eliminar blobs mediante el plano de datos. Un recurso bloqueado puede impedir que se elimine todo su grupo de recursos.

Usa los controles de protección organizativos correspondientes

Las políticas de control de servicios, o SCP, de AWS establecen los permisos máximos de los usuarios y roles de IAM en las cuentas miembro, incluidos los usuarios raíz de esas cuentas. No conceden permisos por sí mismas y no restringen la cuenta de administración. Una SCP puede denegar acciones fuera de las regiones aprobadas. Las reglas de AWS Config detectan incumplimientos de los recursos; Control Tower ayuda a establecer cuentas y controles. Las políticas de etiquetas normalizan los valores de etiqueta admitidos, pero una regla para etiquetas ausentes necesita medidas adicionales adecuadas para hacerla cumplir.

Organization Policy Service de Google Cloud aplica restricciones en el ámbito de la organización, la carpeta o el proyecto, que se heredan hacia abajo en la jerarquía. Los tres proveedores usan cuotas para limitar cantidades como las vCPU. Una cuota limita la cantidad de recursos, no la factura total de todos los servicios.

Para «regiones aprobadas de la UE, una etiqueta CostCenter y protección frente a la eliminación de la base de datos», Azure necesita directivas de región y etiqueta, además de un bloqueo CanNotDelete. AWS combina SCP regionales, estándares y comprobaciones de etiquetas, y protección contra eliminación de la base de datos. Google combina restricciones de ubicación de recursos, comprobaciones de etiquetado y protección contra eliminación.

Microsoft Purview tiene otro propósito: descubrir, clasificar, catalogar y proteger datos en distintos entornos y facilitar el cumplimiento normativo. Restringe los tamaños y las regiones de las máquinas virtuales con una política de recursos, no con un catálogo de datos.

Una persona con permisos en la nube puede crear un recurso facturable en minutos. Por tanto, la gobernanza financiera necesita una práctica continua: mostrar los costos, asignar responsabilidades, actuar ante los cambios y revisar si los controles siguen ajustándose al negocio.

Conecta personas, procesos y tecnología

FinOps reúne a los equipos de finanzas, ingeniería y negocio para tomar decisiones de gasto informadas. Los ingenieros entienden los sistemas y pueden cambiar su uso. Finanzas establece presupuestos y previsiones. Los responsables de negocio deciden cómo equilibrar el costo con la velocidad, la fiabilidad y la calidad.

Asigna a cada cuenta, suscripción o proyecto una persona designada como responsable de costos. Un equipo central de FinOps o centro de excelencia en la nube establece estándares comunes, prepara informes y coordina los compromisos para la demanda base compartida. Apoya las decisiones de los equipos de ingeniería en lugar de tomar por ellos todas sus decisiones diarias sobre recursos.

Las herramientas apoyan ese trabajo: estructuras de cuentas, etiquetas, informes de costos, presupuestos, alertas de anomalías, políticas, cuotas y recomendaciones. Un panel de control sin una persona responsable no decide qué hacer; una alerta sin un proceso de respuesta puede quedar sin leer.

Repite las fases de FinOps

El marco FinOps nombra tres fases que se repiten:

• Informar: hacer visible el gasto y asignarlo a las personas responsables.
• Optimizar: mejorar el uso y las tarifas al tiempo que se cumplen los requisitos.
• Operar: establecer objetivos y políticas, actuar mediante procesos acordados y mejorar la práctica.

Forman un ciclo, no un proyecto puntual. Una revisión mensual puede comparar los costos reales con las previsiones, inspeccionar los cambios por equipo, comprobar la cobertura de etiquetas y revisar los compromisos sin usar. Entre revisiones, un proceso de anomalías gestiona los cambios urgentes. Un proceso de compra de compromisos debe identificar quién puede aprobar la obligación y qué demanda base la sustenta.

La jerarquía de recursos de Google (organización, carpetas, proyectos y recursos) ayuda a combinar la responsabilidad con las políticas de acceso y organizativas heredadas. La visibilidad de costos, los límites de permisos y la auditoría deben ajustarse a esa estructura para que la persona responsable de un proyecto pueda investigar su gasto.

Relaciona el costo con resultados útiles

La economía unitaria divide el costo entre un resultado del negocio, como los pedidos procesados. Con 12 000 u.m. para 400 000 pedidos, el costo es de 0,03 u.m. por pedido. Con 15 000 u.m. para 600 000 pedidos, baja a 0,025 u.m. por pedido.

La factura creció un 25 %, mientras que los pedidos crecieron un 50 %. Por tanto, una factura mayor puede acompañar a una mejora del costo por unidad. Comprueba tanto el total como la medida unitaria: el total importa para el presupuesto, mientras que la medida unitaria explica la eficiencia cuando cambia la producción. Un costo unitario menor puede coexistir con recursos inactivos, así que sigue inspeccionando los costos a nivel de recurso.

Cierra el ciclo después de un incidente

Supón que una anomalía semanal muestra una subida del 40 %. La alerta llega a la persona responsable de la cuenta, que agrupa el informe por etiqueta y encuentra un clúster de prueba que se dejó a tamaño completo. El equipo detiene el trabajo innecesario, confirma el efecto en los datos de costos posteriores y añade una fecha de finalización a las solicitudes de recursos de prueba. En la siguiente revisión, actualiza el estándar y comprueba si existen recursos similares.

Esta secuencia da a cada herramienta un propósito: la alerta detecta, el informe explica, la persona responsable actúa y el proceso reduce la repetición. Antes de recortar un costo, comprueba su efecto en la seguridad, el rendimiento y la fiabilidad. La gobernanza financiera busca resultados útiles para el negocio a partir del gasto en la nube, con las ventajas y desventajas visibles para las personas responsables.

Un plan de soporte técnico compra acceso a ayuda bajo condiciones definidas. Elígelo según el impacto de la carga de trabajo y la primera respuesta requerida, y después calcula la tarifa. Un objetivo de respuesta indica cuándo empieza la ayuda, no cuándo se reparará la aplicación.

Compara los niveles de soporte técnico

Los planes básicos incluyen ayuda para cuentas y facturación, documentación y acceso a la comunidad. Los planes de pago añaden casos técnicos y respuestas más rápidas para incidentes graves. Los niveles superiores pueden añadir orientación de arquitectura y un gestor técnico de cuentas, o TAM, que proporciona orientación continua. Abre los casos mediante la consola del proveedor, como AWS Support Center o Azure Help + support.

En octubre de 2026, AWS recomienda Business Support+ como su plan mínimo para producción. Incluye soporte técnico 24/7 por teléfono, chat y correo electrónico, todas las comprobaciones de Trusted Advisor y un objetivo de respuesta de menos de 30 minutos cuando un sistema esencial para el negocio está caído. Enterprise Support añade un TAM designado y evaluaciones de Well-Architected, con un objetivo de menos de 15 minutos para esa gravedad. Unified Operations añade ingenieros de gestión de incidentes con un objetivo de menos de cinco minutos, especialistas y supervisión de cargas de trabajo 24/7.

AWS retirará los antiguos planes Developer, Business y Enterprise On-Ramp el 1 de enero de 2027 en las regiones comerciales. Los usuarios de Developer y Business pueden pasar a Business Support+; los usuarios de Enterprise On-Ramp están pasando a Enterprise Support.

Aplica los tramos y el mínimo

Business Support+ cuesta el mayor de dos importes: 29 u.m. mensuales por cuenta o porcentajes por tramos de los cargos mensuales de AWS: el 9 % de las primeras 10 000 u.m., el 7 % de 10 000 a 80 000 u.m., el 5 % de 80 000 a 250 000 u.m. y el 3 % por encima de 250 000 u.m.

Con 20 000 u.m. de cargos, el primer tramo aporta 900 u.m. y el siguiente 700 u.m., para un total de 1600 u.m. No apliques el 7 % a las 20 000 u.m. completas: el gasto anterior conserva la tarifa de su tramo. Con 200 u.m. de cargos, el 9 % da 18 u.m., por lo que se aplica el mínimo de 29 u.m.

Enterprise Support usa un mínimo de 5000 u.m. o el 10 % de las primeras 150 000 u.m., el 7 % hasta 500 000 u.m., el 5 % hasta 1 millón de u.m. y el 3 % por encima. Con 100 000 u.m., la tarifa es de 10 000 u.m. Unified Operations comienza en 50 000 u.m. mensuales. Compara el mínimo con el total calculado después de aplicar todos los tramos pertinentes.

Ajusta el plan a la necesidad

Azure Basic incluye ayuda para facturación y suscripciones. Developer cuesta 29 u.m. mensuales para uso fuera de producción, con respuesta a casos de impacto mínimo en ocho horas laborables. Standard cuesta 100 u.m. para producción, con respuesta a casos críticos en una hora. Professional Direct cuesta 1000 u.m. para usos esenciales para el negocio, con casos críticos en una hora y moderados en dos horas. Unified Enterprise tiene precios personalizados, respuesta en 15 minutos para sistemas de Azure caídos y soporte para otros productos de Microsoft.

Google Cloud Customer Care tiene los niveles Basic, Standard, Enhanced y Premium. Los niveles de pago mejoran los objetivos de respuesta; Premium añade un TAM.

Para una tienda web en producción que necesita ayuda técnica permanente sin un gestor de cuentas designado pueden encajar AWS Business Support+ o Azure Standard. Un requisito de contar con un TAM cambia la comparación. Comprueba conjuntamente la gravedad, las horas de cobertura, el objetivo de primera respuesta, la orientación incluida y el precio. El soporte técnico ayuda al equipo del cliente; el cliente sigue operando su aplicación.

Un proveedor ofrece varios tipos de ayuda porque los distintos problemas necesitan respuestas diferentes. Empieza por identificar la tarea: aprender una configuración, investigar un incidente, revisar costos, comprar software o planificar una migración.

Aprende y diseña

La documentación oficial explica las funciones y la configuración. AWS añade documentos técnicos, blogs, Prescriptive Guidance para estrategias y patrones, y Knowledge Center para preguntas habituales. Microsoft Learn y Azure Architecture Center proporcionan referencias comparables. La documentación de Google Cloud y Architecture Center explican los servicios y patrones de diseño de Google.

Las comunidades permiten hacer y responder preguntas: AWS re:Post, Microsoft Q&A y las comunidades de Azure, y Google Cloud Community. Pueden ayudar con una pregunta de diseño o una experiencia compartida. Para un incidente urgente de producción que requiera un objetivo de respuesta, abre un caso técnico con el plan de soporte adecuado.

Los arquitectos de soluciones de AWS asesoran sobre el diseño de cargas de trabajo, mientras que AWS Professional Services ayuda a llevar a cabo proyectos de consultoría más grandes. Los socios pueden diseñar, migrar y operar entornos. Los proveedores independientes de software, o ISV, venden software; los integradores de sistemas y socios de consultoría conectan sistemas y ayudan con la implementación. Los programas de socios de los proveedores ofrecen formación, certificación, eventos y ventajas comerciales.

Examina el estado y las recomendaciones

Los paneles de estado informan de eventos del lado del proveedor. AWS Health muestra el estado público de los servicios y los eventos que afectan a tu cuenta; AWS Health API permite que las automatizaciones utilicen esos eventos. Azure Service Health proporciona información sobre problemas, mantenimiento y avisos pertinentes para las suscripciones. Los servicios de estado de Google Cloud proporcionan información sobre el estado de los servicios y, cuando está disponible, información personalizada sobre incidentes.

Una página pública de estado normal puede coincidir con un evento que afecta a una cuenta o recurso específico. Consulta la vista de la cuenta o suscripción al investigar una caída y compárala con la supervisión de la propia aplicación. La ausencia de un evento en la lista es motivo para seguir investigando la aplicación, no para ignorar sus síntomas.

Las herramientas de asesoramiento examinan las configuraciones y el uso. AWS Trusted Advisor comprueba costos, seguridad, tolerancia a fallos, rendimiento, límites de servicio y excelencia operativa. Basic incluye comprobaciones básicas; los planes de pago incluyen todas. Azure Advisor cubre fiabilidad, seguridad, rendimiento, costos y excelencia operativa, con una puntuación de Advisor. Google Cloud Recommender, parte de Active Assist, sugiere acciones como ajustar el tamaño de máquinas virtuales inactivas.

Compra, contrata ayuda o informa de un abuso

Los mercados de productos y servicios en la nube venden software, datos y servicios de terceros mediante la factura de la nube. Pueden simplificar las compras y el seguimiento de derechos de uso: quién tiene permiso para usar el software comprado. No son colas de soporte técnico. Recurre a un socio o a un equipo de consultoría del proveedor cuando necesites ejecutar una migración o conocimientos especializados en diseño organizativo.

AWS Trust and Safety gestiona las sospechas de abuso procedente de recursos de AWS, como spam, escaneo, tráfico de denegación de servicio o malware. Cualquier persona puede informar de una sospecha de abuso; esta vía es diferente de un caso de soporte sobre tu propia aplicación.

Relaciona cada solicitud concreta con el servicio: «¿Qué cambió en el estado del servicio de nuestra suscripción?» requiere la vista personalizada de estado. «¿Quién puede ayudar a llevar a cabo nuestra migración?» requiere un socio de consultoría o Professional Services. «¿Dónde podemos obtener una licencia de cortafuegos con cargo a nuestra factura de la nube?» requiere el mercado de productos y servicios en la nube. «¿Qué recursos parecen inactivos?» requiere un asesor o una herramienta de recomendaciones, seguido de una revisión de las necesidades de la carga de trabajo por parte de la persona responsable.

Un marco de buena arquitectura organiza las buenas prácticas para diseñar y ejecutar una carga de trabajo. Sus pilares ayudan a un equipo a plantear preguntas equilibradas sobre el sistema. Es una guía para la evaluación y la mejora, no una certificación ni una norma de cumplimiento.

Conoce los pilares y su significado

AWS tiene seis pilares: excelencia operativa, seguridad, fiabilidad, eficiencia del rendimiento, optimización de costos y sostenibilidad. Azure tiene cinco: fiabilidad, seguridad, optimización de costos, excelencia operativa y eficiencia del rendimiento. Google Cloud tiene seis: excelencia operativa; seguridad, privacidad y cumplimiento normativo; fiabilidad; optimización de costos; optimización del rendimiento; y sostenibilidad.

La excelencia operativa significa ejecutar y mejorar sistemas mediante supervisión, automatización y cambios seguros. La seguridad protege los sistemas y los datos. La fiabilidad significa recuperarse de fallos y seguir cumpliendo las funciones previstas. La eficiencia u optimización del rendimiento consiste en satisfacer la demanda con recursos y escalado adecuados. La optimización de costos busca el menor costo adecuado para el valor de negocio requerido. La sostenibilidad tiene en cuenta el impacto ambiental de la carga de trabajo.

El pilar de costos conecta los precios con el diseño: mide el gasto, atribúyelo a las personas responsables, elige modelos de compra adecuados y revisa el uso. Un servicio administrado puede reducir el costo operativo total incluso cuando su cargo directo supera el cargo de máquina virtual de una alternativa autoadministrada.

Convierte las preguntas en un plan de mejora

AWS Well-Architected Tool es un servicio gratuito de consola para evaluar una carga de trabajo mediante preguntas de cada pilar. Registra problemas de riesgo alto y medio y facilita un plan de mejora. Las perspectivas añaden preguntas para tipos de cargas de trabajo como las funciones sin servidor. Azure proporciona una evaluación Well-Architected Review y Azure Advisor organiza las recomendaciones en torno a sus pilares.

En una evaluación, la falta de presupuesto identifica un problema de costos. Una base de datos que funciona en una sola zona de disponibilidad presenta un riesgo de fiabilidad. La falta de autenticación multifactor en las cuentas de administrador es un problema de seguridad. Las implementaciones manuales sugieren riesgos operativos. Prioriza la falta de MFA y la exposición a fallos según los requisitos y el impacto de la carga de trabajo; no trates todos los hallazgos como igualmente urgentes.

Explica las ventajas y desventajas

Una segunda región puede mejorar la resiliencia, pero añade costos de infraestructura, replicación y transferencia. Un duplicado completo aproximadamente duplica el costo de los componentes duplicados. Un entorno en espera más pequeño cuesta menos y suele tardar más en restaurar la capacidad completa. Ninguna de las dos opciones puede elegirse con criterio sin un requisito de tiempo de inactividad y recuperación aceptables.

Una reducción de costos que elimina una copia de recuperación necesaria puede empeorar la fiabilidad. Los controles de seguridad adicionales pueden añadir esfuerzo y gasto mientras reducen el riesgo. El objetivo es un equilibrio justificado, no la máxima puntuación posible en cada pilar por separado.

Imagina un servicio que puede tolerar una interrupción de varias horas y otro que pierde ingresos importantes después de unos minutos. El mismo diseño costoso con una segunda región puede tener distinto valor para los dos servicios. Registra el requisito de negocio que justifica la elección y revísalo cuando cambien el tráfico, la arquitectura o la criticidad.

Una evaluación de buena arquitectura se centra en una carga de trabajo. Un plan para toda la organización sobre competencias, gobernanza y migración usa un marco de adopción de la nube. Mantén conectados ambos niveles: los estándares de toda la organización ayudan a los equipos, mientras que los hallazgos de las cargas de trabajo revelan carencias prácticas en esos estándares.

Un marco de adopción de la nube guía la migración de una organización a la nube. Conecta los objetivos de negocio, las personas, la gobernanza, la seguridad y las operaciones con el trabajo técnico. Una evaluación de buena arquitectura pregunta cómo debe funcionar una carga de trabajo; la orientación de adopción pregunta cómo se prepara la organización para crear y operar muchas cargas de trabajo.

Usa las perspectivas y fases de AWS

AWS CAF agrupa las capacidades en seis perspectivas. Business, People y Governance se centran en capacidades de negocio. Platform, Security y Operations se centran en capacidades técnicas. Un caso empresarial corresponde a Business; las competencias del personal, a People; la gestión financiera de la nube, a Governance.

Las fases de su recorrido son Envision, Align, Launch y Scale. AWS describe resultados deseados que incluyen la reducción del riesgo empresarial, la mejora del desempeño ambiental, social y de gobernanza, el aumento de los ingresos y la mejora de la eficiencia operativa. Las perspectivas describen áreas de capacidad; las fases describen el recorrido. Responden a preguntas organizativas diferentes.

Sitúa las tareas de Azure en su marco

Las siete fases de Microsoft son Strategy, Plan, Ready, Adopt, Govern, Secure y Manage. Strategy define por qué adoptar la nube y cómo reconocer el éxito. Plan prepara a las personas y las cargas de trabajo. Ready establece el entorno. Adopt traslada, moderniza y crea cargas de trabajo. Govern controla el entorno, Secure lo protege y Manage lo opera y mejora.

Govern, Secure y Manage continúan junto con las cargas de trabajo en funcionamiento. Son responsabilidades continuas, no tres tareas reservadas para cuando terminen todas las migraciones.

Una zona de aterrizaje es el entorno preparado para las cargas de trabajo, con cuentas o suscripciones, identidad, red, registro, políticas y estructura de facturación. Las zonas de aterrizaje de Azure apoyan Ready; AWS Control Tower ayuda a configurar un entorno con varias cuentas y controles. Prepara estos fundamentos antes de que los equipos empiecen a implementar cargas de trabajo en un entorno sin gobernanza.

Evalúa la madurez en Google Cloud

Google Cloud Adoption Framework usa cuatro temas: Learn, Lead, Scale y Secure. Evalúa cada uno en las fases táctica, estratégica y transformacional de la escala de madurez en la nube de Google. El trabajo táctico se centra en cargas de trabajo individuales sin un plan a largo plazo. El trabajo estratégico prepara para necesidades futuras. Las organizaciones transformacionales operan sin problemas y se centran en la innovación y los datos.

Un equipo puede necesitar mejorar su liderazgo o sus competencias incluso cuando su plataforma técnica es sólida. Evalúa los temas para identificar qué capacidad organizativa frena la adopción; comprar más servicios no proporciona personas formadas ni un plan compartido.

Relaciona tareas reales sin mezclar vocabularios

Para una empresa minorista, «reducir los costos del centro de datos un 20 % en tres años» corresponde a Strategy de Microsoft y a la perspectiva Business de AWS. «Formar a 40 empleados» corresponde a Plan de Microsoft y a People de AWS. «Preparar cuentas, red y políticas» corresponde a Ready de Microsoft y a Platform de AWS. Migrar 30 aplicaciones corresponde a Adopt de Microsoft; las etiquetas y presupuestos corresponden a Govern y a Governance de AWS. Supervisar los servicios en ejecución corresponde a Manage de Microsoft y a Operations de AWS.

Usa las etiquetas propias de cada proveedor al explicar la relación. AWS no tiene una fase llamada Ready y el tema Learn de Google no es una fase de Azure. Adapta la orientación a los objetivos de la organización, ordena el trabajo según sus dependencias y mantén activas la gobernanza y las operaciones después de que lleguen las primeras cargas de trabajo.