Optimización de Costes – Cloudner

AWS Cloud Intelligence Dashboards

cloudner — Tue, 17 Feb 2026 00:55:30 +0000

En el post anterior hablábamos de si realmente necesitas una herramienta FinOps de terceros o si puedes empezar con lo que AWS ya pone a tu disposición. Hoy entramos en detalle en una de las soluciones más completas que AWS ha publicado dentro de su propio ecosistema.

En este artículo vamos a ver qué es AWS Cloud Intelligence Dashboards, cuáles son sus principales dashboards (CUDOS, CID y KPI), cómo se despliega y qué se puede hacer realmente con ellos en un entorno empresarial.

¿Qué es AWS Cloud Intelligence Dashboards?

AWS Cloud Intelligence Dashboards no es un producto SaaS ni una licencia adicional que contratar. Es un framework de dashboards desarrollado por AWS que se apoya en tus propios datos de facturación y uso, concretamente en el Cost and Usage Report (CUR).

La arquitectura de la herramienta es sencilla. El CUR se almacena en S3, se estructura mediante Glue, se consulta con Athena y se visualiza en QuickSight. Todo dentro de tu(s) cuenta(s), sin exportaciones a terceros ni dependencias externas. El dato no sale de tu entorno.

El coste está asociado a almacenamiento, consultas y visualización. Y la personalización es total, porque puedes modificar el modelo, las consultas o los dashboards si lo necesitas.

Aunque es una herramienta “plug & play”, también puedes personalizar para construir tu modelo FinOps dentro de AWS.

CUDOS, CID y KPI: tres enfoques distintos del mismo dato

Cuando se habla de AWS Cloud Intelligence Dashboards muchas veces se menciona como si fuera un único dashboard. En realidad, se trata de un framework compuesto por varios dashboards especializados.

A continuación vamos a describir los tres dashboards fundacionales: CUDOS, CID y KPI. A partir de ellos existen otros dashboards más avanzados y específicos (por ejemplo, orientados a sostenibilidad, compromisos o análisis más especializados).

CUDOS (Cost and Usage Dashboard): es el más técnico, permite bajar al detalle del consumo. Aquí puedes analizar tendencias por servicio, por cuenta, por región, por tipo de instancia o por patrón de uso. Es especialmente útil para identificar infrautilización, analizar impacto de Savings Plans y Reserved Instances o entender en qué parte concreta de la arquitectura se está produciendo el crecimiento del gasto. Si quieres detectar recursos mal dimensionados, workloads que no escalan como deberían o transferencias de datos inesperadas, CUDOS es un buen punto de partida.

CID (Cost Intelligence Dashboard): está más orientado a negocio. No busca el detalle técni, busca ofrecer una visión consolidada y comprensible para perfiles financieros o responsables de unidades de negocio. Permite estructurar showback o chargeback interno, entender qué cuentas o centros de coste consumen más y analizar la evolución mensual con un enfoque más ejecutivo.

KPI (Key Performance Indicator): este dashboard te permite medir indicadores como el porcentaje de uso On-Demand, la adopción de Spot Instances o el uso de Graviton. De esta forma, cada línea de negocio puede definir metas concretas y el Cloud Center of Excellence hacer seguimiento transversal. Más que analizar coste pasado, ayuda a dirigir la evolución técnica del entorno hacia un modelo más eficiente.

¿Cómo se instala AWS Cloud Intelligence Dashboards?

El despliegue de AWS Cloud Intelligence Dashboards puede adaptarse a distintos escenarios: desde una única cuenta hasta entornos multi-account gestionados con AWS Organizations. La arquitectura concreta dependerá de cómo tengas estructurado tu entorno y de dónde quieras centralizar el análisis.

AWS documenta los distintos modelos de despliegue, incluyendo separación entre cuenta de datos y cuenta de visualización, en su guía oficial.

A nivel práctico, el proceso se apoya en tres pilares: el Cost and Usage Report (CUR), la capa analítica basada en Athena y Glue, y la visualización en QuickSight.

En un entorno bien preparado, el despliegue completo puede realizarse en una o dos horas. Lo que suele llevar más tiempo no es la instalación, sino adaptar la estructura de cuentas, etiquetas y centros de coste para que el análisis tenga sentido.

Casos de uso

Networking: CUDOS permite analizar en detalle el gasto asociado a Data Transfer, diferenciando entre tráfico intra-región, inter-región y salida a Internet. Esto ayuda a detectar arquitecturas con comunicación innecesaria entre regiones o servicios que generan tráfico excesivo hacia Internet. También es posible identificar uso elevado de NAT Gateway cuando podrían implementarse VPC Endpoints privados. En muchos entornos el networking no se revisa hasta que el coste se dispara. Con este análisis puedes rediseñar la topología de red y optimizar el coste.
S3: en organizaciones con grandes volúmenes de datos, pequeñas ineficiencias se convierten en costes recurrentes significativos. CUDOS facilita justificar técnicamente un cambio de estrategia de almacenamiento. Con CUDOS puedes analizar el coste de S3 por tipo de almacenamiento y detectar si se está utilizando mayoritariamente Standard cuando debería aplicarse Intelligent-Tiering o Glacier. También permite identificar crecimiento sostenido sin políticas de lifecycle definidas.
Showback / Chargeback: CID permite estructurar el gasto por cuenta, entorno o centro de coste, facilitando un modelo claro de showback interno. Cada unidad puede visualizar su evolución mensual y comparar su consumo con periodos anteriores. Esto introduce transparencia y responsabilidad sobre el gasto cloud. El resultado no es solo mejor reporting financiero, sino un modelo de gobierno más maduro y alineado con negocio.

¿Hasta dónde llega Cloud Intelligence Dashboards?

Cloud Intelligence Dashboards no pretende sustituir todas las capacidades de herramientas de FinOps de terceros, especialmente en escenarios multi-cloud o con necesidades avanzadas de integración financiera.

Sin embargo, en organizaciones que trabajan principalmente sobre AWS y que buscan control del gasto, gobierno interno y capacidad de análisis técnico, se propone como una alternativa muy competitiva.

La diferencia fundamental es que aquí el dato está bajo tu control y con total capacidad de personalización. No dependes de un modelo cerrado ni de métricas predefinidas que no siempre encajan con tu realidad.

La visión de Cloudner

En Cloudner utilizamos AWS Cloud Intelligence Dashboards como base técnica en cualquier proceso de optimización de costes en AWS. Es la herramienta que nos permite entender qué está ocurriendo realmente en la cuenta antes de proponer cambios.

Posteriormente, es vital usar el dato proporcionado en los dashboards para tomar decisiones: rediseñar arquitectura cuando no es eficiente, ajustar compromisos mal dimensionados, mejorar el modelo de etiquetado o reorganizar cuentas para que el gasto tenga sentido.

Nuestra experiencia indica que el problema no suele ser la falta de visibilidad, sino traducir esa información en decisiones técnicas y de gobierno concretas. Y es precisamente ahí donde Cloudner aporta valor.

¿Buscas más contenidos sobre arquitectura AWS y FinOps?
Sigue a Cloudner en LinkedIn para no perderte nuestras novedades y consejos.

AWS FinOps Dashboard: análisis de costes AWS desde el terminal (hands-on)

cloudner — Tue, 27 Jan 2026 10:21:14 +0000

Saber cuánto gastas en AWS no es suficiente. El control de costes empieza cuando entiendes en qué se va el dinero, por qué y si ese gasto tiene sentido hoy.

Aquí es donde entra en juego AWS FinOps Dashboard, una herramienta sencilla, directa y muy alineada con la filosofía FinOps: visibilidad, contexto y capacidad de decisión. Es ideal para arquitectos, equipos técnicos y sesiones de revisión básica de FinOps.

En este artículo vamos a ver qué es, cómo funciona y en qué escenarios tiene sentido usarla dentro de una estrategia FinOps.

Qué es AWS FinOps Dashboard

AWS FinOps Dashboard es una herramienta open source (disponible en su repositorio de github) que permite analizar costes y consumo de AWS directamente desde línea de comandos. Está pensada para equipos técnicos y perfiles FinOps que quieren respuestas rápidas sin pasar por múltiples paneles de la consola.

No sustituye a las herramientas nativas de AWS ni a plataformas FinOps enterprise. Su valor está en otro sitio: acceso rápido y sencillo a los datos para tener una conversación técnica basada en datos reales.

Cómo instalar y ejecutar AWS FinOps Dashboard (paso a paso)

A continuación, se detalla un procedimiento paso a paso para instalar y poner en marcha AWS FinOps Dashboard en tu entorno. Cabe mencionar que es una herramienta escrita en Python que se ejecuta localmente, por lo que necesitarás cierta configuración previa:

Prerequisitos – AWS CLI y credenciales: Asegúrate de tener Python 3 instalado en tu sistema, así como la AWS CLI configurada con las credenciales de tu cuenta AWS. Es necesario contar con un perfil de AWS CLI que tenga permisos para obtener información de billing y recursos. Si aún no has configurado la CLI, instala la última versión desde AWS e inicializa un perfil con aws configure, ingresando tu Access Key, Secret Key, región por defecto y formato de salida (por ejemplo, JSON). Este paso es crucial, ya que AWS FinOps Dashboard utilizará ese perfil para consultar los datos de costes de tu cuenta.
Instalar AWS FinOps Dashboard: La forma recomendada de instalación es mediante pipx, que permite instalar aplicaciones Python aisladas del entorno global. Si ya tienes pipx, simplemente ejecuta:

pipx install aws-finops-dashboard

Esto descargará e instalará la herramienta junto con sus dependencias. En caso de no tener pipx instalado, puedes usar pip normal:

pip install aws-finops-dashboard

Ambos métodos instalarán un comando llamado aws-finops en tu sistema.
Ejecutar el dashboard: Una vez instalado, ya puedes usar AWS FinOps Dashboard. Simplemente ejecuta en la terminal:

aws-finops

Al correr este comando, la herramienta detectará tus perfiles de AWS configurados y comenzará a consultar los datos de costes y recursos de AWS. En su primera ejecución puede tardar unos segundos en recoger la información, luego mostrará en la misma terminal un dashboard con tablas y gráficos en formato texto.

Ejemplos de uso el dashboard

Tener los datos frente a ti es solo el primer paso. El segundo es interpretarlos correctamente para tomar acciones de FinOps. A continuación, repasamos algunos ejemplos de uso típico de AWS FinOps Dashboard y cómo sacarle el máximo provecho:

Comparar costes entre entornos o cuentas: si tu organización separa las cargas en distintas cuentas (por ejemplo, producción vs desarrollo), el dashboard te permite visualizar ambas simultáneamente con aws-finops –profiles prod dev. Esto facilita comparar el coste mensual de cada entorno. Una práctica recomendada es combinar perfiles relacionados (usando –combine) para ver el gasto total consolidado por proyecto o cliente, especialmente útil cuando una misma aplicación está repartida en varias cuentas AWS.

Identificar servicios con coste elevado: la columna de Coste por Servicio aparece ordenada de mayor a menor gasto automáticamente. Esto significa que en cuanto abres el dashboard, verás al inicio de cada lista aquellos servicios que más impacto tienen en tu factura. Presta especial atención al servicio top 1 de cada cuenta, ya que suele ser el candidato principal para optimización.
Uso de filtros por etiquetas: Si has implementado una estrategia de etiquetado (tags) en tus recursos AWS, puedes aprovechar AWS FinOps Dashboard para filtrar los costes por etiqueta específica. Por ejemplo, aws-finops –tag Team=DevOps mostrará únicamente los costes de recursos etiquetados con ese equipo. Esto es muy útil para generar informes de coste por departamento, proyecto o cliente.
Análisis de tendencias y patrones: Además del estado corriente, es importante ver cómo evolucionan los costes en el tiempo. AWS FinOps Dashboard incluye una vista de tendencia accesible desde la misma interfaz, que muestra los últimos 6 meses de gasto por cuenta o incluso por etiqueta seleccionada. Observando estas tendencias puedes detectar patrones estacionales, crecimientos anómalos o el efecto de optimizaciones que hayas implementado.

Detección de recursos ociosos: Uno de los mayores quick wins en FinOps es eliminar recursos que se facturan, pero no están en uso. La sección de auditoría de AWS FinOps Dashboard resalta estos casos: instancias EC2 detenidas, volúmenes EBS sin uso, IPs elásticas no asociadas y presupuestos excedidos.

Limitaciones que debes tener en cuenta

Como toda herramienta especializada, AWS FinOps Dashboard no es una solución mágica ni pretende reemplazar sistemas más avanzados. Algunas consideraciones importantes son:

No sustituye a AWS Cost Explorer ni a soluciones FinOps empresariales: su propósito es ofrecer visibilidad rápida desde el terminal gracias a su diseño minimalista. Es ideal como primer vistazo, pero no como herramienta de auditoría completa ya que no cubre todas las funcionalidades de análisis o automatización que sí tienen herramientas más robustas.
No gestiona presupuestos ni permite configurar alertas complejas: aunque puede mostrar si se está excediendo un budget, no automatiza notificaciones o acciones correctivas.
No interpreta tu negocio: los datos están ahí, pero el contexto, las prioridades y las decisiones siguen dependiendo del equipo.

AWS FinOps Dashboard ofrece una base clara para iniciar conversaciones entre los equipos técnicos y financieros. No toma decisiones por ti, pero te entrega la información necesaria para que todos trabajen con una visión compartida sobre los costes Cloud.

La visión de Cloudner

En Cloudner utilizamos herramientas como AWS FinOps Dashboard como soporte en procesos FinOps. El valor no está en los datos que muestra, sino en cómo los interpretamos y qué decisiones tomamos a partir de ellos.

Para nosotros, hacer FinOps no significa simplemente reducir gastos, sino entender qué está aportando valor real a tu negocio y qué no. Una optimización efectiva parte de estas premisas:

Tener visibilidad completa y continua del consumo.
Relacionar costes con decisiones técnicas y de arquitectura.
Revisar antes de que llegue el problema, no solo tras una factura inesperada.

AWS FinOps Dashboard es un ejemplo de cómo una herramienta sencilla puede ser el catalizador de las conversaciones correctas. Es especialmente útil cuando una organización da sus primeros pasos en FinOps, ya que permite empezar a hablar de costes con datos y sin necesidad de una infraestructura de análisis avanzada.

En Cloudner ayudamos a equipos técnicos y de negocio a implementar una visión FinOps práctica y técnica, analizando la arquitectura y los costes de tus cuentas AWS con un enfoque orientado a resultados.

¿Buscas más contenidos sobre arquitectura AWS y FinOps?
Sigue a Cloudner en LinkedIn para no perderte nuestras novedades y consejos.

Probando Amazon ECS Managed Instances

cloudner — Fri, 31 Oct 2025 08:46:33 +0000

AWS ha lanzado recientemente ECS Managed Instances, una nueva opción de cómputo dentro de Amazon ECS (Elastic Container Service) que busca resolver un dilema clásico: elegir entre el control total de EC2 y la comodidad operativa de Fargate.

Hasta ahora, ECS ofrecía dos modos de ejecución muy distintos. Con EC2 launch type, los equipos gestionaban sus propias instancias, lo que daba máxima flexibilidad pero también conlleva más carga operativa. Con Fargate, AWS se ocupaba de todo, aunque a costa de perder visibilidad y capacidad de optimización sobre el hardware.

Managed Instances se posiciona justo entre las dos opciones existentes. Mantiene la base de EC2, pero delega en AWS la gestión del ciclo de vida de las instancias, el parcheo del sistema operativo y el escalado automático del clúster.

Características principales

ECS Managed Instances aprovisiona y escala las instancias de forma dinámica, consolidando tareas para aprovechar mejor los recursos y apagar los nodos inactivos. Teoricamente, esto permite mantener costes bajos y una utilización de CPU más eficiente.

La elección de instancias es flexible: puedes dejar que ECS seleccione automáticamente el tipo más rentable (ECS default) o definir tus propios criterios custom de hardware, red y arquitectura.

Además, el servicio se integra con el resto del ecosistema ECS sin cambios de configuración. Los servicios, tareas y despliegues funcionan igual que con EC2 o Fargate, lo que facilita su adopción en entornos existentes.

En cuanto a disponibilidad, la feature está ya desplegada en varias regiones, incluidas us-east-1, us-west-2 y eu-west-1, con expansión progresiva al resto de regiones comerciales.

¿Por qué usar esta opción?

El objetivo de ECS Managed Instances es claro: simplificar la operación de los entornos ECS sin renunciar al control del cómputo subyacente.

En lugar de tener que aprovisionar y mantener manualmente las instancias EC2, AWS se encarga de hacerlo por ti, eligiendo los tipos más eficientes según tus requisitos de CPU, memoria, arquitectura o incluso GPU.

Para entornos en los que Fargate resulta demasiado opaco, Managed Instances ofrece un punto de equilibrio muy interesante. Reduce la complejidad sin perder la posibilidad de afinar el rendimiento o aprovechar tus Savings Plans y reservas existentes de EC2.

Managed Instances tiene un enfoque muy elevado en la seguridad y el mantenimiento automático. Las instancias gestionadas utilizan Bottlerocket, el sistema operativo optimizado para contenedores de AWS, que se parchea y actualiza de forma continua, eliminando buena parte de las tareas rutinarias de mantenimiento.

¿Cuándo usar esta opción?

Managed Instances es ideal cuando necesitas personalizar el tipo de instancia (usar GPU, evitar instancias burstable, etc), pero no quieres invertir tiempo en gestionar un clúster de EC2. También cuando deseas aprovechar descuentos de EC2 o reducir los costes de Fargate sin asumir toda la complejidad operativa.

Por el contrario, si tus cargas son muy efímeras o totalmente desacopladas del hardware, Fargate seguirá siendo la opción más simple.

Prueba práctica con ECS Managed Instances

Para poner a prueba esta nueva funcionalidad, preparamos un entorno siguiendo la guía oficial de AWS.

La configuración inicial se realizó usando la opción ECS default para la selección de instancias, de modo que fuese el propio servicio quien eligiera automáticamente los tipos más adecuados en función de los requisitos definidos en la task definition.

Escenario de prueba y primeras ejecuciones

Creamos un servicio en ECS con una definición de tarea que incluía un único contenedor, configurado con 1 vCPU y 2 GB de RAM. El servicio estaba habilitado con Availability Zone Rebalancing, de forma que ECS pudiera distribuir las tareas de manera uniforme entre las dos zonas de disponibilidad seleccionadas.

A partir de ahí fuimos ajustando el número de tareas en ejecución (6, 5 y 4) para observar cómo el sistema gestionaba la capacidad y el aprovisionamiento de instancias.

En la imagen superior puede verse el resultado de la primera prueba. Con 6 tareas simultáneas, ECS seleccionó varios tipos de instancia (como c6a.xlarge, m7a.medium y m5a.large). La combinación no parece la más eficiente desde el punto de vista del coste y da margen a seleccionar mejor el tipo de instancia.

Al revisar una de las instancias gestionadas (ver imagen inferior) comprobamos que quedaban recursos disponibles no utilizados, especialmente memoria y CPU, lo que sugiere que la lógica de asignación automática aún tiene margen de mejora en este tipo de escenarios.

Ajuste de recursos y observaciones

En la prueba anterior observamos que en las instancias gestionadas no perdemos CPU a asignar a los contenedores pero si perdemos algo de memoria. Por este motivo, quisimos comprobar si el comportamiento de asignación de instancias cambiaba con cargas más pequeñas. Para ello, modificamos la task definition para usar 0,5 vCPU y 0,4 GB de RAM por contenedor. También modificamos el servicio para definir el número de tareas deseadas a 4.

Tras dichos cambios, el resultado fue similar al anterior. ECS volvió a crear nuevas instancias sin aprovechar del todo combinaciones que podrían haber resultado más eficientes económicamente.

En la imagen superior se observa cómo el sistema distribuye 4 tareas entre 3 instancias activas, manteniendo un equilibrio correcto a nivel operativo, aunque con cierta infrautilización de recursos. La realidad es que las cargas se podían ejecutar en 2 instancias del tipo c7a.medium, una en cada zona de disponibilidad, con el consiguiente ahorro al eliminar una instancia.

La visión de Cloudner

La experiencia nos deja una impresión agridulce, pero prometedora si se configura el tipo de instancia de forma custom.

Por un lado, ECS Managed Instances ha gestionado de forma completamente autónoma la creación y eliminación de instancias para adaptarse a la capacidad esperada. El escalado ha sido estable, rápido y sin intervención manual. Por otro, la selección de tipos de instancia podría afinarse más. El modo ECS default tiende a elegir combinaciones que funcionan correctamente, pero no siempre maximizan la eficiencia económica.

Por eso, aunque esta feature simplifica la operación, sigue siendo importante contar con una estrategia de optimización de costes y arquitectura, especialmente en entornos productivos.

Servicios como los que ofrecemos en Cloudner ayudan precisamente a analizar patrones de consumo, identificar ineficiencias y ajustar tanto la configuración de ECS Managed Instances como las reservas EC2 para alcanzar el equilibrio perfecto entre coste, rendimiento y resiliencia.

¿Quieres revisar cómo optimizar los costes de tu infraestructura en AWS? Hablemos.

Reducir costes de tráfico outbound en AWS

cloudner — Mon, 09 Jun 2025 20:25:55 +0000

En este artículo analizamos un escenario técnico habitual en arquitecturas centralizadas sobre AWS, donde el tráfico de salida a internet genera costes inesperados. Exploramos cómo se puede abordar el problema, mejorar la visibilidad y reducir costes de tráfico en AWS sin comprometer la escalabilidad ni la seguridad.

El síntoma: costes outbound elevados

En muchas organizaciones, al revisar los informes de costes de AWS, aparece un patrón recurrente: gastos altos en la transferencia de datos hacia internet.

Este tipo de costes suelen pasar desapercibidos hasta que crecen demasiado. El problema no sólo es el volumen de tráfico, sino también la falta de visibilidad: no se sabe con precisión qué workloads, ni desde qué VPCs, están generando ese tráfico.

Análisis técnico: identificar el origen del tráfico saliente

1. Activación de VPC Flow Logs

Una primera medida consiste en habilitar VPC Flow Logs tanto en la VPC de inspección como en otras VPCs conectadas al Transit Gateway.

Los logs se envían a Amazon S3.
Se analizan con Amazon Athena creando tablas externas.

2. Enriquecimiento con datos de ENIs

Para mapear el tráfico a workloads específicos, se correlacionan los ENIs (Elastic Network Interfaces) con instancias EC2, servicios o nodos EKS. Esto permite:

Identificar qué ENIs están generando tráfico saliente
Relacionar cada ENI con su workload y su cuenta de origen

3. Consultas específicas en Athena

Se ejecutan consultas filtrando:

Tráfico con dstaddr fuera de los rangos reservados para IPs privadas.
Flujos con action = ACCEPT y interface_id asociada a la VPC outbound
Mostrar resultados agregados por srcaddr, account_id y tgw_src_vpc_id para entender los patrones

El análisis puede revelar tráfico de salida innecesario como:

Automatismos mal diseñados
Aplicaciones legacy que llaman periódicamente a APIs públicas de AWS
Servicios internos mal configurados

Acciones correctivas

1. Uso de Endpoints Privados (Gateway Endpoints)

Se pueden sustituir accesos públicos por privados para servicios como:

Amazon S3
Amazon DynamoDB
Servicios internos expuestos públicamente

Una forma directa de reducir tráfico outbound innecesario es crear VPC Gateway Endpoints para servicios como S3 o DynamoDB. Esto permite enrutar las peticiones a través de la red privada de AWS de una forma muy económica.

También es habitual encontrar servicios internos a los que se acceden usando DNS públicos.
Esto puede resolverse configurando las VPCs y las Private Hosted Zones para forzar la resolución interna y mantener el tráfico dentro de la red privada.

2. Establecimiento de límites y alarmas

Para evitar futuros escenarios similares, se pueden aplicar las siguientes medidas de control:

Creación de un dashboard de networking para mejorar la visibilidad y poder comprobar el tráfico entrante y saliente de cada uno de los attachments del Transit Gateway.
Creación de alarmas para notificar si alguno de los attachment del Transit Gateway está superando el umbral máximo esperado de tráfico entrante o saliente.

Resultado final

Aplicando este enfoque, una organización puede:

Identificar con precisión qué workloads generan el tráfico de salida
Eliminar tráfico público innecesario redirigiéndolo a rutas privadas mediante Gateway Endpoints y DNS interno
Establecer una base técnica para el control y la previsión de costes de red.

Lecciones clave

El tráfico a internet puede ser uno de los costes más difíciles de auditar si no se monitoriza adecuadamente.
VPC Flow Logs y Athena permiten un análisis granular sin necesidad de herramientas externas.
Los VPC Gateway Endpoints privados son una solución sencilla, efectiva y segura para reducir tráfico saliente.
La gestión de costes no es solo una cuestión financiera: es una pieza clave del gobierno Cloud.

¿Tienes una arquitectura similar o estás viendo costes que no sabes explicar?

En Cloudner te ayudamos a detectar estos patrones de tráfico, mejorar la visibilidad y optimizar el diseño de red para reducir costes sin comprometer seguridad ni escalabilidad.