Editor Top
|
|
En algún momento, cada cliente de AWS me dice que desea avanzar hacia el futuro lo más rápido posible. Quieren simplificar sus esfuerzos de modernización, impulsar el crecimiento y adaptarse a la nube, al tiempo que reducen los costos a medida que avanzan. Estos clientes suelen tener un gran conjunto de aplicaciones heredadas, posiblemente ejecutándose localmente, que se ejecutan en diversas pilas de tecnología administradas por partes dispares de la organización. Para complicar aún más las cosas, estas organizaciones a menudo tienen que cumplir estrictos requisitos de seguridad y cumplimiento.
Prepárese para compartir
Ahora puede compartir recursos de AWS, como instancias de Amazon Elastic Compute Cloud (Amazon EC2), servicios de contenedores de Amazon Elastic Container Service (Amazon ECS) y Amazon Elastic Kubernetes Service (Amazon EKS), y sus propios servicios HTTPS en Amazon Virtual Private Cloud (Amazon VPC) y los límites de las cuentas de AWS y utilícelos para crear aplicaciones basadas en eventos a través de Amazon EventBridge y organizar flujos de trabajo con AWS Step Functions. Puede actualizar sus cargas de trabajo existentes, conectar sus aplicaciones modernas nativas de la nube a sistemas heredados locales, con toda la comunicación enrutada a través de redes y puntos finales privados.
Estas nuevas funciones se basan en Amazon VPC Lattice y AWS PrivateLink y le brindan muchas opciones nuevas para diseñar y controlar su red, junto con algunas formas nuevas e interesantes de integrar y orquestar todas sus pilas de tecnología. Por ejemplo, puede crear arquitecturas híbridas basadas en eventos que utilicen sus aplicaciones locales existentes.
Hoy en día, algunos clientes utilizan funciones de AWS Lambda o colas de Amazon Simple Queue Service (Amazon SQS) para transferir datos a VPC. Este trabajo pesado indiferenciado ahora puede sustituirse por una solución más sencilla y eficiente.
Al reunir todo esto, obtiene un conjunto de servicios que lo ayudarán a acelerar sus esfuerzos de modernización y simplificar la integración entre sus aplicaciones, independientemente de dónde se encuentren. EventBridge y Step Functions funcionan de la mano con PrivateLink y Celosía VPC para permitir la integración de aplicaciones públicas y privadas basadas en HTTPS en sus arquitecturas y flujos de trabajo basados en eventos.
Aquí están los términos y conceptos esenciales:
VPC del propietario del recurso – Una VPC que tiene recursos para compartir. El propietario de esta VPC crea una puerta de enlace de recursos con una o más configuraciones de recursos asociadas y luego utiliza AWS Resource Access Manager (RAM) para compartir la configuración de recursos con el consumidor de recursos, como otra cuenta de AWS o un desarrollador que crea arquitecturas basadas en eventos. y flujos de trabajo utilizando EventBridge y Step Functions. Definamos al propietario del recurso como la persona (tal vez usted) de su organización que es responsable del cuidado y la alimentación de este VPC.
Puerta de enlace de recursos – Proporciona un punto de entrada a una VPC para que los clientes puedan acceder a los recursos en la VPC del propietario del recurso, como lo indican las configuraciones de recursos asociadas con la puerta de enlace. Una puerta de enlace de recursos puede poner a disposición varios recursos.
Recurso – Puede ser un punto final HTTPS, una base de datos, un clúster de bases de datos, una instancia EC2, un balanceador de carga de aplicaciones delante de varias instancias EC2, un servicio ECS detectable a través de AWS Cloud Map, un servicio Amazon Elastic Kubernetes Service (Amazon EKS) detrás un balanceador de carga de red, un servicio heredado que se ejecuta en la VPC del propietario del recurso o en las instalaciones a través de AWS Site-to-Site VPN o AWS Direct Connect.
Configuración de recursos – Define un conjunto de recursos a los que se puede acceder a través de una puerta de enlace de recursos determinada. Se puede hacer referencia a los recursos mediante dirección IP, nombre DNS o (para recursos de AWS) un ARN.
Consumidor de recursos – La persona de su organización responsable de crear aplicaciones que se conectan y consumen servicios proporcionados por los recursos en una VPC del propietario del recurso.
Compartir recursos
Puedes utilizar todo este poder de muchas maneras diferentes; Me centraré en uno para esta publicación.
Primero, desempeñaré el papel de propietario del recurso. hago clic Puertas de enlace de recursos en la Consola VPC, vea que no tengo una puerta de enlace y haga clic en Crear puerta de enlace de recursos para empezar:
Le asigno un nombre (rg principal) y un tipo de dirección IP, luego elija la VPC y las subredes privadas donde tendrá presencia la puerta de enlace (esta es una selección única que no se puede cambiar sin crear una nueva puerta de enlace de recursos). También elijo hasta cinco grupos de seguridad para controlar el tráfico entrante:
Me desplazo hacia abajo, asigno las etiquetas deseadas y hago clic Crear puerta de enlace de recursos para proceder:
Mi nueva puerta de enlace se activa en cuestión de segundos; Asiento en agradecimiento y hago clic Crear configuración de recursos para seguir adelante:
Ahora necesito crear mi primera configuración de recursos. Digamos que tengo un servicio HTTPS ejecutándose en una instancia EC2 en una subred privada en mi VPC de propietario de recurso. Asigno un nombre DNS al servicio y uso un registro de alias de Amazon Route 53 que devuelve la dirección IP de la instancia:
Estoy usando una zona alojada pública en este ejemplo. Ya estamos trabajando en soporte para zonas alojadas privadas.
Con el DNS configurado, hago clic Crear configuración de recursos para seguir adelante. Introduzco un nombre (rc-servicio1), elegir Recurso como tipo y seleccione la puerta de enlace de recursos que creé anteriormente:
Me desplazo hacia abajo y defino mi instancia EC2 como recurso, introduzco el nombre DNS y configuro el uso compartido para los puertos 80 y 443:
Ahora tomo un pequeño desvío y salto a la consola RAM para crear un recurso compartido para que otras cuentas de AWS puedan acceder a los recursos (esto es opcional y solo es relevante para escenarios entre cuentas). Podría crear un recurso compartido para cada servicio, pero en la mayoría de los casos crearía un recurso compartido y lo usaría para empaquetar una colección de servicios relacionados. Haré eso y lo llamaré. servicios compartidos:
Al regresar de mi desvío, actualizo la lista de recursos compartidos, elijo el que creé y hago clic en Crear configuración de recursos:
La configuración de recursos está lista en segundos.
Resumen y tiempo de planificación
Antes de seguir adelante, hagamos un resumen rápido y hagamos algunos planes. Esto es lo que tengo hasta ahora (en el rol de proveedor de recursos):
- VPC principal – Mi VPC de propietario de recursos.
- rg principal – Una puerta de enlace de recursos en MainVPC.
- rc-servicio1 – La configuración de recursos para rg principal.
- servicio1 – Un servicio HTTPS alojado en una instancia EC2 en una subred privada de MainVPC, en una dirección IP fija.
Bien, ¿qué sigue?
Compartir – Este es el primer uso y el más obvio. Puedo utilizar AWS Resource Access Manager (RAM) para compartir la configuración de recursos con otra cuenta de AWS y acceder al servicio desde otra VPC. Por otro lado (como consumidor de recursos), sigo un par de pasos rápidos para conectarme al servicio que se ha compartido conmigo:
- Red de Servicio – Puedo crear una red de servicio, agregar la configuración de recursos a la red de servicio y crear un punto final de VPC en una VPC para conectarme a la red de servicio.
- Punto final – Puedo crear un punto final de VPC en una VPC y acceder al recurso compartido a través del punto final.
Modernizar – Puedo eliminar mi integración Lambda o SQS heredada para deshacerme de parte del trabajo pesado indiferenciado.
Construir – Puedo utilizar EventBridge y Step Functions para crear arquitecturas basadas en eventos y orquestar aplicaciones. ¡Tomaré esta opción!
Acceso a recursos privados con EventBridge y Step Functions
EventBridge y Step Functions ya facilitan el acceso a puntos finales HTTPS públicos, como los de proveedores de SaaS como Slack, Salesforce y Adobe. Con el lanzamiento de hoy, consumir servicios HTTPS privados es igual de fácil.
Como consumidor de recursos, simplemente creo una conexión EventBridge, hago referencia a una configuración de recursos que se compartió conmigo y llamo al servicio desde mi aplicación basada en eventos. Todo lo que ya sé todavía se aplica y ahora tengo el nuevo poder de acceder a servicios privados.
Para crear la conexión EventBridge, abro la consola EventBridge y hago clic Conexiones en el Integración menú:
Reviso mis conexiones existentes (ninguna hasta ahora), luego hago clic Crear conexión para seguir adelante:
Introduzco un nombre (MiServicio1) y una descripción de mi conexión, seleccione Privado como el tipo de APIy elija la Configuración de recursos que creé anteriormente:
Al desplazarme hacia abajo, necesito configurar la autorización para el servicio al que me estoy conectando. yo selecciono Configuración personalizada y Autorización básicae ingrese el Nombre de usuario y Contraseña por mi servicio. yo también agrego Acción=Previsión a la cadena de consulta (como puede ver, hay muchas opciones de autorización) y haga clic en Crear:
La conexión se crea y está lista en cuestión de minutos. Luego lo uso en mis flujos de trabajo de Step Functions usando la tarea HTTP, seleccionando la conexión, ingresando la URL de mi punto final API y eligiendo un método HTTP:
Y eso es todo: ¡sus flujos de trabajo de Step Functions ahora pueden utilizar recursos privados!
También puedo usar esta conexión como destino de destino de la API de EventBridge en Event Buses and Pipes.
Cosas que debes saber
Aquí un par de cosas que debes saber sobre estas nuevas funciones interesantes:
Precios – Se aplican los precios existentes para Step Functions, EventBridge, PrivateLink y VPC Lattice, incluido el cargo por GB para la transferencia de datos a la VPC.
Regiones – Puede crear y utilizar puertas de enlace de recursos y configuraciones de recursos en 21 regiones de AWS: EE. UU. Este (Ohio, Norte de Virginia), EE. UU. Oeste (Norte de California, Oregón), África (Ciudad del Cabo), Asia Pacífico (Hong Kong, Mumbai, Osaka, Seúl, Singapur, Sydney, Tokio), Canadá (Central), Europa (Frankfurt, Irlanda, Londres, Milán, París, Estocolmo), Medio Oriente (Bahrein) y América del Sur (São Paulo).
En las obras – Como señalé anteriormente, ya estamos trabajando en el soporte para zonas alojadas privadas. También planeamos admitir el acceso a otros tipos de recursos de AWS a través de EventBridge y Step Functions.
— jeff;
GIPHY App Key not set. Please check settings