Resumen

  • La discusión sobre portabilidad se ha desplazado de una pregunta simple —cuánto cuesta sacar datos— a otra más exigente: qué derecho contractual existe para qué movimiento. AWS, Azure y Google ofrecen mecanismos de salida y de multicloud con perímetros diferentes. País de cuenta o facturación, región de origen, ruta de red, servicio elegible, finalidad, propiedad del destino y procedimiento pueden cambiar el resultado dentro de una misma marca global.

  • La evidencia británica no respalda tratar el egress como la barrera universal ni necesariamente como la principal. La CMA concluyó en 2025 que obstáculos técnicos y comerciales restringían el cambio de proveedor y el multicloud, pero los clientes describieron un cuadro mixto: las transferencias pesan mucho en diseños sincronizados o de gran volumen; en otros casos importan tanto o más la diferenciación técnica, PaaS y serverless, el gasto comprometido y el trabajo de migración.

  • Reino Unido y la Unión Europea están convirtiendo parte de la portabilidad en un derecho más explícito, pero no han creado una regla mundial uniforme. El Data Act eliminará desde el 12 de enero de 2027 los cargos por el proceso de cambio cubierto, mientras permite trasladar por separado determinados costes de egress para el uso paralelo. La cuestión competitiva no es lograr una tarifa cero idéntica en todas partes, sino hacer legibles, comparables y utilizables los derechos antes de que arquitectura y compromisos comerciales hagan costoso ejercerlos.

Una transferencia ya no se entiende sin su dirección

Durante años, el precio de salida de datos funcionó como abreviatura del problema de portabilidad de la nube. Era una medida visible: tantos gigabytes cruzan el perímetro, tantos euros o dólares aparecen en la factura. Esa simplicidad resulta cada vez menos útil.

Lo que importa ahora es la combinación de derecho, precio y procedimiento. Un cliente puede tener una salida gratuita si abandona un servicio, pero no si mantiene ese servicio y replica datos de forma permanente en otra nube. Puede disponer de 60 días con una dirección de facturación y de 180 con otra. Puede obtener un tratamiento reducido por Internet pero no por una red prémium, salvo que el origen esté en un conjunto determinado de centros de datos. Puede cumplir todos esos requisitos y quedar fuera porque el destino sirve a terceros en vez de pertenecer a la misma organización.

Ese es el sentido de decir que la portabilidad tiene domicilio. No se trata de un código postal literal, sino de geografía contractual: dónde está adscrita la relación comercial, dónde se ejecuta la carga y bajo qué ruta y finalidad se mueve la información.

La investigación de mercado de la Competition and Markets Authority británica ayuda a entender por qué esta precisión importa. En 2025, la CMA concluyó que barreras técnicas y comerciales restringían la capacidad de cambiar de proveedor y de utilizar varias nubes. Pero no encontró una explicación monocausal.

Para determinados clientes y arquitecturas, sobre todo cuando grandes bases de datos deben mantenerse sincronizadas, el egress puede ser un coste material y recurrente. Para otros, la dificultad está en otro sitio: interfaces distintas, servicios administrados difíciles de sustituir, PaaS y serverless, capacidades especializadas, habilidades internas, compromisos de gasto y el coste humano de rediseñar una aplicación.

Una política de portabilidad puede, por tanto, rebajar una barrera sin hacer que un sistema sea portátil de verdad.

Salir, salir de un servicio y convivir no son lo mismo

Hay tres movimientos que conviene separar.

El primero es la salida completa: una organización deja de utilizar un proveedor o el conjunto pertinente de servicios y lleva sus datos y cargas a otro proveedor o a infraestructura propia. Es el caso más parecido a una migración convencional, con una transferencia concentrada en el tiempo y un destino definido.

El segundo es la salida parcial o por servicio. El cliente abandona, por ejemplo, una categoría elegible pero conserva otras dentro del mismo hiperescalador. Comercialmente es distinta de cerrar toda la relación. Técnicamente también: identidades, redes, observabilidad o aplicaciones pueden seguir dependiendo de servicios que permanecen.

El tercero es el multicloud paralelo continuo. Nadie está saliendo necesariamente. Dos servicios de proveedores distintos funcionan a la vez y se transfieren datos de manera reiterada. En una arquitectura poco integrada, ese tráfico puede ser reducido. En una plataforma sincronizada, analítica o intensiva en datos, puede convertirse en una variable estructural del coste.

Confundir estos tres movimientos produce malas comparaciones. Una promesa de «egress gratuito» puede ser muy valiosa para la primera categoría y casi irrelevante para la tercera. Un régimen que protege el cambio de un único servicio puede ampliar la capacidad negociadora sin hacer económicamente viable una replicación permanente. Y una interconexión barata puede facilitar el multicloud sin resolver la portabilidad de un servicio propietario.

El Data Act europeo formaliza precisamente esa diferencia. Sus reglas sobre cambio y sus reglas sobre uso paralelo no son idénticas. Esa separación es económicamente sensata: una transferencia extraordinaria para abandonar un proveedor no genera el mismo patrón de costes que un flujo recurrente diseñado para mantener dos proveedores operativos al mismo tiempo.

Reino Unido: derechos nuevos, resultados todavía no demostrados

El Reino Unido ofrece ahora una vista temprana de cómo puede evolucionar esa geografía contractual.

En su documento del 31 de marzo de 2026, la CMA registró medidas de AWS y Microsoft destinadas a ampliar el periodo de cambio a 180 días para clientes británicos, permitir que el beneficio alcance la salida de un solo servicio, reducir determinados costes de transferencias multicloud continuas, dar base contractual a los derechos de egress y facilitar interconexiones directas.

El cambio no es trivial. Pasar de una política promocional o administrativa a un derecho contractual reduce una forma de discrecionalidad. Permitir la salida de un servicio evita obligar al comprador a elegir entre conservar toda la arquitectura o desmantelar toda la relación comercial para obtener el beneficio. Y añadir rutas de interconexión puede reducir trabajo de ingeniería, no solo una línea de coste de red.

Pero el límite de la prueba es importante. La CMA también dijo que hacían falta más pasos y que revisaría el progreso a los seis meses. A 22 de agosto de 2026 ese momento todavía no había llegado. Lo observable son compromisos, cambios de términos, productos y derechos. No hay todavía evidencia posterior suficiente para afirmar qué efecto tendrán sobre la competencia, qué proporción de clientes los utilizará o cuánto cambiarán realmente las decisiones de arquitectura.

La distinción entre remedio disponible y remedio eficaz es central. Un derecho que existe pero resulta difícil de descubrir, solicitar o modelizar puede disciplinar menos al proveedor que uno incorporado desde el principio a la comparación económica de una compra.

AWS: el país de la cuenta cambia el derecho

AWS muestra con claridad la diferencia entre una política global y un derecho definido por domicilio contractual.

Su programa global permite solicitar a Support la transferencia gratuita de datos hacia Internet cuando el cliente está saliendo de AWS. La ventana ordinaria es de 90 días y el uso del programa no obliga por sí solo a cerrar la cuenta. Es una mejora concreta para una migración de salida, pero sigue siendo un procedimiento que el cliente debe identificar y activar.

El addendum británico crea otra capa. La elegibilidad se vincula al Account Country: la cuenta pagadora debe tener Reino Unido como país de cuenta. El cliente debe avisar con dos meses de antelación y dispone de un periodo de transición de 180 días. La definición cubre tanto una salida completa como el cambio de uno o más servicios elegibles mientras se continúan usando otros servicios de AWS.

Eso altera la economía de una migración parcial. Una empresa ya no necesita valorar únicamente qué ocurriría si abandona por completo AWS; puede negociar y diseñar pensando en la posibilidad de retirar un servicio concreto.

Para el multicloud paralelo, sin embargo, la lógica vuelve a cambiar. El addendum contempla transferencias a tarifas que no excedan los costes de AWS cuando sus servicios se utilizan junto a los de otro proveedor. El destino debe responder al uso interno del mismo cliente. Quedan fuera las transferencias destinadas a usuarios finales, clientes u otros terceros. Además, el beneficio requiere una solicitud previa a Support.

AWS Interconnect – multicloud introduce otro mecanismo: no aplica un cargo AWS por gigabyte en el producto, y existe una interconexión gratuita de 500 Mbps por proveedor de nube y por región AWS. Pero la otra nube fija y cobra independientemente su propio lado. Incluso una ruta que elimina una clase de cargo no convierte la conexión completa en coste cero.

La lección contractual es más importante que la marca. «AWS permite egress gratuito» no es una frase suficientemente precisa para una decisión de infraestructura. Hay que preguntar: ¿qué cuenta, qué servicio, qué movimiento, durante cuánto tiempo, hacia quién y por qué ruta?

Azure: facturación, origen y camino de red

Azure construye un mapa parecido con variables distintas.

En el mecanismo global de salida, el cliente puede recibir un crédito por egress a través de Internet durante 60 días y, después de completar la transferencia, debe cancelar las suscripciones correspondientes al proceso global. ExpressRoute, VPN, Azure Front Door y CDN no entran en esa oferta. La gratuidad, por tanto, no describe todas las formas de sacar información de Azure: describe una finalidad y una ruta elegibles.

Para clientes con dirección de facturación en Reino Unido y datos que salen de centros de datos británicos, el perímetro es más amplio. La ventana llega a 180 días; la salida puede producirse por servicio; y la Microsoft Global Network puede quedar cubierta bajo las condiciones previstas para ese escenario.

La arquitectura multicloud continua tiene otra ficha. El tratamiento a coste se dirige a organizaciones con facturación en el Espacio Económico Europeo, la AELC o Reino Unido, sujeto a reglas de localización. El cliente debe tramitar la solicitud mediante Support y facilitar información como la suscripción, el ASN del extremo externo y una estimación del tráfico. El procesamiento de destino debe pertenecer a la misma organización; una distribución CDN o una transferencia hacia otro cliente no es el mismo caso.

La ruta vuelve a importar. Para ciertos supuestos europeos, el régimen se articula sobre egress por Internet a través del camino ISP. En el Reino Unido, si el tráfico parte de centros de datos británicos, también puede alcanzar la MGN bajo las condiciones correspondientes.

Esto produce algo que las hojas de cálculo de compra suelen tratar mal: dos aplicaciones alojadas en la misma plataforma comercial pueden tener un coste de opcionalidad distinto porque una reside en otra región, utiliza otra ruta o sirve a otra clase de destinatario.

Google: abandonar un servicio no equivale a mantenerlo abierto

Google separa también el derecho de salida de la conectividad multicloud estable.

Exit Cloud sigue una secuencia de aviso, inicio, migración y cierre del servicio pertinente. Para productos elegibles, la transferencia puede ser gratuita cuando el cliente abandona ese servicio. La salida puede limitarse a un servicio concreto mientras otros servicios de Google Cloud continúan, pero dentro del servicio que se abandona el concepto de salida exige dejar de utilizarlo, no trasladar simplemente una fracción de los datos y mantener el resto funcionando igual.

Para escenarios parciales o paralelos europeos aparece Data Transfer Essentials. Aquí no estamos ante una excepción de salida, sino ante un mecanismo para tráfico cualificado entre servicios de la misma organización distribuidos entre proveedores.

La oferta es inicialmente gratuita cuando se utiliza conforme a sus reglas, pero el calificativo «gratuita» vuelve a necesitar varias líneas de contexto. Solo determinados servicios, niveles y regiones europeas son compatibles. La configuración depende de conectividad mediante IP externas, destinos registrados y ASN reconocidos. No está diseñada para servir a terceros. No tiene SLA propio. Si un destino deja de cumplir los criterios, el tráfico puede volver a facturarse al precio ordinario. Y un servicio inscrito en un proceso de salida no puede tratarse simultáneamente como si fuera simplemente una pata estable del esquema paralelo.

Es una forma útil de interoperabilidad económica, pero estrechamente definida. Eso no es necesariamente un defecto: las condiciones pueden ser legítimas para separar una transferencia intraorganizativa de una entrega comercial a terceros. El problema surge cuando el comprador no puede descubrir esa frontera hasta después de haber diseñado la arquitectura.

Europa: 2027 no convierte en gratuito todo el multicloud

El Data Act de la Unión Europea, aplicable desde el 12 de septiembre de 2025, convierte parte de estas cuestiones en obligaciones generales.

El artículo 25 exige que los derechos del cliente y las obligaciones del proveedor en materia de cambio se expresen claramente en contrato. Es un desplazamiento importante desde la portabilidad como favor comercial hacia la portabilidad como término que debe poder conocerse antes de contratar.

El artículo 29 introduce una transición económica. Hasta el 12 de enero de 2027 pueden existir cargos reducidos de cambio, pero no deben exceder los costes directamente vinculados al proceso. Desde esa fecha, el proveedor no podrá imponer cargos por el proceso de cambio cubierto.

La fecha ha generado una interpretación demasiado fácil: «el egress europeo será gratis en 2027». No es una descripción completa. El artículo 34 aborda por separado el uso en paralelo de servicios de procesamiento de datos. Cuando dos servicios se utilizan simultáneamente, el proveedor puede trasladar costes de egress incurridos, sin excederlos.

La diferencia refleja la economía subyacente. Europa pretende evitar que abandonar a un proveedor dependa de una penalización que refuerce el bloqueo. No exige que un flujo multicloud recurrente carezca siempre de coste de transporte.

Eso también pone un límite útil al debate regulatorio. La meta competitiva no necesita ser una tarifa universal de cero. Puede ser un mercado en el que los costes legítimos sean visibles y los derechos de salida sean suficientemente utilizables para que la amenaza de marcharse discipline al proveedor.

La prueba de mercado: portabilidad que pueda ejercerse

Aplicada a la nube, la prueba de mercado exige mirar más allá de la existencia nominal de una opción. Sin portabilidad utilizable, un servicio deja de ser solo una oferta técnica y adquiere poder sobre la decisión futura del comprador. El proveedor debe tener incentivos para retener al cliente por calidad, precio e innovación, no por el temor a una salida impracticable.

Eso no significa borrar la diferenciación. Un servicio serverless puede ser mejor precisamente porque está profundamente integrado. Una base de datos administrada puede justificar costes de migración reales. Una red puede tener costes distintos según distancia y ruta. La competencia no requiere fingir que todas las nubes son intercambiables.

Sí requiere que la geografía contractual no oculte quién conserva el control comercial. Si una empresa obtiene un derecho de salida por tener facturación británica, pero no puede saber al comprar qué regiones, servicios y rutas lo preservan, el derecho llega demasiado tarde para influir en el diseño. Si una oferta multicloud exige que el destino pertenezca a la misma organización, esa frontera debe ser comprensible antes de que el caso de uso se convierta en producción.

Las condiciones comunes, por tanto, deben ser delgadas, explícitas y verificables: qué cuenta está cubierta, qué servicios son elegibles, qué datos pueden trasladarse, qué rutas cuentan, qué destino se admite, cuánto dura la ventana, qué ocurre con una salida parcial y qué trámite activa el beneficio.

La portabilidad útil no elimina el coste de cambiar. Hace posible conocerlo antes de quedar atrapado en él.

Fuentes

Competition and Markets Authority — Cloud services market investigation https://www.gov.uk/cma-cases/cloud-services-market-investigation

Competition and Markets Authority — Final decision report https://assets.publishing.service.gov.uk/media/688b8891fdde2b8f73469544/final_decision_report.pdf

Competition and Markets Authority — Appendix N: Egress fees – free switching programmes https://assets.publishing.service.gov.uk/media/688b8169fc784fa12a089071/Appendix_N_-_Egress_fees___free_switching_programmes.pdf

Competition and Markets Authority — Appendix O: Customer views on egress fees https://assets.publishing.service.gov.uk/media/688b817cfc784fa12a089072/Appendix_O_-_Customer_views_on_egress_fees.pdf

Competition and Markets Authority — Actions on cloud and business software through the UK digital markets competition regime https://assets.publishing.service.gov.uk/media/69cbb8d52d120d9d5ec0f311/Actions_on_cloud_and_business_software_through_the_UK_digital_markets_competition_regime.pdf

AWS — Free data transfer out to internet when moving out of AWS https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-internet-when-moving-out-of-aws/

AWS — UK Customer Switching and Portability Addendum https://d1.awsstatic.com/onedam/marketing-channels/website/aws/en_US/legal/approved/aws-uk-customer-switching-addendum.pdf

AWS — Interconnect – multicloud Pricing https://aws.amazon.com/interconnect/multicloud/pricing/

Microsoft — Cancel and delete your Azure subscription https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/cancel-azure-subscription

Microsoft — Azure data transfer fees https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/data-transfer-fees

Google Cloud — Applying for free data transfer when exiting Google Cloud https://cloud.google.com/exit-cloud

Google Cloud — Data Transfer Essentials overview https://docs.cloud.google.com/data-transfer-essentials/docs/overview

Google Cloud — Data Transfer Essentials: supported services and regions https://docs.cloud.google.com/data-transfer-essentials/docs/services

EUR-Lex — Reglamento (UE) 2023/2854, Data Act https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32023R2854

Comisión Europea — Data Act explained https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained