Facturación para Amazon Redshift Serverless

Facturación de la capacidad de computación

Puede adquirir capacidad para Amazon Redshift sin servidor de dos maneras:

• Puede adquirir capacidad bajo demanda: cuando elige la capacidad informática bajo demanda, paga por los recursos sobre la marcha. Esta es la mejor opción si acaba de empezar a utilizar Amazon Redshift sin servidor o si aún no conoce bien los patrones de uso constantes. La opción bajo demanda ofrece la mayor flexibilidad. Para obtener más información, consulte Facturación de la capacidad informática bajo demanda.

• Puede comprar reservas: una reserva ofrece un descuento cuando compra una cantidad predeterminada de recursos informáticos durante un periodo de tiempo específico, por ejemplo, durante un año. Es una buena idea cuando sabe que va a utilizar una cantidad de capacidad de forma constante. Resulta útil para ahorrar dinero cuando puede pronosticar algunas de sus necesidades de capacidad. Para obtener más información, consulte Facturación de las reservas sin servidor.

Puede utilizar las reservas y los recursos bajo demanda de forma conjunta. No es necesario que utilice uno u otro.

Para obtener información acerca de los precios detallada, consulte Precios de Amazon Redshift.

Facturación del almacenamiento

La capacidad de almacenamiento principal se factura como Redshift Managed Storage (RMS). El almacenamiento se factura por GB al mes. La facturación del almacenamiento es independiente de la facturación de la capacidad recursos de computación. El almacenamiento que se utiliza para las instantáneas de los usuarios se factura con las tarifas estándar de facturación de las copias de seguridad, en función del nivel de uso.

Los costos de transferencia de datos y de machine learning (ML) se aplican por separado, al igual que los clústeres aprovisionados. La replicación de instantáneas y el uso compartido de datos entre regiones de AWS se facturan según las tarifas de transferencia indicadas en la página de precios. Para obtener más información, consulte Precios de Amazon Redshift.

Visualización del uso de facturación con CloudWatch

La métrica SnapshotStorage, que realiza un seguimiento del uso del almacenamiento de instantáneas, se genera y envía a CloudWatch. Para obtener más información sobre CloudWatch, consulte ¿Qué es Amazon CloudWatch?

Uso de la prueba gratuita de Amazon Redshift sin servidor

Amazon Redshift Serverless ofrece una prueba gratuita. Si participa en la prueba gratuita, puede ver el saldo de crédito de prueba gratuita en la consola de Redshift y comprobar el uso de la prueba gratuita en la vista del sistema SYS_SERVERLESS_USAGE. Tenga en cuenta que los detalles de facturación para el uso de prueba gratuita no aparecen en la consola de facturación. Solo puede ver el uso en la consola de facturación una vez finalizada la prueba gratuita. Para obtener más información sobre la prueba gratuita de Amazon Redshift sin servidor, consulte Prueba gratuita de Amazon Redshift sin servidor.

Notas sobre la facturación de uso

• Registro del uso: una consulta o transacción solo se mide y registra después de que la transacción se complete, se revierta o se detenga. Por ejemplo, si una transacción se ejecuta durante dos días, el uso de RPU se registra después de que se complete. Puede supervisar el uso en curso en tiempo real si consulta sys_serverless_usage. El registro de las transacciones puede reflejarse como una variación del uso de RPU y afectar a los costos para horas específicas y para el uso diario.

• Escritura de transacciones explícitas: es importante, como práctica recomendada, finalizar las transacciones. Si no finaliza ni revierte una transacción abierta, Amazon Redshift Serverless sigue utilizando las RPU. Por ejemplo, si escribe un BEGIN TRAN explícito, es importante que estén las instrucciones COMMIT y ROLLBACK correspondientes.

• Consultas canceladas: si ejecuta una consulta y la cancela antes de que termine, se le sigue facturando el tiempo que se ha ejecutado la consulta.

• Escalado: la instancia de Amazon Redshift Serverless puede iniciar el escalado para manejar periodos de mayor carga, con el fin de mantener un rendimiento constante. La facturación de Amazon Redshift Serverless incluye tanto la capacidad base de computación como la capacidad escalada a la misma tasa de RPU.

• Reducir verticalmente: Amazon Redshift Serverless escala verticalmente desde su capacidad de RPU base para gestionar periodos de mayor carga. En algunos casos, la capacidad de RPU puede permanecer en una configuración superior durante un periodo después de que la carga de la consulta disminuya. Le recomendamos que establezca un máximo de horas de RPU en la consola para protegerse de costes inesperados.

• Tablas del sistema: cuando se consulta una tabla del sistema, se factura el tiempo de consulta.

• Redshift Spectrum: cuando se tiene Amazon Redshift Serverless y se realizan consultas, no se cobra por separado por las consultas del lago de datos. Para las consultas de datos almacenados en Amazon S3, el cargo es el mismo, por tiempo de transacción, que en las consultas de datos locales.

• Consultas federadas: las consultas federadas se cobran en términos de RPU utilizadas durante un intervalo de tiempo específico, de la misma manera que las consultas en el almacenamiento de datos o el lago de datos.

• Almacenamiento: el almacenamiento se factura por separado, por GB al mes.

• Cargo mínimo: el cargo mínimo es de 60 segundos de uso de recursos, contabilizado por segundos.

• Facturación de instantáneas: la facturación de instantáneas no cambia. Se cobra según el almacenamiento, facturado a una tasa de GB al mes. Puede restaurar su almacenamiento de datos a puntos específicos de las últimas 24 horas con una precisión de 30 minutos, de forma gratuita. Para obtener más información, consulte Precios de Amazon Redshift.

Prácticas recomendadas de Amazon Redshift Serverless para mantener la previsibilidad de la facturación

A continuación, se muestran las prácticas recomendadas y las configuraciones integradas que lo ayudarán a mantener la coherencia de la facturación.

• Asegúrese de finalizar cada transacción. Cuando usa BEGIN para iniciar una transacción, también es importante END.

• Use el control de errores de las prácticas recomendadas para responder correctamente a los errores y finalizar cada transacción. Minimizar las transacciones abiertas ayuda a evitar el uso innecesario de RPU.

• Use SESSION TIMEOUT para finalizar las transacciones abiertas y las sesiones inactivas. Hace que se agote el tiempo de espera de cualquier sesión inactiva durante más de 3600 segundos (1 hora). Hace que se agote el tiempo de espera de cualquier transacción que se mantenga abierta e inactiva durante más de 21 600 segundos (6 horas). Esta configuración de tiempo de espera se puede cambiar explícitamente para un usuario específico, por ejemplo, cuando desea mantener abierta una sesión para una consulta de larga duración. En el tema CREATE USER (CREAR USUARIO), se muestra cómo ajustar SESSION TIMEOUT para un usuario.

  • En la mayoría de los casos, le recomendamos que no amplíe el valor SESSION TIMEOUT, a menos que tenga un caso de uso que lo requiera específicamente. Si la sesión permanece inactiva, con una transacción abierta, puede dar lugar a un caso en que se utilicen RPU hasta que se cierre la sesión. Esto dará lugar a costos innecesarios.

  • Amazon Redshift sin servidor tiene un tiempo máximo de 86 399 segundos (24 horas) para una consulta en ejecución. El periodo máximo de inactividad de una transacción abierta es de seis horas antes de que Amazon Redshift sin servidor finalice la sesión asociada a la transacción. Para obtener más información, consulte Cuotas de objetos de Amazon Redshift Serverless.

Facturación de Amazon Redshift sin servidor con agrupación de conexiones

Amazon Redshift sin servidor trata todas las consultas entrantes como actividad de usuario facturable, incluidas las consultas sencillas de comprobación de estado enviadas por grupos de conexiones. Este comportamiento se aplica independientemente de si la consulta se origina en una aplicación, un controlador JDBC/ODBC o un marco de agrupación de conexiones. Cada consulta de comprobación de estado desencadena el uso de la computación y se incurre en cargos independientemente del propósito o el origen de la consulta. Como resultado, mantener los grupos de conexiones abiertos puede generar costos incluso cuando no se estén ejecutando cargas de trabajo reales de los usuarios.

La agrupación de conexiones mantiene un conjunto de conexiones persistentes entre las aplicaciones y el punto de conexión de Amazon Redshift sin servidor. Para garantizar que estas conexiones se mantengan en buen estado y disponibles, los mecanismos de agrupación suelen enviar consultas ligeras o vacías (por ejemplo, SELECT 1) a intervalos regulares. Estas consultas automatizadas verifican el estado de la conexión.

Cuando utilice la agrupación de conexiones, tenga en cuenta estas prácticas recomendadas para minimizar los cargos imprevistos:

• Ajuste la frecuencia de las comprobaciones de estado revisando y optimizando la frecuencia de las consultas de comprobación de estado o de keep-alive en la configuración de agrupación de conexiones.

• Optimice la configuración del sistema inactivo configurando la agrupación de conexiones para minimizar la pérdida innecesaria de conexiones o la actividad de consultas en segundo plano durante los tiempos de inactividad del sistema.

• Implemente una agrupación en el nivel de aplicaciones o una mejor gestión del ciclo de vida de las conexiones si así puede reducir la sobrecarga.

• Desactive las consultas de latido o validación si la configuración de agrupación de conexiones lo permite. Compruebe los parámetros específicos de la cadena de conexión o los archivos de configuración para ajustar esta configuración.

• Afine la configuración de keepalive de TCP: si no puede desactivar los mecanismos de latidos internos del controlador, ajuste la configuración keepalive del protocolo de control de transmisión (TCP) en el nivel del sistema operativo o de la aplicación para solucionar los problemas de tiempo de espera de la conexión. Consulte el sistema operativo, el controlador JDBC u ODBC, o la documentación del grupo de conexiones para obtener más información.

• Optimice la agrupación de conexiones de bases de datos: configure el grupo de conexiones (HikariCP, grupo de conexiones de base de datos de Apache) para administrar las conexiones y minimizar la sobrecarga de conexión. Concéntrese en parámetros como el número máximo de conexiones, el tiempo de espera de inactividad y las consultas de validación (si es necesario). Esta optimización ayuda a alinear el uso de la computación de Amazon Redshift sin servidor con la demanda real de carga de trabajo, lo que podría reducir los costos.

Optimización de costos para Amazon Redshift sin servidor sin ETL

Para optimizar los costos al ejecutar integraciones sin ETL en Amazon Redshift sin servidor, puede ajustar el tamaño de los entornos y modificar la configuración de actualización según las necesidades de la carga de trabajo. Considere la posibilidad de realizar los siguientes ajustes:

• Utilice la capacidad base de RPU inferior de 8 RPU, cuando esté disponible para las cargas de trabajo.

• Configure el REFRESH_INTERVAL de la instancia de Redshift de destino para equilibrar actualización con costo. Los intervalos más cortos garantizan actualizaciones casi en tiempo real, pero aumentan los costos de procesamiento. Los intervalos más largos (5 minutos o más) reducen los cargos de las cargas de trabajo en las que la actualización inmediata no es fundamental, como la elaboración de informes o el análisis histórico. Para editar REFRESH_INTERVAL de destino de Redshift, consulte la cláusula de intervalo de actualización en la descripción de ALTER DATABASE.

• Maximice el uso del entorno de Amazon Redshift sin servidor ejecutando simultáneamente cargas de trabajo de análisis mientras se ingieren datos sin ETL. Esto garantiza que la capacidad de procesamiento sirva activamente para múltiples propósitos empresariales.

• Para minimizar el cómputo inactivo y optimizar el costo total de propiedad, revise las integraciones sin ETL actuales y aumente el REFRESH_INTERVAL siempre que la actualización de los datos no sea fundamental para la empresa, al tiempo que alinea la capacidad de la RPU con la demanda de la carga de trabajo.