Una empresa desarrolla una aplicación y quiere venderla a clientes que ya compran tecnología a través de Amazon Web Services. ¿Tiene que utilizar Amazon Bedrock? ¿Necesita contratar una auditoría SOC 2? ¿Debe alojar toda su infraestructura en AWS? ¿Qué comisión se queda Marketplace y cuándo merece la pena convertirse en partner? Las respuestas dependen del programa concreto. AWS Partner Network, AWS Marketplace y Foundational Technical Review no son la misma cosa.

Esta guía, actualizada a octubre de 2026, explica cómo funcionan estos mecanismos desde la perspectiva de cualquier empresa de software, sin referirse a productos o proyectos de una compañía específica. Nos apoyamos en la documentación oficial de AWS Marketplace y en AWS Partner Network. Las condiciones comerciales y de elegibilidad pueden cambiar; antes de contratar o publicar un producto conviene revisar siempre la versión vigente.

1. Tres caminos distintos: partner, vendedor y solución validada

AWS Partner Network (APN) es un programa para organizaciones que desarrollan software, ofrecen servicios profesionales o comercializan soluciones relacionadas con AWS. La inscripción y los recorridos de partner permiten acceder a información, formación y, cuando se cumplen criterios adicionales, programas de colaboración comercial. Registrarse no garantiza clientes, financiación ni acceso automático a todos los beneficios.

AWS Marketplace es un canal de venta donde los clientes pueden encontrar y adquirir software y determinados servicios. Ser vendedor implica superar requisitos de registro, facturación, fiscalidad, soporte y publicación del producto. Una empresa puede estudiar Marketplace sin que eso signifique tener ya una solución validada mediante FTR.

Foundational Technical Review (FTR) es una revisión técnica de soluciones vinculada a buenas prácticas de arquitectura, seguridad, fiabilidad y operaciones. En la modalidad simplificada anunciada en junio de 2026, AWS acepta un informe SOC 2 Type II o un informe AWS Well-Architected Framework Review (WAFR), siempre que se cumplan los requisitos de validación. Es un paso distinto de darse de alta como vendedor.

2. ¿Es necesario utilizar Amazon Bedrock?

No. Bedrock es un servicio de modelos de inteligencia artificial, no una condición universal para vender aplicaciones en AWS Marketplace ni para solicitar la incorporación a APN. Una solución puede ser un SaaS de gestión empresarial, seguridad, productividad, análisis de datos o cualquier otra categoría de software admitida.

La arquitectura determina qué integraciones técnicas necesita el producto. Un SaaS publicado en Marketplace sí tiene que incorporar los mecanismos pertinentes de suscripción, contratación, control de acceso y, cuando corresponda, medición de consumo o derechos de uso. Nada de ello obliga por definición a integrar Bedrock.

3. ¿Hay que disponer de SOC 2 Type II para empezar a vender?

No existe un requisito general que obligue a todo nuevo vendedor de AWS Marketplace a presentar SOC 2 Type II. La elegibilidad para vender productos de pago depende, entre otras cuestiones, de tener una cuenta AWS en buen estado, aceptar las condiciones del programa, estar en una jurisdicción admitida y aportar información fiscal y bancaria, además de pasar los procesos de verificación aplicables.

Sin embargo, no hay que confundir el requisito de admisión de Marketplace con las exigencias particulares de un cliente o programa. Algunas empresas compradoras pueden solicitar SOC 2, ISO 27001 u otras evidencias por sus propios procesos de contratación y seguridad.

SOC 2 Type II es un informe emitido por un auditor independiente sobre el funcionamiento de determinados controles durante un periodo. Su elaboración y auditoría suelen representar un coste significativo. Para una empresa pequeña, preparar la arquitectura y los controles básicos antes de asumir ese gasto puede ser sensato, siempre que no exista una obligación contractual o regulatoria que lo exija.

4. Qué son FTR, WAFR y PRM

FTR: validación técnica de una solución

La Foundational Technical Review ayuda a evaluar riesgos técnicos y acreditar determinadas buenas prácticas de una solución. La revisión se presenta como autoservicio y sin tarifa directa por parte de AWS. Su aprobación puede facilitar distintivos, visibilidad y acceso condicionado a programas posteriores.

WAFR: una vía alternativa a SOC 2 para FTR

Desde junio de 2026, la modalidad simplificada permite enviar un informe de AWS Well-Architected Framework Review, generado con AWS Well-Architected Tool, en lugar de SOC 2 Type II. No equivale a una auditoría SOC 2 ni sustituye sus funciones comerciales o legales. Es una vía distinta de validación técnica aceptada por AWS para ese proceso concreto.

Según la guía actual de Partner Central, el informe WAFR debe tener menos de un año, identificar la solución y no presentar hallazgos de alto riesgo en los pilares de Seguridad, Excelencia Operativa y Fiabilidad. También exige identificar a la persona revisora. La revisión puede hacerla el propio partner utilizando la herramienta, aunque resolver los problemas detectados o contratar ayuda externa puede generar costes.

PRM: atribución de ingresos relacionados con AWS

Partner Revenue Measurement (PRM) sirve para atribuir determinados ingresos de AWS a las soluciones del partner, ayudando a medir su impacto dentro del ecosistema. No es una comisión de venta ni una certificación de seguridad. La nueva validación FTR exige que el producto relacionado esté habilitado para PRM; la información de medición puede tardar hasta siete días en aparecer tras activarse.

Requisitos de FTR que conviene conocer

La ruta simplificada documentada para software exige que la solución esté vinculada a un único producto de software de AWS Marketplace, que tenga una arquitectura alojada en AWS aprobada y que PRM esté habilitado. No basta con presentar un PDF WAFR si esos requisitos previos no están completos. AWS indica que el resultado de la validación puede obtenerse en minutos, con aprobación o acciones correctivas.

5. Cuánto cobra AWS Marketplace: comisiones publicadas

La guía oficial de comisiones distingue ofertas públicas, privadas, renovaciones y ventas a través de partners de canal. Estas son las tarifas estándar documentadas, sin perjuicio de contratos o condiciones particulares:

ModalidadComisión estándar
SaaS, oferta pública3 %
Software desplegable mediante AMI, contenedor o modelos de machine learning, oferta pública20 %
Oferta privada inferior a 1 millón USD3 %
Oferta privada desde 1 millón y menos de 10 millones USD2 %
Oferta privada desde 10 millones USD1,5 %
Renovaciones de ofertas privadas contempladas en la política1,5 %

Las ofertas privadas mediante partner de canal (CPPO) tienen un incremento de 0,5 puntos porcentuales sobre la comisión aplicable, según la documentación. Los servicios profesionales siguen una estructura diferenciada y conviene verificar su tarifa vigente antes de presupuestar una operación.

Ejemplo ilustrativo: si un SaaS se vende mediante oferta pública por 100 euros, el 3 % representa 3 euros y quedarían 97 euros antes de impuestos, costes de infraestructura, soporte, devoluciones u otras partidas. No es beneficio neto.

La modalidad de comercialización importa tanto como el precio. No debe aplicarse automáticamente la comisión del 3 % de SaaS a una máquina virtual vendida como AMI o a un contenedor.

6. ¿Puede venderse un SaaS que no está alojado íntegramente en AWS?

Sí, la guía de arquitecturas SaaS de AWS Marketplace permite desde mayo de 2025 publicar diferentes arquitecturas SaaS. Pero existe una diferencia muy importante entre poder listar el producto y recibir la identificación especial «deployed on AWS».

Para obtener esa identificación, AWS exige que tanto el plano de aplicación como el de control estén completamente en infraestructura AWS y que determinados servicios externos que traten datos de la aplicación también cumplan la política; existen excepciones descritas para CDN, DNS y proveedores corporativos de identidad. Por tanto, un SaaS externo puede ser elegible para la venta, pero no necesariamente para esa etiqueta.

Esto afecta también al camino de validación FTR: la modalidad actual incluye como requisito que el producto de Marketplace tenga una arquitectura alojada en AWS aprobada. No conviene confundir una autorización comercial para listar un SaaS externo con el cumplimiento automático de los requisitos para FTR.

7. Qué tipos de software pueden encajar

En términos generales, un SaaS con usuarios, suscripciones y prestación continua del servicio puede estudiar la publicación como SaaS. Un producto que se instala y ejecuta en la cuenta AWS del comprador puede encajar mejor en una modalidad AMI o contenedor, siempre que cumpla los requisitos técnicos de esa categoría.

Un instalador clásico de Windows o macOS no pasa a ser SaaS únicamente porque consulte una API alojada en AWS para validar licencias. Tampoco cualquier aplicación móvil se comercializa por Marketplace de la misma manera que por una tienda de aplicaciones. Hay que identificar qué servicio compra realmente el cliente, dónde se ejecuta y qué modalidad admite AWS.

La guía de elegibilidad de vendedores exige software de producción, un proceso de soporte definido y mantenimiento de seguridad, además de los requisitos de registro correspondientes. Una demostración experimental puede necesitar más trabajo antes de estar preparada para el catálogo.

8. Registro como vendedor: documentación y operaciones

Una empresa que quiere vender software de pago debe preparar su identidad legal, información fiscal, datos bancarios elegibles y los controles de verificación que le correspondan. AWS requiere procesos adicionales para determinadas jurisdicciones, como KYC para ventas en EMEA, y puede imponer requisitos específicos según el producto.

En el plano operativo, conviene documentar el soporte, las políticas de actualización, el modelo de precios, la atención a incidencias y la seguridad del producto. Para SaaS hay que diseñar correctamente el alta de clientes, los derechos de uso, la integración de contratación y, cuando proceda, medición y eventos de suscripción. Un producto comercialmente atractivo puede fallar en la publicación si no tiene preparado ese ciclo de vida.

9. Cómo preparar una FTR sin precipitar una auditoría externa

  1. Registrar la organización en AWS Partner Central y comprobar qué recorrido de partner corresponde a su actividad.
  2. Definir una solución concreta, su arquitectura y la modalidad de producto de AWS Marketplace.
  3. Comprobar si la arquitectura cumple las condiciones de producto alojado en AWS exigidas por el proceso actual de FTR.
  4. Vincular un único producto de software de Marketplace a la solución y habilitar PRM.
  5. Completar una revisión en AWS Well-Architected Tool sobre la carga principal, documentando los seis pilares y las acciones correctivas.
  6. Resolver los riesgos altos que impidan superar la validación, especialmente los de Seguridad, Excelencia Operativa y Fiabilidad.
  7. Presentar el informe WAFR o, si ya se dispone de uno válido, el SOC 2 Type II mediante la pestaña Validation de Partner Central.
  8. Conservar los resultados y revisar la fecha de vencimiento de la validación.

La FTR actual se presenta como válida durante dos años desde su aprobación. Consultar la ficha de la solución sigue siendo necesario, porque los programas de partner evolucionan y los requisitos de renovación pueden modificarse.

10. ¿Qué gana una empresa con todo esto?

Marketplace proporciona un escaparate y un mecanismo de contratación dentro del entorno de compras de AWS. APN puede facilitar formación, contactos y acceso condicionado a iniciativas comerciales. La FTR puede reforzar la presentación técnica de la solución y habilitar determinados programas, incluidos distintivos o oportunidades de venta conjunta cuando se cumplan sus requisitos.

Sin embargo, ninguno de estos elementos garantiza facturación. Para vender software empresarial siguen siendo necesarios un problema bien definido, un producto fiable, documentación, soporte, comercialización activa y una propuesta económica sostenible. La FTR valida aspectos técnicos; no sustituye una estrategia comercial.

11. Errores habituales

  • Suponer que AWS Partner Network, Marketplace y FTR son una única inscripción.
  • Creer que Amazon Bedrock es obligatorio para vender cualquier SaaS.
  • Contratar SOC 2 únicamente porque se desea empezar a vender en Marketplace.
  • Considerar que cualquier SaaS externo recibe automáticamente el distintivo «deployed on AWS».
  • Aplicar una comisión SaaS a un producto AMI o contenedor.
  • Confundir PRM con un programa que paga comisiones por cada cliente.
  • Presentar una WAFR sin comprobar primero los requisitos de vinculación a Marketplace y arquitectura AWS.
  • Olvidar los costes de operación, soporte, fiscalidad y adquisición de clientes.

12. Hoja de ruta para una pequeña empresa de software

La secuencia más sensata suele comenzar con el producto y sus clientes, no con una auditoría. Primero documenta el modelo de servicio, verifica que encaja en una modalidad de Marketplace y estima el margen después de comisiones. Después prepara el registro del vendedor, la integración de contratos y suscripciones, los requisitos de soporte y la seguridad básica.

Si una solución alojada en AWS puede beneficiarse de FTR, prepara su Well-Architected Review y la atribución PRM. Si los compradores empiezan a exigir controles auditados de forma independiente, evalúa SOC 2 como una decisión empresarial separada, con presupuesto y alcance definidos. Esta estrategia evita confundir un posible beneficio comercial con una obligación universal.

Conclusión

Ser partner, vender en AWS Marketplace y aprobar una FTR son objetivos relacionados pero distintos. Una empresa puede avanzar por etapas, sin necesitar Bedrock para cualquier tipo de producto ni contratar SOC 2 por defecto. El mejor camino consiste en elegir una modalidad comercial compatible, comprender las comisiones, cumplir los requisitos de vendedor y abordar las validaciones técnicas cuando aporten valor real.

Fuentes oficiales