Cuotas, límites de servicio y pedidos de aumento
Toda nube tiene topes por cuenta y por región, y la mayoría se descubre el día del lanzamiento. Saber cuáles son duros, cuáles se piden con anticipación y cuáles no se pueden mover es parte del diseño, no del soporte.
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
La nube se vende como capacidad infinita y no lo es. Cada cuenta tiene topes: cuántas instancias de cada tipo, cuántas direcciones públicas, cuántas funciones concurrentes, cuántas escrituras por segundo.
La mayoría de esos números nunca molesta. El problema es el día en que sí: el lanzamiento que esperaba tráfico, la conmutación a la región secundaria, el trabajo por lotes de fin de mes. Es decir, siempre el peor día.
Tres tipos de tope, y sólo uno se negocia rápido
| Tipo | Qué es | Se puede subir | Ejemplo |
|---|---|---|---|
| Cuota ajustable | Un valor por cuenta y región, con tope por defecto conservador | Sí, pidiéndolo | Cantidad de núcleos por familia de instancias |
| Límite duro del servicio | Una restricción del diseño del servicio | No | Tamaño máximo de un objeto, duración máxima de una función |
| Límite de tasa | Cuántas llamadas por segundo acepta la API | A veces, parcialmente | Llamadas a la API de control por segundo |
La distinción práctica es simple: la cuota ajustable es un trámite con demora y el límite duro es un requisito de diseño. Descubrir un límite duro tarde obliga a rediseñar; descubrir una cuota tarde sólo obliga a esperar, pero esa espera puede ser de horas o de días.
Límites de tasa: el error que parece un problema propio
Las APIs de los proveedores limitan la cantidad de llamadas por segundo, y cuando se supera responden con un error de sobrecarga. La consecuencia inmediata es un error que no está en el código de nadie.
Qué hacer cuando aparece
- Reintentar con espera creciente y aleatoria. Los SDK oficiales lo hacen por defecto; los scripts propios, casi nunca.
- No llamar a la API de control en el camino de cada request. Consultar la configuración o listar recursos en cada request es la causa más común de chocar contra el límite.
- Cachear lo que no cambia: la lista de zonas, los metadatos, los secretos.
- Repartir el trabajo en lotes en vez de disparar mil llamadas a la vez desde un bucle.
Antes de seguir, predecí
Cómo se pide un aumento y cuánto tarda
El procedimiento que funciona
- Con anticipación: los aumentos grandes pueden tardar días y a veces requieren que un humano los apruebe.
- Con contexto: la cantidad que hace falta, para cuándo, y por qué. Un pedido justificado se aprueba más rápido y más grande.
- Región por región, incluida la de recuperación.
- Con margen: pedir exactamente lo que se necesita garantiza otro pedido en tres meses.
- Verificando después, porque un aumento aprobado no siempre se aplica a toda la familia de recursos que uno supone.
Vigilarlas como cualquier otra métrica
Las cuotas son una forma de saturación, así que van en el monitoreo junto con el resto.
Lo mínimo
- Alerta al llegar a un porcentaje del tope, no al tope. Los tres proveedores publican el uso de las cuotas principales como métrica.
- Revisión periódica automática de las cuotas de todas las cuentas y regiones contra lo que necesita el sistema.
- La cuota como parte de la definición de infraestructura: dejar escrito qué valores necesita cada entorno, para que el ejercicio de recuperación lo verifique.
- Los límites duros, documentados en las decisiones de diseño, para que nadie proponga una arquitectura que los ignora.
Más a fondo · nivel seniorLos límites que definen la arquitectura
Algunos topes no son un trámite: son la restricción alrededor de la cual se diseña. Conviene conocerlos por categoría, más que de memoria.
- Almacenamiento de objetos: el tamaño máximo de un objeto y el de cada parte en una carga multiparte. Definen cómo se suben los archivos grandes.
- Funciones: duración máxima, tamaño del paquete, memoria y concurrencia. Definen qué trabajo puede vivir ahí y qué necesita un contenedor.
- Bases: conexiones simultáneas según el tamaño de la instancia, y tamaño máximo del almacenamiento. Definen si hace falta un pooler y cuándo hay que particionar.
- Redes: reglas por grupo de seguridad, rutas por tabla, interfaces por instancia. Definen cuántos servicios entran por red antes de tener que partirla.
- Colas y flujos: tamaño del mensaje y capacidad por partición. Definen si el contenido grande viaja en el mensaje o en el almacenamiento con una referencia.
La regla general: cuando una arquitectura necesita que uno de estos límites sea más alto, casi siempre hay un patrón conocido que lo evita —cargar por partes, partir el trabajo, guardar el contenido aparte— y ese patrón es mejor que el pedido de aumento.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica