MON +00 - Control de producción
Datos de ejecución
- Responsable: Joel López.
- Fecha y ventana observada: 03/09/2026, 09:53-10:00 CEST.
- Entorno:
https://signmethod.com/ en la sesión de Chrome abierta.
- Método: Playwright para navegación e inspección DOM; CDP únicamente para leer las respuestas de red generadas por las acciones Playwright.
- Alcance: comprobaciones de lectura. No se creó, modificó, envió, firmó ni canceló ningún acuerdo.
Resultado
| Área | Resultado | Evidencia observada |
|---|
| Home | OK | La portada se renderiza y muestra Frontend v2.0.8 · Backend/Lambda v2.0.7. |
| Login | PARCIAL | La sesión ya estaba autenticada como joel.lopez@softradis.com, rol Owner, empresa pepe. Se abrió el panel y las consultas privadas funcionaron, pero no se cerró la sesión ni se repitió la introducción de credenciales. |
| Rechazo no autorizado | PARCIAL | Una petición GET /prod/users?companyId=pepe sin cabecera de autorización no expuso datos; el navegador la presentó como net::ERR_FAILED por MissingAllowOriginHeader, sin permitir confirmar el código HTTP 401/403. |
| Listado | OK | El modal de acuerdos muestra 6 enviados, 3 pendientes, 0 borradores y 1 completado. La actualización ejecutó GET /prod/signature-requests?companyId=pepe y GET /prod/signature-requests/drafts?companyId=pepe, ambos con HTTP 200 tras preflight 204. |
| Firma pública | PARCIAL | La vista /comprobar-token se renderiza. El token ficticio no sensible CONTROL-00-INEXISTENTE-2026-09-03 produjo el 404 esperado y no mostró datos de acuerdos. La interfaz mantiene el mensaje en inglés Agreement not found; no se abrió ni firmó un acuerdo real. |
| API/Lambda | KO | GET /prod/health, empresas, usuario, acuerdos y borradores respondieron 200. Las métricas y logs Lambda de la ventana son satisfactorios: 23 invocaciones y 23 líneas REPORT, Errors=0, Throttles=0, sin fallos técnicos, duración máxima 568,71 ms, memoria máxima 122/256 MB y concurrencia máxima 3/10. Los dos ERROR registrados son HttpError 404 funcionales y controlados. La correlación demuestra que los tres OPTIONS /signatures llegaron a API Gateway, pero GET /signatures tuvo Count=0 y no invocó Lambda. Chrome bloqueó el GET porque el preflight solo permite Content-Type,Authorization y no admite cache-control; el frontend también envía pragma y x-owner-email. Además, no existe ninguna alarma CloudWatch para la función. Es la recurrencia del problema ya mencionado en INC-044 y una brecha de monitorización ya identificada en PRE-02. |
| Cognito | PARCIAL | La sesión vigente permitió cargar el perfil y los recursos protegidos. No se repitieron login, MFA ni métricas de Cognito. |
| DynamoDB | PARCIAL | Las lecturas funcionales de empresas, usuario, acuerdos y borradores devolvieron 200; no se consultaron métricas de errores o throttling de DynamoDB. |
| S3/SES | PARCIAL | Se identificaron signmethod-prod-documents-743737184059 como bucket privado del backend y signmethod-www-743737184059 como origen privado de CloudFront E39W5MD848G7V8. Ambos tienen bloqueo público y SSE-S3; documentos tiene versionado y el bucket web no. Ninguno tiene Request Metrics ni FilterId, server access logging ni CloudTrail Data Events; CloudFront tampoco tiene logging estándar o en tiempo real y no existen trails ni CloudTrail Lake. No hay datos retrospectivos del origen para +00; esta observabilidad S3 es KO. Tampoco existen alarmas S3 o CloudFront ni acciones SNS. CloudFront atendió 3 solicitudes con 4xx/5xx=0 %. Una comprobación posterior confirmó lecturas directas autorizadas S3 (HeadObject=200, Range GetObject=206) y portada CloudFront 200, sin modificar objetos. El objeto privado era JSON y no un PDF abierto desde Signmethod mediante URL firmada. Todavía falta esa validación aplicativa. SES continúa sin verificar. |
Tráfico relevante
GET /prod/health: 200.GET /prod/companies: 200.GET /prod/users?email=<redactado>: 200.GET /prod/signature-requests?companyId=pepe: 200.GET /prod/signature-requests/drafts?companyId=pepe: 200.GET /prod/public-agreements/CONTROL-00-INEXISTENTE-2026-09-03: 404 esperado.GET /prod/signatures: fallo de navegador tras preflight 204; HeaderDisallowedByPreflightResponse, parámetro cache-control.
Punto 2 - Métricas Lambda
- Función:
signmethod-prod-admin-api.
- Región:
eu-west-1.
- Ventana: 03/09/2026, 07:53-08:00 UTC.
- Periodo: 1 minuto; no fue necesario ampliar la ventana.
Invocations (Sum): 23 (07:54=2, 07:56=1, 07:57=6, 07:58=7, 07:59=7).Errors (Sum): 0.Throttles (Sum): 0.Duration: media 176,13 ms, p95 535,57 ms, p99 561,83 ms y máximo 568,71 ms.ConcurrentExecutions (Maximum): 3 sobre un límite disponible de cuenta de 10; margen de 7 ejecuciones.- Referencia de 24 horas: media
160,47 ms, p95 565,35 ms, p99 642,19 ms y máximo 801,37 ms. La media de la ventana fue aproximadamente un 9,8 % superior, pero los percentiles altos y el máximo fueron inferiores; no se aprecia una desviación anómala.
- Timeout configurado: 15 segundos. El máximo observado representa aproximadamente el
3,8 % del timeout.
- Memoria configurada: 256 MB; la memoria realmente utilizada se comprobará en los logs del punto 3.
- No hay concurrencia reservada específica.
DeadLetterErrors: sin puntos; no hay DLQ configurada, no aplicable.DestinationDeliveryFailures: sin puntos; no hay destinos asíncronos configurados, no aplicable.IteratorAge: no aplicable porque no existen event source mappings basados en streams.
Conclusión: las métricas Lambda del control +00 son satisfactorias. Este resultado no elimina el KO del apartado combinado API/Lambda, porque /prod/signatures sigue bloqueado por CORS antes de completar la solicitud y todavía faltan la correlación del fallo y las alarmas.
Punto 3 - Logs Lambda
- Grupo:
/aws/lambda/signmethod-prod-admin-api.
- Región:
eu-west-1.
- Ventana: 03/09/2026, 07:53-08:00 UTC.
- Eventos examinados: 74; no fue necesario ampliar la ventana.
Task timed out: 0.Runtime.ExitError: 0.Runtime exited: 0.Unhandled, uncaughtException y unhandledRejection: 0.Process exited: 0.- Errores de memoria (
out of memory, ENOMEM o heap): 0.
- Fallos o timeouts asociados a DynamoDB, S3, Cognito o SES: 0.
- Marcadores
ERROR: 2. Ambos son HttpError: Agreement not found, statusCode=404, a las 07:58:37 y 07:59:06 UTC. Corresponden a rechazos funcionales controlados de acuerdos inexistentes; no son errores de runtime, dependencias ni respuestas 5xx.
- Líneas
REPORT: 23, coincidentes con las 23 invocaciones del punto 2.
Duration: media 176,13 ms, p95 537,34 ms, p99 568,71 ms y máximo 568,71 ms.Billed Duration: media 249,04 ms y máximo 1.138 ms.- Memoria configurada: 256 MB.
Max Memory Used: 122 MB (47,7 %); margen aproximado de 134 MB.- Cold starts: 3 de 23 (
13,0 %).
Init Duration: media 555,11 ms y p95/máximo 568,92 ms.- El mayor
Billed Duration incluye inicialización y no representa tiempo íntegro del handler.
- Duración máxima frente al timeout de 15 segundos: aproximadamente
3,8 %.
CloudWatch Logs Insights calcula percentiles mediante pct; esto explica la pequeña diferencia entre sus valores y los percentiles interpolados de CloudWatch Metrics del punto 2.
Conclusión: los logs Lambda del control +00 cumplen el resultado esperado. No existen timeouts, errores de runtime, excepciones no controladas, presión de memoria ni fallos de dependencias. La tasa de cold starts queda registrada para la evaluación conjunta posterior.
Punto 4 - Correlación de /prod/signatures
- API:
signmethod-prod-admin-api.
- Stage:
prod.
- Región:
eu-west-1.
- Ventana principal: 03/09/2026, 07:53-08:00 UTC.
- Ventana ampliada comprobada: 07:48-08:05 UTC; el resultado no cambia.
- Periodo: 1 minuto.
Métricas detalladas de API Gateway
GET /signatures: Count=0 o sin datapoints; sin puntos para 4XXError, 5XXError, Latency o IntegrationLatency.OPTIONS /signatures: Count=3, una solicitud en cada minuto 07:57, 07:58 y 07:59 UTC.OPTIONS /signatures: 4XXError=0 y 5XXError=0.- Latencia de los tres preflight: 2, 4 y 2 ms; media de los puntos
2,67 ms.
- Los logs Lambda contienen las 23 ejecuciones de otras rutas, pero ninguna referencia a
/signatures.
Configuración observada
GET /signatures usa autorización COGNITO_USER_POOLS e integración AWS_PROXY con signmethod-prod-admin-api.OPTIONS /signatures no requiere autorización y usa integración MOCK; no invoca Lambda.- El preflight responde
204 con Access-Control-Allow-Origin: *.
Access-Control-Allow-Headers solo permite Content-Type,Authorization.Access-Control-Allow-Methods permite OPTIONS,GET,PUT,POST,DELETE,PATCH,HEAD.- Las respuestas de Gateway
UNAUTHORIZED, ACCESS_DENIED, EXPIRED_TOKEN, DEFAULT_4XX, DEFAULT_5XX y equivalentes no añaden cabeceras CORS.
- El stage no tiene access logging configurado.
- X-Ray está habilitado en el stage, pero no se recuperaron trazas para esta ventana.
Correlación con Chrome y conclusión
Chrome registró los preflight 204 y después Network.loadingFailed con net::ERR_FAILED, HeaderDisallowedByPreflightResponse y parámetro fallido cache-control. El frontend envía cache-control, pragma y x-owner-email, además de Content-Type y Authorization; API Gateway solo autoriza estas dos últimas.
La evidencia combinada permite concluir que los tres OPTIONS llegaron correctamente a la integración MOCK, pero Chrome rechazó la respuesta de preflight por su allowlist incompleta y no envió el GET. Por eso GET /signatures no tiene datapoints, no presenta IntegrationLatency y no invocó Lambda. La ausencia de CORS en las respuestas de error de autorización es una carencia adicional, pero no explica la petición observada porque el GET no llegó a enviarse.
Conclusión: Lambda no falla en /prod/signatures; la indisponibilidad observada pertenece a la configuración CORS de API Gateway y al contrato de cabeceras con el frontend. No se modificó producción.
Punto 5 - Alarmas Lambda
- Función:
signmethod-prod-admin-api.
- Región:
eu-west-1.
- Alcance: inventario regional completo de alarmas métricas y compuestas, mediante consulta de solo lectura.
- Alarmas métricas totales en la región: 6; todas pertenecen a otros servicios o cargas ajenas a Signmethod.
- Alarmas compuestas totales: 0.
- Alarmas con namespace
AWS/Lambda: 0.
- Alarmas con dimensión
FunctionName=signmethod-prod-admin-api: 0.
- Alarmas cuyo nombre o descripción referencia la función: 0.
- Alarmas compuestas cuya regla referencia la función: 0.
No existe cobertura automática para:
Errors.Throttles.Duration p95, p99 o máximo.ConcurrentExecutions.- Ausencia de invocaciones o anomalías de tráfico.
- Errores de API Gateway vinculados con la función.
Al no existir recursos de alarma, no puede asignarse un estado histórico OK, ALARM o INSUFFICIENT_DATA para la ventana +00, ni existe una acción SNS o suscripción asociada que revisar. Esto no contradice las métricas y logs satisfactorios: demuestra que CloudWatch no está configurado para avisar automáticamente si la situación cambia.
Conclusión: el punto 5 queda comprobado con resultado KO por ausencia completa de alarmas Lambda. No representa una incidencia activa durante la ventana, sino una brecha de monitorización. Crear las alarmas requeriría modificar infraestructura y quedó fuera de esta comprobación de solo lectura.
Punto 6 - Inventario de S3 y CloudFront
Bucket de documentos
- Nombre:
signmethod-prod-documents-743737184059.
- Región:
eu-west-1.
- Recurso
DocumentsBucket del stack SignmethodBackend-prod.
- Creado el 27/08/2026 a las 08:57 UTC.
- Almacenamiento privado utilizado por el backend; no es origen de la distribución web identificada.
- Website hosting no configurado.
- Bloqueo de acceso público activo en las cuatro opciones y política evaluada como no pública.
- Cifrado predeterminado SSE-S3 (
AES256).
- Versionado habilitado.
Bucket del frontend
- Nombre:
signmethod-www-743737184059.
- Región:
eu-west-1.
- Origen S3 de la distribución que sirve
signmethod.com.
- Creado el 29/04/2026 a las 19:52 UTC.
- Website hosting no configurado; se utiliza el endpoint REST privado.
- Bloqueo de acceso público activo en las cuatro opciones y política evaluada como no pública.
- Cifrado predeterminado SSE-S3 (
AES256).
- Versionado no habilitado; esta carencia ya está recogida en
PRE-02.
Distribución CloudFront
- ID:
E39W5MD848G7V8.
- Estado
Deployed y distribución habilitada.
- Alias:
signmethod.com y www.signmethod.com.
- Origen:
signmethod-www-743737184059.s3.eu-west-1.amazonaws.com.
- Origin Access Control presente; no usa acceso público ni OAI legado.
- Redirección de HTTP a HTTPS.
- HTTP/2 y HTTP/3; TLS mínimo
TLSv1.2_2021.
- Métodos permitidos:
GET y HEAD.
- Compresión habilitada.
- Documento raíz:
index.html.
- Fallback SPA: errores 403 y 404 transformados en
/index.html con HTTP 200 y TTL de error de 10 segundos.
La relación funcional queda identificada como navegador → CloudFront → bucket web y backend/Lambda → bucket privado de documentos. No existe una distribución CloudFront asociada al bucket de documentos dentro del alcance identificado. Otros buckets históricos o de otros entornos quedan fuera del control +00. La revisión fue exclusivamente de lectura y no modificó producción.
Conclusión: el inventario requerido queda completado. Todavía deben comprobarse la configuración de Request Metrics, sus datos durante la ventana, las alarmas y una lectura funcional censurada.
Punto 7 - S3 Request Metrics y FilterId
- Región:
eu-west-1.
- Recursos revisados:
signmethod-prod-documents-743737184059 y signmethod-www-743737184059.
- Consulta exclusivamente de lectura.
Bucket de documentos
- Configuraciones de métricas S3: 0.
- Request Metrics: no habilitadas.
FilterId: no existe o no aplica.- Series de solicitud visibles en CloudWatch: 0.
- Solo aparecen las métricas automáticas diarias
BucketSizeBytes (StorageType=StandardStorage) y NumberOfObjects (StorageType=AllStorageTypes).
Bucket del frontend
- Configuraciones de métricas S3: 0.
- Request Metrics: no habilitadas.
FilterId: no existe o no aplica.- Series de solicitud visibles en CloudWatch: 0.
- Solo aparecen las métricas automáticas diarias
BucketSizeBytes (StorageType=StandardStorage) y NumberOfObjects (StorageType=AllStorageTypes).
En ninguno de los buckets están disponibles AllRequests, GetRequests, PutRequests, DeleteRequests, HeadRequests, 4xxErrors, 5xxErrors, FirstByteLatency, TotalRequestLatency, BytesDownloaded o BytesUploaded.
ListBucketMetricsConfigurations confirma de forma autoritativa que no existen configuraciones, independientemente de que hubiera o no tráfico. La ausencia de series de solicitud en CloudWatch lo corrobora. Las métricas diarias de almacenamiento no tienen dimensión FilterId y no permiten analizar la ventana +00 con periodo de un minuto.
Conclusión: el punto 7 queda comprobado con resultado KO por ausencia de observabilidad S3 por solicitudes. No será posible recuperar retrospectivamente esas métricas para 07:53-08:00 UTC. Habilitarlas implicaría un cambio de configuración con coste y no se realizó durante esta revisión.
Punto 8 - Métricas del bucket de documentos
- Bucket:
signmethod-prod-documents-743737184059.
- Región:
eu-west-1.
- Ventana principal: 03/09/2026, 07:53-08:00 UTC.
- Periodo solicitado: 1 minuto.
- Ventana ampliada: 07:48-08:05 UTC; no aporta datos adicionales.
- Consulta exclusivamente de lectura.
No existen datapoints, ni en la ventana principal ni en la ampliada, para:
AllRequests, GetRequests, PutRequests, DeleteRequests, HeadRequests, PostRequests o ListRequests.4xxErrors o 5xxErrors.BytesDownloaded o BytesUploaded.FirstByteLatency o TotalRequestLatency.
La ausencia no significa tráfico o errores iguales a cero. Como se demostró en el punto 7, el bucket tiene cero configuraciones de Request Metrics y no dispone de FilterId; CloudWatch no recopiló esas series y no permite reconstruir el rendimiento de la ventana +00.
Métricas diarias disponibles
Última muestra anterior al control, correspondiente al 02/09/2026 a las 00:00 UTC:
BucketSizeBytes, Average, StandardStorage: 5.405.502 bytes, aproximadamente 5,16 MiB.NumberOfObjects, Average, AllStorageTypes: 53 objetos/versiones.
Serie reciente:
- Del 29/08 al 01/09: 4.959.054 bytes y 14 objetos/versiones.
- 02/09: 5.405.502 bytes y 53 objetos/versiones.
- Variación:
+446.448 bytes y +39 objetos/versiones.
El bucket tiene versionado habilitado, por lo que NumberOfObjects puede incluir versiones y marcadores de eliminación y no equivale necesariamente al número de claves actualmente visibles. Estas métricas son diarias y no describen la ventana de siete minutos.
Conclusión: el rendimiento del bucket de documentos durante +00 es NO EVALUABLE mediante CloudWatch. Solo se acredita que la última muestra diaria contenía aproximadamente 5,16 MiB y 53 objetos/versiones. No debe interpretarse como cero errores ni como una incidencia activa. La búsqueda de errores mediante CloudTrail Data Events o registros equivalentes se reserva para el punto 11.
Punto 9 - Frontend S3 y CloudFront
- Bucket de frontend:
signmethod-www-743737184059.
- Distribución:
E39W5MD848G7V8.
- Namespace CloudFront global consultado en
us-east-1.
- Ventana principal: 03/09/2026, 07:53-08:00 UTC.
- Periodo: 1 minuto.
- Ventana ampliada: 07:48-08:05 UTC; devuelve los mismos valores.
Métricas CloudFront
Requests (Sum): 3; una solicitud en cada minuto 07:57, 07:58 y 07:59 UTC.BytesDownloaded (Sum): 3.327 bytes (1.111, 1.109 y 1.107 bytes respectivamente).BytesUploaded (Sum): 0 bytes.4xxErrorRate (Average y Maximum): 0 % en los tres minutos.5xxErrorRate (Average y Maximum): 0 % en los tres minutos.TotalErrorRate (Average y Maximum): 0 % en los tres minutos.
Limitaciones del origen
- El bucket S3 no publica datapoints de
AllRequests, GetRequests, 4xxErrors, 5xxErrors, FirstByteLatency, TotalRequestLatency o BytesDownloaded porque Request Metrics no está habilitado.
OriginLatency y CacheHitRate no están disponibles porque la distribución no tiene monitorización adicional habilitada.- Standard logging de CloudFront está deshabilitado; no existen códigos de origen por petición.
- El fallback SPA transforma errores 403 y 404 del origen en
/index.html con respuesta HTTP 200. Por ello, el 0 % de errores al viewer no descarta una recuperación SPA interna.
- No se aportaron en este punto los últimos valores diarios de
BucketSizeBytes y NumberOfObjects del bucket web. Son datos informativos de capacidad y no cambian la evaluación de la ventana.
Conclusión: CloudFront atendió tres solicitudes sin devolver errores 4xx o 5xx al cliente y no existe evidencia de un fallo visible del frontend. Los errores individuales del origen no pueden aislarse sin Request Metrics S3, métricas adicionales o access logs. El punto queda PARCIAL: correcto desde la perspectiva del viewer, no concluyente para el origen. No se modificó producción.
Punto 10 - Lectura funcional sin modificaciones
- Prueba ejecutada el 03/09/2026 aproximadamente a las 08:50 UTC, fuera de la ventana histórica
+00.
- No se generaron ni mostraron URLs firmadas.
- Las claves, contenido, ETag y VersionId potencialmente sensibles permanecieron censurados.
Bucket de documentos
- Bucket:
signmethod-prod-documents-743737184059.
- Se localizó un objeto existente mediante una operación de listado de solo lectura.
HeadObject: HTTP 200.GetObject con rango bytes=0-0: HTTP 206 y un byte leído.Content-Range: bytes 0-0/424.- Tipo:
application/json; charset=utf-8.
- El bucket tiene versionado habilitado.
- ETag, tamaño y
LastModified permanecieron iguales antes y después.
- La operación demuestra lectura autorizada del bucket, pero no valida la apertura de un PDF desde Signmethod ni el uso de una URL firmada generada por la aplicación.
Bucket del frontend
- Bucket:
signmethod-www-743737184059.
- Objeto:
index.html.
HeadObject: HTTP 200.GetObject con rango bytes=0-0: HTTP 206 y un byte leído.Content-Range: bytes 0-0/684.- Tipo:
text/html.
- ETag, tamaño y
LastModified permanecieron iguales antes y después.
Frontend público mediante CloudFront
GET https://signmethod.com/: HTTP 200.- Tipo:
text/html.
- Tamaño recibido: 684 bytes.
X-Cache: RefreshHit from cloudfront y cabecera Via presente.- El cuerpo no se guardó ni se incluyó en la evidencia; solo se calculó un hash en memoria para comprobar la recepción completa.
No se ejecutaron operaciones PUT, POST, DELETE, COPY, multipart upload ni escrituras locales de contenido. Las únicas operaciones S3 fueron ListObjectsV2, HeadObject y GetObject de un byte. Los metadatos permanecieron sin cambios.
Conclusión: las lecturas directas autorizadas de ambos buckets y la entrega pública de CloudFront fueron satisfactorias y no modificaron archivos ni infraestructura. El punto queda PARCIAL respecto a la comprobación originalmente solicitada, porque el objeto privado era JSON y no se verificó un PDF QA mediante una URL firmada emitida por Signmethod.
Punto 11 - Registros S3, CloudFront y CloudTrail
S3 server access logging
signmethod-prod-documents-743737184059: deshabilitado.signmethod-www-743737184059: deshabilitado.- Ninguno tiene
LoggingEnabled, bucket de destino ni prefijo de logs.
Registros CloudFront
- Distribución:
E39W5MD848G7V8.
- Standard logging: deshabilitado; no hay bucket ni prefijo de destino.
- Real-time logging: no asociado al comportamiento por defecto ni a comportamientos adicionales.
CloudTrail y Data Events
- Regiones habilitadas comprobadas: 17.
- Trails encontrados: 0.
- CloudTrail Lake Event Data Stores encontrados: 0.
- No existe ningún selector de Data Events para
AWS::S3::Object, ni específico para los dos buckets ni global.
- CloudTrail Event History registra eventos de administración, pero no sustituye los Data Events necesarios para observar accesos a objetos S3.
Para la ventana 03/09/2026, 07:53-08:00 UTC, no existe una fuente histórica que permita recuperar operaciones GetObject, PutObject, HeadObject u otras, códigos de respuesta S3, errores de autorización, identidad solicitante, clave afectada, latencia del origen o correlación exacta entre CloudFront y S3. Las lecturas del punto 10 ocurrieron después de esa ventana y no permiten reconstruirla.
Conclusión: el punto 11 queda comprobado con resultado KO por ausencia de logs S3, logs CloudFront, trails y CloudTrail Data Events. Los posibles errores del origen no pueden reconstruirse retrospectivamente. Es una brecha de observabilidad y no evidencia de que ocurriera un error. Activar estas fuentes implicaría cambios de configuración y posible coste; no se modificó producción.
Punto 12 - Alarmas S3 y CloudFront
S3 en eu-west-1
- Alarmas métricas totales de la cuenta: 6; pertenecen a cargas ajenas a Signmethod.
- Alarmas compuestas: 0.
- Alarmas con namespace
AWS/S3: 0.
- Alarmas que referencian
signmethod-prod-documents-743737184059 o signmethod-www-743737184059: 0.
CloudFront en us-east-1
- Alarmas métricas totales: 0.
- Alarmas compuestas: 0.
- Alarmas con namespace
AWS/CloudFront: 0.
- Alarmas que referencian
E39W5MD848G7V8: 0.
No existe cobertura automática para errores 4xx/5xx de S3, latencias o volumen de solicitudes S3, tasas 4xx/5xx/TotalErrorRate de CloudFront, anomalías de tráfico, errores del origen o disponibilidad del frontend. Al no existir recursos de alarma, tampoco hay estados OK, ALARM o INSUFFICIENT_DATA, acciones SNS, notificaciones ni escalado que revisar.
Conclusión: el punto 12 queda comprobado con resultado KO por ausencia completa de alarmas S3 y CloudFront. Es una brecha de monitorización y no una alarma activa ni prueba de ausencia histórica de errores. Crear alarmas S3 por solicitud exigiría habilitar primero Request Metrics; no se modificó producción.
Punto 13 - Dictamen global Lambda
Dictamen: OPERATIVAMENTE OK, CON OBSERVACIONES.
Evidencias favorables durante +00:
- Invocaciones: 23.
Errors: 0.Throttles: 0.Duration Average: 176,13 ms.Duration p95/p99: 535,57/561,83 ms en CloudWatch Metrics.Duration Maximum: 568,71 ms, aproximadamente el 3,8 % del timeout de 15 segundos.- Concurrencia máxima: 3; margen disponible observado de 7 ejecuciones.
- Memoria máxima:
122/256 MB (47,7 %).
- Cold starts: 3 de 23 (
13,0 %); Init Duration máxima 568,92 ms.
- Timeouts, errores de runtime, excepciones no controladas y fallos DynamoDB, S3, Cognito o SES: 0.
- Los dos
HttpError registrados fueron respuestas 404 funcionales y controladas, no fallos Lambda.
Observaciones que impiden un OK sin reservas:
GET /prod/signatures no invocó Lambda: API Gateway registró tres OPTIONS y ningún GET para esa ruta.- Chrome bloqueó el GET por la allowlist incompleta del preflight CORS. Además, las Gateway Responses de autorización o error carecen de cabeceras CORS.
- No existe ninguna alarma para Lambda; una degradación futura no produciría aviso automático.
Conclusión: la función estuvo sana y con margen suficiente durante la ventana. No hay evidencia de que Lambda causara el fallo de /signatures. Su runtime queda OPERATIVAMENTE OK, CON OBSERVACIONES; la monitorización automática permanece KO. El apartado combinado API/Lambda continúa KO por el defecto de entrada CORS/API Gateway y la ausencia de alarmas. No se modificó producción.
Punto 14 - Dictamen global S3 y CloudFront
Dictamen: DISPONIBILIDAD ACTUAL OK; COMPORTAMIENTO HISTÓRICO +00 NO CONCLUYENTE.
Evidencias favorables:
- Ambos buckets usan cifrado SSE-S3 (
AES256) y bloqueo completo del acceso público.
- El bucket de documentos tiene versionado habilitado.
- CloudFront está desplegado y habilitado, fuerza HTTPS y accede al bucket web privado mediante Origin Access Control.
- Durante
+00, CloudFront registró 3 solicitudes y 3.327 bytes descargados.
4xxErrorRate, 5xxErrorRate y TotalErrorRate al viewer fueron 0 %.- Las lecturas actuales devolvieron
206 para el objeto privado de documentos y index.html, y 200 para https://signmethod.com/ mediante CloudFront.
- Los objetos comprobados permanecieron sin cambios.
Brechas que impiden certificar el origen durante +00:
- Request Metrics y
FilterId no existen en ninguno de los buckets.
- No hay métricas S3 por solicitud, errores o latencia.
- S3 server access logging está deshabilitado.
- CloudFront standard logging y real-time logging están deshabilitados.
- No existen trails ni CloudTrail Lake Event Data Stores en las 17 regiones habilitadas comprobadas.
- No existen alarmas S3 o CloudFront.
- El bucket del frontend no tiene versionado habilitado.
- El fallback SPA transforma errores 403 y 404 del origen en
/index.html con respuesta 200, por lo que un 0 % de errores al viewer no demuestra por sí solo que el origen no produjera errores internos.
- La lectura privada actual utilizó un objeto JSON mediante credenciales autorizadas; no se abrió un PDF QA mediante una URL firmada emitida por Signmethod.
Conclusión: S3 y CloudFront funcionan en las comprobaciones actuales y CloudFront no mostró errores visibles durante +00. Sin embargo, la tasa histórica de error y la latencia del origen S3 no pueden certificarse retrospectivamente. El estado correcto es NO CONCLUYENTE para el origen durante +00, no cero errores S3. La validación de infraestructura actual queda OK, mientras que la observabilidad permanece KO y la validación aplicativa del PDF sigue PARCIAL. No se realizaron cambios.
Punto 15 - Paquete consolidado de evidencias
El usuario declara completado un paquete ZIP con el siguiente contenido:
REPORT.md: informe ejecutivo y resultado de los 15 puntos.MANIFEST-SHA256.txt: hash individual de cada artefacto.- 15 imágenes PNG, una por cada punto del plan.
- Total declarado dentro del ZIP: 17 archivos.
- Tamaño declarado: 1.443.014 bytes, aproximadamente 1,38 MiB.
- SHA-256 declarado del ZIP:
8bdeba69c7cea8d738f49023b04e3570bbc20834f7dd076514c9a57a334b5ed0.
- Prueba de integridad interna declarada: correcta, sin miembros dañados.
Verificación en el repositorio
El archivo observation-plus00-evidence-2026-09-03.zip está presente en el repositorio y se validó localmente antes de versionarlo:
- Tamaño comprobado: 1.443.014 bytes.
- SHA-256 comprobado:
8bdeba69c7cea8d738f49023b04e3570bbc20834f7dd076514c9a57a334b5ed0.
- Miembros comprobados: 17 (
REPORT.md, MANIFEST-SHA256.txt y 15 PNG).
- Lectura completa de todos los miembros: correcta.
- Entradas verificadas contra
MANIFEST-SHA256.txt: 16 de 16 correctas; el manifiesto no se incluye a sí mismo.
Conclusión: los 15 puntos han sido informados como completados y el paquete material de evidencias queda disponible, íntegro y verificado en el repositorio.
Limitaciones y seguimiento
El control no permite declarar estable la monitorización completa de las primeras dos horas. Ya se han validado las métricas y los logs Lambda, se ha correlacionado el fallo /prod/signatures y se ha confirmado el KO por ausencia de alarmas Lambda. En S3 se ha demostrado que no existen Request Metrics ni fuentes alternativas de registro, y el punto 12 confirmó también la ausencia de alarmas S3 y CloudFront. Queda pendiente la apertura de un PDF QA mediante una URL firmada emitida por Signmethod. CloudFront mostró 4xx/5xx=0 % al viewer, pero el origen no es reconstruible. También quedan pendientes otras métricas y alarmas de API Gateway, Cognito, DynamoDB y SES, además de entregas y rebotes de correo. El ZIP consolidado del punto 15 sí está disponible en el repositorio y su integridad fue verificada.
No se abre una incidencia nueva por /prod/signatures, ya que el fallo ya está recogido en INC-044; esta ejecución confirma que continúa reproducible.