Administración de operaciones

Por qué existen las cuotas de servicio de AWS - Diseño multitenant que protege la infraestructura compartida

Explicamos que las cuotas de servicio de AWS (antes límites de servicio) no son simples restricciones sino un diseño para proteger a otros clientes en un entorno multitenant, desde el problema del vecino ruidoso, la diferencia entre límites soft y hard, y el trasfondo de las solicitudes de aumento.

約 5 分で読めます

La esencia de las cuotas de servicio - Un mecanismo para proteger a otros clientes

Las cuotas de servicio de AWS (antes llamadas límites de servicio) son los límites superiores de recursos que cada cuenta puede utilizar. Se establecen cuotas para prácticamente todos los recursos: número de instancias EC2 que se pueden lanzar, ejecuciones simultáneas de Lambda, número de buckets S3, número de VPCs, etc. Estas cuotas no existen para incomodar a los usuarios. La infraestructura de AWS es multitenant. Los servidores físicos, redes y almacenamiento se comparten entre múltiples clientes. Si un cliente consume recursos sin límite, otros clientes en la misma infraestructura física se ven afectados. Esto se conoce como el problema del "vecino ruidoso" (noisy neighbor). Las cuotas de servicio son un mecanismo para prevenir que un solo cliente monopolice los recursos compartidos.

Límites soft y límites hard

Hay 2 tipos de cuotas. Los límites soft (cuotas ajustables) pueden aumentarse mediante solicitud en la consola de Service Quotas o al soporte de AWS. El número de vCPUs de instancias bajo demanda de EC2 (por defecto: varía por familia de instancias por región), ejecuciones simultáneas de Lambda (por defecto: 1,000), número de buckets S3 (por defecto: 100) son ejemplos de límites soft. Los límites hard (cuotas no ajustables) no pueden aumentarse independientemente de la solicitud. El tamaño máximo de objeto de S3 (5 TB), el tamaño máximo de ítem de DynamoDB (400 KB), el tamaño máximo de política IAM (6,144 caracteres) son ejemplos de límites hard. Estos están determinados por restricciones de diseño del servicio y no pueden cambiarse.

El trasfondo de las solicitudes de aumento de cuota

¿Qué sucede cuando se envía una solicitud de aumento desde la consola de Service Quotas? Algunas cuotas se aprueban automáticamente. Aumentos como el número de buckets S3 (100 a 1,000) se aprueban automáticamente en minutos después de la solicitud. Estas cuotas están automatizadas porque el aumento tiene poco impacto en otros clientes. Por otro lado, aumentos significativos de cuota de vCPU de EC2 (por ejemplo, 1,000 a 10,000) son revisados por el equipo de AWS. Esto se debe a que se necesita verificar si hay capacidad física suficiente en la región y AZ solicitadas. Si la capacidad es insuficiente, puede sugerirse una región o tipo de instancia alternativo, o puede tomar tiempo hasta que se agregue capacidad.

Por qué las cuotas por defecto son bajas

Las cuotas por defecto de cuentas nuevas se establecen intencionalmente bajas. Las vCPU bajo demanda de EC2 son de 5 a 32 vCPU por familia de instancias para cuentas nuevas. Estos valores por defecto bajos tienen 3 razones. Primera, prevención de uso fraudulento. El uso fraudulento donde cuentas creadas con tarjetas de crédito robadas lanzan grandes cantidades de instancias EC2 para minar criptomonedas es un problema real para AWS. Las cuotas bajas por defecto limitan el daño de tales abusos. Segunda, protección contra errores. Los nuevos usuarios pueden lanzar accidentalmente grandes cantidades de instancias por errores de script, generando facturas enormes. Las cuotas bajas funcionan como red de seguridad. Tercera, planificación de capacidad. Si todas las cuentas nuevas pudieran usar recursos ilimitados desde el principio, la planificación de capacidad de AWS se volvería extremadamente difícil.

Monitoreo y automatización de cuotas

Service Quotas está integrado con CloudWatch, permitiendo obtener la tasa de uso de cuotas como métricas. Por ejemplo, se puede configurar una alarma de CloudWatch que se active cuando la tasa de uso de cuota de vCPU de EC2 supere el 80%, notificando vía SNS. Es importante monitorear proactivamente y solicitar aumentos con anticipación, ya que es demasiado tarde una vez que se alcanza la cuota. Trusted Advisor también verifica cuotas y alerta cuando el uso se acerca al límite. Para la automatización, se puede usar la API de Service Quotas para solicitar aumentos programáticamente, y AWS Config puede detectar recursos que se acercan a las cuotas. Para profundizar en la gestión de cuotas y operaciones de AWS, los libros especializados (Amazon) son una buena referencia.

Servicios relacionados

AWS Trusted AdvisorServicio que proporciona recomendaciones en tiempo real para optimizar su entorno de AWS

Artículos relacionados

El mecanismo de throttling de las API de AWS - El algoritmo Token Bucket y la verdad detrás del error 429Explicamos cómo el rate limiting de las API de AWS se implementa con el algoritmo Token Bucket, el concepto de burst capacity, las diferencias en los límites según el servicio, y las medidas prácticas para evitar el throttling.Diseño de dominios de fallo en AWS - El mecanismo de disponibilidad protegido por la estructura de 3 capas AZ, región y particiónExplicamos por qué la infraestructura de AWS está diseñada en 3 capas: AZ (aislamiento de fallos), región (separación geográfica) y partición (separación política), y hasta dónde se propagan los fallos en cada capa con ejemplos concretos.El interior del cálculo de tarifas de AWS - Cómo se miden la facturación por segundo, por 100ms y por solicitudExplicamos cómo se miden, agregan y facturan las diversas granularidades de cobro de AWS, como la facturación por segundo de EC2, por 1ms de Lambda y por solicitud de S3, desde el mecanismo del sistema de metering.

Más sobre este tema

El mecanismo de sincronización horaria interna de AWS - Amazon Time Sync Service y el diseño de smearing de segundos intercalaresExplicamos el mecanismo de Amazon Time Sync Service operado de forma independiente por AWS, la fuente de tiempo de alta precisión con GPS y relojes atómicos, la decisión de diseño de absorber los segundos intercalares mediante smearing y la importancia de la sincronización horaria en sistemas distribuidos.Centralización de registros de auditoría SaaS con AWS AppFabric - Estandarización OCSF e integración con Security LakeExplicamos la recopilación de registros de auditoría de aplicaciones SaaS con AppFabric, la estandarización al formato OCSF y la construcción de pipelines de análisis.Implementación de Feature Flags con AWS AppConfig - Despliegue seguro de configuración y rollbackDespliega cambios de configuración de forma independiente al código mediante estrategias Linear y Exponential. Garantiza la seguridad con rollback automático activado por alarmas de CloudWatch.Revisión de arquitectura - Evaluación sistemática de cargas de trabajo con AWS Well-Architected ToolExplica la revisión de arquitectura de cargas de trabajo usando AWS Well-Architected Tool. Presenta la evaluación basada en 6 pilares, la elaboración de planes de mejora y el uso de lentes personalizados.Diseño y operación de logs de auditoría - Registro completo de actividad API con CloudTrailExplica las técnicas de diseño de logs de auditoría con AWS CloudTrail, el registro de actividad API, el almacenamiento a largo plazo en S3 y la respuesta de cumplimiento mediante integración con Config.Lecciones de sistemas distribuidos de los informes de incidentes (COE) de AWS - Principios de diseño que cambiaron las grandes interrupciones del pasadoA partir de los Correction of Errors (COE) e informes de incidentes publicados por AWS, explicamos las causas raíz de grandes incidentes pasados como la interrupción de S3, la interrupción de DNS en us-east-1 y la interrupción de Kinesis, y cómo cambiaron los principios de diseño de AWS.El diseño de tags determina las operaciones - Curiosidades y reglas de nomenclatura prácticas de la estrategia de tags de recursos AWSExplicamos por qué los tags de recursos AWS no son simples etiquetas sino la base de la asignación de costos, control de acceso y automatización, las reglas de nomenclatura de claves de tags, cómo usar el límite de 50 tags y la gobernanza mediante políticas de tags.Gestion centralizada de backups con AWS Backup - Planes de backup y proteccion cross-regionGestione backups de EC2, RDS, DynamoDB y mas bajo una politica unificada. Cubre la proteccion WORM con Vault Lock y la automatizacion de pruebas de restauracion.

Artículos y servicios similares

AWS Service QuotasServicio para gestionar centralmente los límites de uso de servicios AWS, enviar solicitudes de aumento de cuotas y configurar alertasPor qué el límite de Lambda es 15 minutos - La racionalidad oculta en las restricciones de diseño serverlessExplicamos por qué el tiempo máximo de ejecución de 15 minutos de Lambda, el límite de memoria de 10 GB, el payload de 6 MB y otras restricciones serverless están configuradas en esos valores, desde la perspectiva de la filosofía de diseño de Firecracker y la operación multi-tenant.El mecanismo de throttling de las API de AWS - El algoritmo Token Bucket y la verdad detrás del error 429Explicamos cómo el rate limiting de las API de AWS se implementa con el algoritmo Token Bucket, el concepto de burst capacity, las diferencias en los límites según el servicio, y las medidas prácticas para evitar el throttling.Diagnóstico de optimización del entorno AWS - Verificación de mejores prácticas con Trusted AdvisorExplicamos el diagnóstico automático del entorno con AWS Trusted Advisor. Presentamos los elementos de verificación y métodos de uso en las 5 categorías: optimización de costos, seguridad, tolerancia a fallos, rendimiento y límites de servicio.