Puede sonar como una pregunta extraña, pero tengan paciencia conmigo aquí.
Necesito construir un pequeño proyecto web. En aras de hacerlo gratuito, iba a alojar la parte frontal en S3 como un sitio estático y hacer que invocara funciones del lado del servidor haciendo llamadas AJAX a una API REST alojada en una función lambda. He hecho esto antes en una aplicación web para mí, pero recuerdo que causó complicaciones cuando se realizaron solicitudes de origen cruzado y terminé recurriendo al uso de JSONP. ¿Hay algún problema con esta configuración? Escuché que JSONP puede ser un problema de seguridad y este nuevo sitio está diseñado para uso público.
Mi configuración alternativa sería crear un servidor en Lightsail que aloje el sitio y el backend. Obviamente, esta es probablemente la forma más correcta de hacer las cosas, pero cuesta un poco más de dinero.
¿Cuál de estos métodos es probablemente la mejor opción?
Pregunta adicional: ¿Es posible configurar CORS para no tener que usar JSONP para solicitudes de origen cruzado? No estoy familiarizado con CORS.
¿Cuál de estos métodos es probablemente la mejor opción?
Voy a fingir que no preguntaste eso, ya que no hay una respuesta "correcta", es subjetiva y hay muchos factores, algunos de los cuales se basan en opiniones.
Pero ambas soluciones son viables.
API Gateway, que es lo que usaría como front-end para exponer sus funciones de Lambda a Internet, es compatible con CORS, por lo que esto no debería ser una preocupación para usted.
Otra opción es usar S3 y Lambda (con API Gateway), pero configurar ambos recursos como orígenes detrás de una distribución de CloudFront. Señale el comportamiento predeterminado de la caché en el depósito, luego use un patrón de ruta como /api/* para enrutar las solicitudes de API a API Gateway. Esto envía todas las solicitudes al origen apropiado, pero el nombre de host de su sitio en DNS apunta a CloudFront, donde se accede a todos los recursos, lo que significa que ninguna de las solicitudes será de origen cruzado; se accede a todo en un solo nombre de host. Las características de almacenamiento en caché/CDN de CloudFront son una ventaja para un rendimiento óptimo al obtener el contenido estático y se pueden desactivar para la API.
Parece que los costos son su preocupación... así que tenga esto en cuenta: SI alguno de los códigos del lado del servidor de su aplicación necesita comunicarse con Internet, también DEBE proporcionar una puerta de enlace NAT para que Lambda lo use para comunicarse con Internet. Por sí solo, Lambda NO TIENE ACCESO A INTERNET SALIENTE. Actualmente, una puerta de enlace NAT cuesta 0,045 por hora, además de los cargos por transferencia y procesamiento de datos. Con Lambda, solo paga por el tiempo que se ejecuta la función, pero su puerta de enlace NAT se ejecutará todo el tiempo. Además de esto, si su tráfico llega a su función Lambda a través de API Gateway, hay que considerarlo... dado que es una aplicación pequeña, voy a suponer que nunca alcanzará el límite para incurrir en los cargos de API Gateway, sin embargo, si tiene CloudTrail activado, obtendrá registros de CloudTrail para (1) Lambda, (2) NAT Gateway, (3) S3 y (4) API Gateway... lo que potencialmente puede configurarlo para posibles cargos de CloudTrail.
Ahora compare esto con la instancia más barata de Lightsail que cuesta 0,047 por hora y ya tiene acceso a Internet. De acuerdo, la RAM disponible es muy pequeña, pero si está ejecutando una aplicación pequeña... y con suerte no está escrita en Java, entonces esto no debería ser un problema. Además, la pila es mucho más pequeña y fácil de administrar.
Entonces, con una diferencia de referencia de 0,002 centavos por hora (comparando el costo de NAT Gateway con los costos de Lightsail)... y también teniendo en cuenta la simplicidad de Lightsail,... Lightsail podría ser una mejor opción.
Si le preocupa el hecho de que Lambda escalará automáticamente, tenga en cuenta que puede activar mediante programación instancias de Lightsail adicionales y más grandes y, básicamente, lograr el mismo tipo de paradigma de escalado. Sin embargo, tenga en cuenta que no puede simplemente cerrar una instancia de Lightsail que no está utilizando, debe eliminarla antes de fin de mes para evitar el cargo mensual completo.
Dicho esto, para una instancia de EC2, no es necesario que la elimine para evitar cargos adicionales, simplemente puede apagarla... así que, en realidad, recomendaría EC2 en lugar de Lightsail porque puede simplificar aún más las cosas.
FYI Para solucionar los problemas de CORS, debe crear una lambda que responda a la solicitud de verificación previa de opciones (y vincularla con la puerta de enlace API) y luego configurar la lambda para devolver los encabezados de CORS que desea