Nous annonçons maintenant la possibilité pour les clients de Cloudflare d’analyser les anciens messages dans leurs boîtes de réception Office 365 afin de détecter les menaces. Le service Retro Scan vous permet de revenir sept jours en arrière, afin d’identifier les menaces qui n’ont pas été détectées par votre outil de sécurité actuel.
Pourquoi exécuter le service Retro Scan
Lorsque nous échangeons avec nos clients, ces derniers nous apprennent souvent qu’ils n’ont pas connaissance de l’état des boîtes aux lettres de leur entreprise. Les entreprises disposent d’un outil de sécurité des e-mails, ou elles utilisent la protection intégrée de Microsoft, mais elles ne sont pas en mesure de comprendre l’efficacité de leur solution actuelle. Nous constatons que les filtres de ces outils laissent souvent passer des e-mails malveillants, augmentant le risque de compromission de données au sein des entreprises.
Conformément à notre engagement de contribuer à bâtir un Internet meilleur, nous permettons désormais aux clients de Cloudflare d’utiliser Retro Scan pour analyser les messages dans leurs boîtes de réception à l’aide de nos modèles d’apprentissage automatique avancés – et ce, gratuitement. Notre service Retro Scan détectera et mettra en évidence toutes les menaces que nous identifions, afin de permettre aux clients d’éliminer les menaces contenues dans leurs boîtes de réception en remédiant directement à celles-ci depuis leurs comptes de messagerie. Avec ces informations, les clients peuvent également mettre en œuvre des contrôles supplémentaires, tels que l’utilisation de Cloudflare ou de la solution de leur choix, afin d’éviter que des menaces similaires ne parviennent leurs boîtes aux lettres à l’avenir.
Exécuter le service Retro Scan
Les clients peuvent accéder au tableau de bord de Cloudflare ; l’option Retro Scan se trouve sous l’onglet Area 1 :
Pour permettre à Cloudflare d’accéder aux messages à analyser, vous devez autoriser l’analyse des messages par l’application. Pour démarrer ce processus, accordez à Cloudflare les autorisations nécessaires pour exécuter l’analyse des messages. Une deuxième autorisation est nécessaire pour permettre à l’application Cloudflare d’accéder à Active Directory, afin de déterminer quels utilisateurs font partie de l’entreprise, ainsi que les groupes auxquels ils appartiennent ; ceci permet à nos algorithmes de mieux évaluer le caractère malveillant d’un message.
Une fois toutes les autorisations accordées, il reste une dernière étape : sélectionnez les domaines que vous souhaitez analyser, puis fournissez les informations requises concernant les autres fournisseurs de solutions de sécurité des e-mails utilisées pour protéger vos boîtes de réception.
Enfin, les clients peuvent cliquer sur « Generate Retro Scan » ; la solution de sécurité des e-mails Cloudflare Area 1 commencera alors à analyser les anciens messages. Puisque ce processus demande du temps, nous vous informerons par e-mail lorsque l’analyse sera terminée.
Analyse des résultats
Le service vous fournira une analyse rapide des menaces que nous avons détectées dans les boîtes de réception de votre entreprise. La section supérieure présente toutes les détections par type, indiquant le nombre de messages correspondant à chacune de ces catégories : Malicious (malveillants), Suspicious (suspects), Spoof (imitation), Spam (indésirables) et Bulk (envoi en masse). Nous mettons également en évidence les détections les plus importantes, qui requièrent votre attention, sous la catégorie Phish (phishing). Vous pouvez à tout moment cliquer sur le bouton Search (Rechercher) pour obtenir plus d’informations sur les e-mails portant ces intitulés.
Le rapport présente également les employés les plus fréquemment ciblés, ainsi que les endroits d’où proviennent le plus souvent les menaces. Toutes ces statistiques sont destinées à vous permettre de mieux comprendre ce qui se passe dans la boîte de réception de votre entreprise.
Comment s’inscrire ?
Le service Retro Scan est actuellement proposé en version bêta fermée. Si vous souhaitez exécuter le service Retro Scan sur vos domaines de messagerie Office 365, veuillez contacter votre interlocuteur chez Cloudflare, et nous ajouterons le service à votre compte.
Après avoir exécuté le service Retro Scan et examiné les résultats, vous pouvez choisir d’acheter la solution Cloudflare Area 1 afin d’empêcher les menaces futures d’atteindre votre boîte de réception ou choisir de mettre en place une évaluation du risque lié au phishing, qui propose un essai gratuit pendant 30 jours du produit Area 1. Si le service Retro Scan est un excellent outil pour détecter les menaces latentes, l’évaluation des risques liés au phishing peut vous aider à acquérir une meilleure visibilité de l’ensemble des outils que nous proposons pour protéger les boîtes aux lettres.
Pour commencer, vous pouvez cliquer sur le bouton Request Trial (Demander un essai) en bas du rapport Retro Scan, puis renseigner le formulaire correspondant ; un collaborateur de Cloudflare vous contactera alors, ou vous pouvez contacter directement votre interlocuteur Cloudflare.
Ab sofort können Cloudflare-Kunden alte Nachrichten in ihren Office 365-Postfächern auf Bedrohungen hin scannen. Mit dem Retro Scan können Sie jeweils die vergangenen sieben Tage überprüfen, um zu sehen, welche Bedrohungen Ihrem aktuellen E-Mail-Sicherheitstool entgangen sind.
Gründe für den Einsatz eines Retro Scan
Kunden berichten uns oft, dass sie nicht wissen, in welchem Zustand die E-Mail-Postfächer ihrer Unternehmen sind. Firmen nutzen ein E-Mail-Sicherheitstool oder den bei Microsoft integrierten Schutz. Oft ist wissen sie aber nicht, wie effektiv ihre aktuelle Lösung tatsächlich arbeitet. Wir haben festgestellt, dass schädliche E-Mails von diesen Werkzeugen oft nicht herausgefiltert werden, wodurch sich das Risiko einer Kompromittierung innerhalb des Unternehmens erhöht.
Im Rahmen unserer Bemühungen, ein besseres Internet zu schaffen, stellen wir Cloudflare-Kunden nun einen Retro Scan zur Verfügung. Mit diesem können sie Nachrichten in ihren Postfächern unter Einsatz fortschrittlicher Machine Learning-Modelle kostenlos scannen. Unser Retro Scan erkennt Bedrohungen und weist auf diese hin, sodass Kunden ihre Postfächer durch eine Behebung innerhalb ihrer E-Mail-Konten bereinigen können. Mit diesen Informationen sind sie außerdem in der Lage, herkömmliche Kontrollen zu implementieren. Sie können also Cloudflare oder ihre bevorzugte Lösung einsetzen, um vergleichbare Bedrohungen in Zukunft daran zu hindern, ihre Postfach überhaupt erst zu erreichen.
Einsatz des Retro Scan
Kunden finden im Cloudflare-Dashboard unter der Registerkarte Area 1 die Option „Retro Scan“:
Um zum Scannen auf die Nachrichten zugreifen zu können, benötigt Cloudflare eine entsprechende Berechtigung. Diese müssen Sie zunächst erteilen.Eine zweite Autorisierung erlaubt der Cloudflare-Anwendung den Zugriff auf Active Directory. Das ist notwendig, um in Erfahrung zu bringen, welche Nutzer zu dem Unternehmen gehören und welchen Gruppen sie angehören. Dies erleichtert es unseren Algorithmen, eine Einschätzung dazu zu treffen, ob eine Nachricht schädlich ist.
Nachdem alle Genehmigungen erteilt wurden, bleibt noch ein letzter Schritt: Sie müssen auswählen, welche Domains gescannt werden und uns Informationen zu den anderen E-Mail-Sicherheitsdiensten zukommen lassen, die Ihre Postfächer schützen.
Zu guter Letzt können Kunden per Klick auf „Generate Retro Scan“ die E-Mail-Sicherheitslösung Cloudflare Area 1 dazu veranlassen, mit dem Scan älterer Nachrichten zu beginnen. Da dieser Vorgang eine gewisse Zeit in Anspruch nimmt, werden die Kunden per E-Mail vom Abschluss des Scans informiert.
Analyse der Ergebnisse
Ihnen wird ein kurzer Überblick über die in den Postfächern Ihres Unternehmens aufgespürten Bedrohungen angezeigt. Im obersten Abschnitt werden alle ermittelten Bedrohungen nach Typ in Kategorien unterteilt. Hier sehen sie, wie viele schädliche, verdächtige und gefälschte Nachrichten sowie Spam- und Massennachrichten Sie jeweils erhalten haben. Unter „Phish emails“ heben wir die Nachrichten hervor, die die größte Aufmerksamkeit verdienen. Sie können sich jederzeit mit einem Klick auf das Suchfeld weitere Informationen über die entsprechend gekennzeichneten E-Mails anzeigen lassen.
In dem Bericht werden auch die Mitarbeitenden herausgehoben, die am stärksten zur Zielscheibe geworden sind, sowie die häufigsten Ursprünge von Bedrohungen. Diese Statistiken sollen Ihnen eine klarere Vorstellung davon vermitteln, was in den Postfächern Ihres Unternehmens vor sich geht.
Sie möchten sich registrieren? So funktioniert’s
Der Retro Scan ist zurzeit als Closed Beta-Version verfügbar. Falls Sie daran interessiert sind, ihn bei Ihren Office 365-E-Mail-Domains einzusetzen, wenden Sie sich gern an Ihre Ansprechpartnerin oder Ihren Ansprechpartner bei Cloudflare. Wir schalten diese Funktion dann für Ihr Konto frei.
Nachdem Sie einen Retro Scan durchgeführt und die Ergebnisse in Augenschein genommen haben, können Sie entweder zur Abschirmung Ihres Postfachs vor künftigen Bedrohungen Cloudflare Area 1 erwerben oder eine Phishing-Risikowertung vornehmen lassen, wobei es sich um eine 30-tägige kostenlose Probeversion des Area 1-Produkts handelt. Der Retro Scan ist ein großartiges Werkzeug zur Ermittlung latenter Bedrohungen. Eine Phishing-Risikobewertung hilft Ihnen dabei, sich einen besseren Überblick über alle Tools zu verschaffen, mit denen wir dafür sorgen, dass Postfächer nicht infiziert werden.
Zum Einstieg können Sie auf die Schaltfläche „Request Trial“ am Ende des Retro Scan-Berichts klicken und das daraufhin angezeigte Formular ausfüllen. Einer bzw. eine unserer Mitarbeitenden wird sich dann mit Ihnen in Verbindung setzen. Sie können sich aber auch direkt an Ihren Ansprechpartner bzw. Ihre Ansprechpartnerin bei Cloudflare wenden.
Agora anunciamos a possibilidade de os clientes da Cloudflare verificarem mensagens antigas em suas caixas de entrada do Office 365 em busca de ameaças. Este Retro Scan permitirá que você analise sete dias atrás e veja quais ameaças sua ferramenta de segurança de e-mail atual deixou passar.
Por que executar um Retro Scan
Conversando com os clientes, ouvimos frequentemente que eles não sabem o estado das caixas de entrada de suas organizações. As organizações possuem uma ferramenta de segurança de e-mail ou usam a proteção integrada da Microsoft, mas não entendem a eficácia de sua solução atual. Descobrimos que essas ferramentas muitas vezes permitem que e-mails maliciosos passem por seus filtros, aumentando o risco de comprometimento dentro da empresa.
Em nossa busca para ajudar a construir uma internet melhor, disponibilizamos para os clientes da Cloudflare o uso do Retro Scan para verificar mensagens em suas caixas de entrada usando nossos modelos avançados de aprendizado de máquina gratuitamente. Nosso Retro Scan detecta e destaca quaisquer ameaças que encontrarmos, assim os clientes podem limpar suas caixas de entrada tratando-as em suas contas de e-mail. Com essas informações, os clientes também podem implementar controles adicionais, como usar a Cloudflare ou sua solução preferida, para evitar que ameaças semelhantes cheguem às suas caixas de entrada no futuro.
Executar um Retro Scan
Os clientes podem navegar até o painel da Cloudflare, onde verão na guia Area 1 a opção Retro Scan:
Para poder acessar as mensagens, a Cloudflare precisa de autorização para poder verificar as mensagens. Você inicia esse processo fornecendo à Cloudflare as permissões apropriadas para verificar as mensagens. A segunda autorização permite que o aplicativo da Cloudflare acesse o Active Directory. Isso é necessário para entender quais usuários estão dentro da organização e a quais grupos eles pertencem, o que ajuda nossos algoritmos a avaliar melhor se uma mensagem é maliciosa.
Depois que todas as autorizações forem concedidas, você terá uma etapa final que é escolher quais domínios vamos verificar e nos fornecer informações sobre outros fornecedores de segurança de e-mail que estão protegendo suas caixas de entrada.
Por fim, os clientes podem clicar em “Gerar Retro Scan”, o que fará com que o Cloudflare Area 1 Email Security comece a verificar as mensagens mais antigas. Como esse processo é demorado, fornecemos aos clientes um alerta por e-mail quando a verificação estiver concluída.
Analise dos resultados
O que vai ser apresentado a você é uma rápida análise das ameaças que encontramos nas caixas de entrada de e-mail de sua organização. A seção superior divide todas as nossas detecções por tipo. Aqui você pode encontrar a contagem de mensagens maliciosas, suspeitas, falsas, spam e em massa. Também destacamos aquelas mais importantes a serem observadas nos e-mails de phishing. A qualquer momento você pode clicar no botão Pesquisar para obter mais informações sobre os e-mails com esses marcadores.
O relatório também mostra os principais funcionários visados, bem como os locais mais comuns de origem das ameaças. Todas essas estatísticas têm como objetivo fornecer uma melhor compreensão do que está acontecendo na caixa de entrada da sua empresa.
Como faço para me cadastrar
O Retro Scan está atualmente em beta fechado. Se você tiver interesse em executar uma verificação retroativa em seus domínios de e-mail do Office 365, fale com seu contato da Cloudflare e nós o adicionaremos à sua conta.
Depois de executar o Retro Scan e ver os resultados, você pode optar por adquirir o Cloudflare Area 1 para evitar que ameaças futuras cheguem à sua caixa de entrada ou optar por configurar uma avaliação de risco de phishing, que é uma avaliação gratuita de 30 dias do produto Area 1. Embora o Retro Scan seja uma ótima ferramenta para ver quais ameaças latentes existem, uma avaliação de risco de phishing pode ajudá-lo a obter melhor visibilidade sobre todas as ferramentas que temos para manter as caixas de entrada limpas.
Para começar, você pode clicar no botão “Solicitar avaliação” na parte inferior do relatório Retro Scan, preencher o formulário correspondente e alguém da Cloudflare entrará em contato ou você pode falar diretamente com seu contato da Cloudflare.
Ahora los clientes de Cloudflare pueden analizar viejos mensajes de sus bandejas de entrada de Office 365 en busca de amenazas. Retro Scan te permitirá observar qué amenazas ha pasado por alto tu actual herramienta de seguridad del correo electrónico en los últimos siete días.
Por qué ejecutar Retro Scan
Al hablar con los clientes, solemos escuchar que no conocen el estado de los buzones de correo de sus organizaciones. Las organizaciones tienen una herramienta de seguridad para correo electrónico o usan la protección integrada de Microsoft, pero no entienden qué nivel de efectividad tiene la actual solución. A menudo, descubrimos que estas herramientas permiten el paso de correos electrónicos maliciosos a través de sus filtros, lo que aumenta el riesgo en la empresa.
En nuestra búsqueda de ayudar a crear un mejor servicio de Internet, permitimos a los clientes de Cloudflare el uso de Retro Scan para analizar mensajes en sus buzones de entrada con nuestros modelos de aprendizaje automático avanzados, ¡gratis! Nuestro Retro Scan detecta y resalta las amenazas que encontramos para que los clientes puedan limpiar sus buzones de entrada y gestionarlas dentro de sus cuentas de correo electrónico. Con esta información, los clientes también pueden implementar controles adicionales, como el uso de Cloudflare o las soluciones que prefieran, para evitar que amenazas similares lleguen a sus casillas de correo en el futuro.
Cómo ejecutar Retro Scan
Los clientes pueden ir al panel de Cloudflare y allí verán debajo de la pestaña Área 1 la opción de Retro Scan:
Para poder tener acceso a los mensajes, Cloudflare necesita tener autorización para analizarlos. Para comenzar este proceso, debes brindar a Cloudflare los permisos correspondientes para analizar los mensajes. La segunda autorización permitirá que la aplicación de Cloudflare acceda al directorio activo. Eso es necesario para comprender qué usuarios están en la organización y a qué grupos pertenecen, lo que ayuda a que nuestros algoritmos evalúen mejor si un mensaje es malicioso.
Una vez que se conceden todas las autorizaciones, queda un último paso que consiste en elegir qué dominios queremos analizar y se nos facilita información sobre los demás proveedores de seguridad de correo electrónico que protegen tus bandejas de entrada.
Por último, los clientes pueden hacer clic en “Generar Retro Scan” que hará que Cloudflare Area 1 Email Security comience a analizar los mensajes más antiguos.Como este proceso lleva tiempo, avisamos a los clientes por correo electrónico cuando finaliza el análisis.
Cómo analizar los resultados
Se te brindará un detalle de las amenazas que encontramos en las bandejas de entrada de correo electrónico de tu organización.La sección superior muestra todas las detecciones por tipo. Aquí puedes encontrar el recuento de mensajes maliciosos, sospechosos, con suplantación de identidad, spam y mensajes masivos. También destacamos los más importantes a tener en cuenta en los correos electrónicos de phishing. En cualquier momento, puedes hacer clic en el botón Buscar para obtener más información sobre los correos electrónicos con esas etiquetas.
El informe también muestra los empleados que han recibido la mayor cantidad de ataques y los lugares más comunes de donde provienen las amenazas. Todas estas estadísticas sirven para comprender mejor lo que ocurre en la bandeja de entrada de tu empresa.
Cómo registrarse
El Retro Scan se encuentra actualmente en fase beta cerrada.Si te interesa ejecutar Retro Scan en tus dominios de correo electrónico de Office 365, comunícate con tu contacto de Cloudflare y lo incorporaremos a tu cuenta.
Después de ejecutar Retro Scan y ver los resultados, puedes optar por comprar Cloudflare Area 1 para evitar que futuras amenazas lleguen a tu bandeja de entrada o configurar una evaluación de riesgos de phishing, que es una prueba gratuita de 30 días del producto Área 1. Si bien Retro Scan es una excelente herramienta para ver qué amenazas latentes existen, una evaluación del riesgo de phishing puede ayudarte a obtener una mejor visibilidad de todas las herramientas que tenemos para mantener limpios los buzones de correo.
Para empezar, puedes hacer clic en el botón “Solicitar prueba” de la parte inferior del informe de Retro Scan, completar el formulario correspondiente y una persona de Cloudflare se pondrá en contacto contigo, o puedes comunicarte directamente con tu contacto de Cloudflare.
우리가 근무하면서 가장 좋아하는 부분은 Cloudflare 고객과 대화하는 시간입니다. 고객의 IT 및 보안 문제에 대하여 항상 새롭고 흥미로운 사실을 알게 됩니다.
최근 이러한 대화에 변화가 있었습니다. 고객이 언급하는 가장 큰 문제를 쉽게 정의할 수 없는 경우가 점점 더 많아집니다. 그리고 이러한 문제는 개별 제품이나 주요 기능으로 대처할 수 없는 것입니다.
더 정확히 말하면 IT 및 보안 팀에서는 디지털 환경에 대한 제어 능력을 잃고 있다고 이야기합니다.
제어 능력 상실은 다양한 형태를 띱니다. 고객은 호환성이 걱정되므로 필요성은 알지만 새로운 기능을 채택하는 것을 꺼리는 모습을 보일 수 있습니다. 아니면 비교적 단순한 변경 사항을 적용하는 데 시간과 노력이 많이 들며, 이러한 변경 사항 때문에 더 큰 영향력이 있을 작업에 투입할 시간을 빼앗기고 있다고 언급할 수도 있습니다. 고객이 느끼는 감정을 요약하자면 “팀이나 예산의 규모가 아무리 크더라도 비즈니스를 완벽하게 연결하고 보호하는 데는 절대 충분하지 않다”는 것입니다.
익숙하게 느껴지는 부분이 있으신가요? 그런 부분이 있다 해도 여러분 혼자 그렇게 느끼는 건 아닙니다.
제어 능력을 상실하는 이유
IT 및 보안이 바뀌는 속도는 빨라지고 있으며 무섭도록 복잡해지고 있습니다. IT 및 보안 팀에서는 과거에 비해 더 다양한 기술 도메인을 책임지고 있습니다. 최근 Forrester 연구에서 확인된 변화에 따르면 사내, 원격, 하이브리드 근무자를 보호할 책임이 있는 팀의 52%만이 지난 5년 동안 이러한 책임을 맡았습니다. 한편 46%는 해당 기간 동안 퍼블릭 클라우드 애플리케이션을 관리하고 보호할 책임이 생겼습니다. 그리고 53%는 규제 준수로 인한 어려운 문제를 떠맡았습니다.
IT 및 보안 팀에는 엄청난 과제가 생겼습니다. 원격 팀, 온프레미스 팀 및 인프라, 다양한 클라우드 환경, SaaS 앱 등을 연결하여 이들 모두가 안전한 단일 환경처럼 작동하게 만들어야 했습니다. 하지만 이 작업은 다양한 이유로 쉽지 않습니다.
대부분의 기업에서는 전용 인프라, 고유한 규제 준수 요구, 준호환성 프로세스 및 구성으로 인해 클라우드, SaaS 앱, 웹 앱, 온프레미스 인프라를 연결하는 것이 어렵습니다. 간단히 말하자면 이들 도메인은 쉽고 안전하게 함께 작동하도록 구축되지 않았습니다.
IT 및 보안은 언제 차선책과 복잡하게 얽힌 상호 의존성에 발목을 잡혀도 이상하지 않습니다.
다행히 Cloudflare에서는 전향적인 방법을 찾아냈습니다.
클라우드 연결성에 오신 것을 환영합니다
흔히 고객과의 대화에서 중요한 것은 행간을 읽는 능력입니다. 고객은 제어 능력 상실을 언급할 때, 명시하지는 않지만, 존재하지 않는다고 생각하는 무언가를 원하는 것처럼 보입니다. 고객은 IT 및 보안에서 담당하는 모든 것을 위한 연결 조직을 원합니다. 즉, 환경의 모든 것을 다루고, 모든 곳에서 제공되며, 필요한 모든 보안, 네트워킹, 개발 기능을 수행하여 복잡성을 줄이는 무언가를 필요로 합니다.
추가 연구 결과 우리의 짐작이 확신으로 바뀌었습니다. IT 및 보안 리더를 대상으로 진행한 설문조사에서는 이들 중 72%가 안전한 “모든 용도에 사용 가능한” 클라우드 플랫폼을 높이 평가하는 것으로 확인되었습니다. 그리고 이들은 전체 IT 및 보안 예산에서 평균 16%를 이러한 플랫폼에 투자할 의향이 있음을 밝혔습니다.
따라서 Cloudflare에서는 이런 클라우드 플랫폼이 정확히 어떤 모습일지 생각하기 시작했습니다. 그 플랫폼에서 필요한 모든 작업을 어떻게 수행할 수 있을까요?
우리가 찾은 해답을 공유합니다. 바로 클라우드 연결성입니다.
클라우드 연결성은 디지털 환경을 보호하고 연결하기 위해 기업에서 필요로 하는 다양한 서비스를 제공하는 새로운 접근법입니다. 클라우드 연결성은 프로그래밍 가능한 클라우드 네이티브 서비스의 통합 인텔리전스 플랫폼으로, 모든 네트워크(엔터프라이즈 및 인터넷), 클라우드 환경, 애플리케이션, 사용자 사이에 모든 용도에 사용 가능한 연결을 가능하게 해줍니다. 클라우드 연결성에는 수많은 보안, 성능, 개발자 서비스가 포함됩니다. 그 주안점은 모든 것을 모든 장소에서 대체하는 기능이 아니라, 필요한 장소에 탑재하고 중요한 여러 서비스를 단일 플랫폼으로 통합하는 능력입니다.
클라우드 연결성은 4가지 기본 원칙에 따라 구축되었습니다.
심층 통합 — 조직에서는 인터넷에 의존하여 디지털 환경의 다양한 요소를 근무자, 파트너, 고객과 연결합니다. 클라우드 연결성은 인터넷 및 엔터프라이즈 네트워크와 기본적으로 통합되므로 모든 사용자, 애플리케이션, 인프라 간에 안전하고 대기 시간이 짧으며 무한히 확장 가능한 연결이 가능합니다. 클라우드 연결성은 인터넷만큼 빠르고 직관적이면서도 위험이나 불확실성은 없습니다.
프로그래밍 가능성 — 모든 엔터프라이즈 디지털 환경에는 독점 인프라, 다양한 클라우드, 고유 규제 준수 요구, 그리고 기타 전용 툴링, 프로세스, 구성이 존재합니다. 클라우드 연결성의 아키텍처는 한계가 없는 상호 운용성과 사용자 지정 가능한 네트워킹을 제공하므로 일관된 사용자 경험 및 효율적인 관리가 가능하며 고유한 요구에 적응할 수 있습니다.
플랫폼 인텔리전스 — 조직에서는 디지털 환경에서 모든 것을 연결하고 보호하기 위해 다양한 서비스를 필요로 합니다. 하지만 모든 것을 통합하는 것은 부담스러운 일이며 모두 관리하려고 하면 비효율적이고 보안에 구멍이 생깁니다. 잘 설계된 클라우드 연결성에는 기본적으로 다양한 서비스가 구축되어 있으며 자동으로 인텔리전스 모델을 업데이트하기 위해 매우 높은 볼륨의 다양한 트래픽을 분석합니다.
단순성 — IT 및 보안 서비스가 너무 많으면 대시보드도 너무 많아집니다. 이로 인해 비효율적이 되고, 가시성이 낮아지며, 알림으로 인해 피곤해집니다. 단일 플랫폼으로 100% 통합하는 것이 해답은 아니지만, 클라우드 연결성은 단일 제어판에서 IT 환경의 훨씬 더 많은 부분을 관리하므로 무분별하게 확장되는 도구와 대시보드 과부하가 크게 줄어듭니다.
이러한 특징을 지닌 클라우드 연결성으로 더 많은 제어 능력을 잃지 않는 채로 디지털 환경에 새로운 서비스를 추가할 수 있습니다. 이미 보유하고 있는 서비스에 대한 제어 능력을 다시 확보하는 데도 도움이 됩니다.
Cloudflare의 클라우드 연결성
우리가 이러한 4가지 특성을 특히 중시하는 성향이 있음을 인정합니다. Cloudflare에서는 처음부터 통합, 프로그래밍 가능성, 플랫폼 인텔리전스, 단순성이라는 원칙을 기반으로 서비스를 구축했습니다. 현재 Cloudflare의 전체 포트폴리오는 충분히 포괄적이어서 고객이 수많은 보안 및 IT 요구를 해결할 때 이러한 이점을 누릴 수 있습니다.
이러한 접근법 덕분에 Cloudflare가 세계 최초 클라우드 연결성임이 되었음을 자랑스레 말씀드릴 수 있습니다.
우리가 주장하는 것을 직접 확인해 보세요. 다음은 Cloudflare의 지원으로 제어 능력 문제를 해결한 고객 사례입니다.
Conrad Electric: 전 세계에 걸쳐 분산된 인력의 액세스 보호
클라우드 연결성에서는 프로그래밍 가능성, 심층 네트워크 통합, 기본 제공 인텔리전스를 제공하므로 기업 리소스에 안전한 액세스를 보장하는 데 이상적입니다.
전자제품 소매업체인 Conrad Electronic에서는 “직원을 온라인 상태로 유지하는 것만으로도 다양한 관리 병목 현상이 발생했습니다”라고 이야기합니다. 이 회사에 근무하는 2,300명의 직원 중 절반 가까이가 원격으로 기업 애플리케이션에 액세스해야 하며 이러한 액세스를 활성화는 것은 쉽지 않았습니다. 이를 위해 각 사용자를 대상으로 VPN 클라이언트를 배포하고 구성해야 했으니까요.
Conrad Electronic에서는 이제 Cloudflare의 클라우드 연결성을 이용하여 수백 개의 기업 애플리케이션에 안전한 원격 액세스를 제공합니다. 관리 부담이 크게 줄어들었으며 웹 운영을 개선하는 데 이제 매달 훨씬 더 많은 시간을 투자할 수 있다고 담당자는 이야기합니다. 또한 보안 상태도 개선되었습니다. “한 번의 클릭으로 특정 개인을 제한하거나 중요한 영역을 보호할 수 있습니다. 1,000개의 VPN 프로필을 유지할 필요가 없으므로 보안이 개선되고 시간과 비용이 절약됩니다.”
Carrefour: 고객이 직접 사용하며 신뢰할 수 있는 애플리케이션 제공 및 관리
클라우드 연결성을 이용하면 위협 인텔리전스, 네트워크 통합, 통합 인터페이스로 보안 간극을 훌륭하게 메꿀 수 있으며 전 세계에 걸쳐 애플리케이션을 안전하게 제공할 수 있습니다.
다국적 소매 및 도매 기업인 Carrefour는 호황을 누리며 빠른 성장세를 구가하고 있는 전자 상거래 업체입니다. 그러나 사이버 공격이 늘어났을 때 단순히 보안 스택을 늘리는 것은 도움이 되지 않았습니다. Carrefour 보안 팀 관계자는 “다양한 도구를 바꿔가며 사용하다 보니 아키텍처 조정과 제어가 어려웠습니다… 또한, 여러 도구를 아우르는 통합 기능이 없어 보안 및 성능 문제를 조사하고 해결하는 것이 복잡했고 시간이 오래 걸렸습니다”라고 이야기합니다.
폭넓은 보안 기능 변경의 일환으로 Carrefour에서는 Cloudflare의 클라우드 연결성을 채택하여 웹 악용, zero-day 위협, 악의적 봇 공격을 차단했습니다. 이를 통해 각기 다른 벤더에서 제공하는 5개의 보안 도구를 대체할 수 있었습니다. 그 이후로 Carrefour에서는 사고 해결 시간이 75% 단축되었습니다.
Canva: 혁신적인 애플리케이션 구축
마지막으로 클라우드 연결성의 프로그래밍 가능성과 네트워크 통합은 거의 모든 상황에서 혁신적인 개발을 지원하는 데 도움이 됩니다.
글로벌 설계 대기업인 Canva가 그 좋은 예입니다. 전에 이 회사에서는 다양한 개발자 플랫폼을 이용하여 네트워크 에지에서 사용자 지정 코드를 실행했습니다. 하지만 이러한 서비스를 사용하려면 시간이 너무 오래 걸렸고, 혁신에 방해가 되는 한계에 부딪혀야 했습니다.
Cloudflare의 클라우드 연결성은 “우리 소프트웨어의 중요한 부분”이 되었습니다. Canva에서는 클라우드 연결성의 개발자 서비스를 사용하여 사용자 지정 코드를 작성하고 실행하며 SEO 및 시간 제한 콘텐츠 액세스를 위해 페이지 제공을 최적화합니다. 최근 Canva의 관계자는 우리에게 “당사는 Cloudflare 덕분에 플랫폼이 신속하고 안정적이며 안전하다는 확신을 갖고 제품의 성장과 신규 시장으로의 확장에 집중할 수 있습니다”라고 이야기했습니다.
또한 Canva의 경험은 안전한 액세스 및 애플리케이션 제공을 위해 Cloudflare 제품을 채택하는 것으로 이어졌습니다. 이는 클라우드 연결성을 100% 활용하여 운영하는 경우의 예시를 아주 잘 보여줍니다.
클라우드 연결성에 대해 자세히 알아보세요
고객 덕분에 우리는 혁신을 이룰 수 있으며 클라우드 연결성의 비전도 예외가 아닙니다. 모든 것을 더 쉽고, 빠르며, 안전하고, 연결된 상태로 만들기 위해 노력하고 있습니다. 클라우드 연결성 덕분에 복잡성이 줄어들고 보안이 개선되는 모습을 보게 되어 정말 기쁩니다.
여기에서 클라우드 연결성에 대해 자세히 알아볼 수 있습니다. 하지만 이는 시작일 뿐이라고 생각해 주시면 좋겠습니다. 질문이 있거나 제안할 것이 있으면 Cloudflare로 연락해 주시기 바랍니다. 안전하고 연결된 여정에서 고객을 계속해서 도울 방법을 찾기 위한 대화를 계속할 수 있을 것으로 기대합니다.
Nearly 70% of companies that are breached are likely to get breached again within twelve months (CPO). Effective remediation and addressing attacks at the root is key to staying ahead of threats and recurring breaches on the endpoint. Strong Digital Forensics and Incident Response (DFIR) ready to go when any incident occurs is a critical piece of a security team’s toolkit and drives successful response and remediation.
With this in mind, we’re excited to announce the integration of Velociraptor, Rapid7’s leading open-source DFIR framework, into the Insight Platform for InsightIDR Ultimate users — all with no additional deployment or configurations required. Already utilized in the field by our Incident Response experts on behalf of Managed Detection and Response (MDR) customers, InsightIDR Ultimate users can now experience the power of Velociraptor, from daily threat monitoring and hunting to swift threat response.
Key benefits of Velociraptor in InsightIDR:
Hunt for threats and vulnerabilities on single endpoints or across the entire fleet conveniently within InsightIDR, enabling faster identification and remediation.
Leverage the latest security researcher and practitioner-contributed Artifacts (structured YAML files containing queries) from Velociraptor’s Exchange. This ensures you always have up-to-date coverage across the current threat landscape.
Monitor for threat activity as it occurs on the endpoint, and forward matching events to InsightIDR for in-depth investigations into potential threats.
Efficiently analyze all of your Velociraptor data inside of InsightIDR with the flexibility of custom Notebooks (used to track and post process hunts or collaborate on an investigation) or the visual navigation of the Virtual File System (a server side cache of the files on the endpoint).
Unlock expanded threat detection capabilities – like EVTX or ETW watcher plug-ins to monitor Windows event sources – with Velociraptor’s Client Monitoring feature and forward alert investigations into InsightIDR.
Get to the bottom of new threats quickly with the most up-to-date detections thanks to Velociraptor’s expressive query language (rather than code) that makes it faster and easier for teams to share custom detections with the open-source community.
Let’s walk through a potential scenario with InsightIDR and Velociraptor
Jo is a SOC analyst on a team that uses Rapid7 Insight products to monitor and respond to security incidents in a fleet of a few thousand endpoints. This morning, an email notification for a new InsightIDR investigation grabs Jo’s full attention – an endpoint just triggered an alert from a usually quiet detection rule named “Velociraptor – Alert.Windows.ETW.Powershell”, and the data in the preview immediately looks suspicious to Jo.
Jo jumps into InsightIDR to begin their investigation. The endpoint in question has only triggered this single alert so far. It was forwarded from Velociraptor, a recent addition to Jo’s toolset within the Rapid7 Insight Platform. The artifact was one of several they’d deployed to endpoints for continuous monitoring. While InsightIDR and the Sysmon integration could already detect suspicious Powershell commands when included in Process Start commandline arguments, this artifact adds visibility into Windows Powershell ETW provider for logged events.
Jo follows the link to Velociraptor, provided in the InsightIDR Investigation. The link goes directly to the Alert.Windows.ETW.Powershell event page for the endpoint that triggered the investigation. From here, Jo starts a KAPE triage collection on this endpoint. Then they start a hunt across the entire fleet for the indicators of compromise they’ve gathered so far.
Data from Jo’s collection flows into the UI for review. After noticing an unfamiliar grandparent for Powershell in the process list, Jo decides to quarantine the endpoint. They go back to their InsightIDR tab, search for the affected endpoint, and toggle its Quarantine flag. Now that endpoint can only communicate with the Rapid7 Platform, which now includes Velociraptor.
Among the hundreds in the hunt’s scope, a handful of endpoints return matches for Jo’s initial queries. Jo recruits a few of their teammates to help triage the results and begin deeper investigation. Between Velociraptor’s powerful DFIR capabilities and the skills of Jo’s team, the intruder will be thwarted before completing their mission.
After the incident response concludes, Jo reviews the new Velociraptor Artifacts they created to detect this new malicious activity. They decide that a few of these will be useful submissions to the Artifact Exchange. They also take the opportunity to browse other recent additions from the DIFR community and deploy a few to their Velociraptor instance.
With Rapid7’s platform-hosted Velociraptor service, Jo’s team was able to skip another lengthy deployment process and leap right into monitoring and hunting for threats. They were also welcomed to the wider open-source Velociraptor community to share knowledge, threat intel, and DFIR techniques with the practitioners who help Velociraptor thrive.
Today, we’re excited to announce that any Cloudflare user, on any plan, can choose specific categories of bots that they want to allow or block, including AI crawlers.
As the popularity of generative AI has grown, content creators and policymakers around the world have started to ask questions about what data AI companies are using to train their models without permission. As with all new innovative technologies, laws will likely need to evolve to address different parties' interests and what’s best for society at large. While we don’t know how it will shake out, we believe that website operators should have an easy way to block unwanted AI crawlers and to also let AI bots know when they are permitted to crawl their websites.
The good news is that Cloudflare already automatically stops scraper bots today. But we want to make it even easier for customers to be sure they are protected, see how frequently AI scrapers might be visiting their sites, and respond to them in more targeted ways. We also recognize that not all AI crawlers are the same and that some AI companies are looking for clear instructions for when they should not crawl a public website.
Crawler bots are nothing new. Cloudflare already protects you from scraping today.
Web crawlers have been around for a long time. The first, called World Wide Web Wanderer, was developed back in 1993 to measure the size of the web by counting the total number of accessible web pages. This technique led directly to the creation of the first popular search engine, WebCrawler, in 1994.
And still today, the most common use of a web crawler is for a search engine: Google’s GoogleBot. To provide the most relevant results for searches, crawlers like GoogleBot typically start by visiting web pages and retrieving the HTML content. Search engine operators predefine how much of the crawled HTML files is necessary for indexing, and then the files will be parsed to extract components like text, images, metadata, and links. This extracted data will then be stored in a structured format back on Google’s servers. Extracted links (URLs) are the key to how the crawlers discover new websites. The links that were present in the HTML files are added to a queue of URLs for the crawlers to visit and parse. And URLs are pretty easily spread around the Internet making it easy for crawlers to discover new sites. It can even be a URL that appeared in a referrer header that was stored and published by another web server. This process of following links, parsing, and storing data is recursively repeated allowing search engines to map out the web. All this collected data is then indexed to allow for efficient searching and retrieval of information.
While search engine crawler operations are generally beneficial for a site owner to get their site discovered, there are bot operators that use similar techniques for more malicious purposes such as price scraping to undercut competitor pricing or theft of copyrighted material such as images.
The techniques deployed by AI crawlers are no different. Just like a search engine crawler, they’ll parse HTML content and follow extracted URLs to gather available information. But instead of using it to index the web, this content will be applied as training data for their ML models.
Along with our bot detection tools, we also have a Verified Bot directory that allows responsible and necessary bots, like GoogleBot, to register to be segmented into their own separate detections (fill out a request here if you have a bot you think should be added). We’ve added new functionality to that directory to give our customers more control.
Available now: segment known bots with flexibility and precision
Our new Verified Bot categories are now available in the Cloudflare Rules Engine and Workers. With this granular bot categorization, Cloudflare users get better bot segmentation, and can choose specific responses to specific types of bots. To take advantage of these new bot categories, simply log in to the Cloudflare dash, go to the WAF tab, create a rule, and choose one of the Verified Bot sub categories as the Field.
The new categories include:
Search Engine Crawler,
Aggregator,
AI Crawler,
Page Preview,
Advertising
Academic Research,
Accessibility,
Feed Fetcher,
Security,
Webhooks.
You can also view all the available categories using the Cloudflare API.
More targeted responses can be useful in a variety of situations. A few examples include:
If you are a content creator, and you’re concerned about your work being reproduced by AI services, you can block AI bots we have cataloged in a simple firewall rule, while still allowing search engine crawlers to index your site.
If your content is frequently shared on social media, you may want to use Workers to serve a simplified version of the page to Page Preview services, like the services that X (formerly Twitter), Discord and Slack are using to render a thumbnail version of a web page.
If you run an online store that processes payments through webhooks API, you can harden your site’s security by only allowing verified webhooks services to make a request to that API endpoint.
If you are using Cloudflare’s Load Balancing service and have limited in-region capacity, you can use Custom Rules for Load Balancing to send all bots except Search Engine Crawlers to a backup pool, prioritizing critical visitors over non-critical automated services.
Above all, these new categories give you, the website owner, complete, granular control over not only whether bots can visit your site, but what specific types of bots can and can’t do. For those of you that simply don’t want any bots, no problem, you don’t have to make any changes. Your existing rules that reference bot score or our Verified bots change will not be impacted at all.
More than just blocking, encouraging good behavior to make the Internet better
At Cloudflare, we have a history of working with good bot operators (like GoogleBot), who respect Internet norms and best practices, to access the websites that want to allow them. We want to encourage good behavior by AI crawlers as well, so we have developed a set of criteria that will allow us to tag respectful AI bots differently. In order to be tagged as a respectful AI bot, AI crawler must take the following steps to show they are acting in good faith:
Maintain a public web page committing to respect robots.txt.
Set IPs that are used solely by the bot and are verifiable via a public IP list, reverse DNS lookup, or ASN ownership.
Maintain a unique and stable user-agent to represent the bot.
Respect a robots.txt entry for your user-agent as well as wild-card entries.
Requiring all AI crawlers to respect crawl-delay, which has previously been a nonstandard extension.
These steps are an expansion of our existing Verified Bots policy which you can see here. When a bot creator has performed the steps above, we perform additional evaluation to confirm we’ve seen no suspicious activity from the bot. We check the bot's documentation, check internal dashboards to ensure traffic is appropriately distributed across the sites we protect, and check whether the bot hits suspicious endpoints like logins, or has exhibited other malicious activity.
While new AI bots can be scary, this industry is evolving incredibly quickly, and you may want to handle different bots differently in the future. We think it's important to distinguish between bot operators that are being respectful and those that are trying to be deceptive.
It should be easy for everyone to deal with AI crawlers, not just Cloudflare customers
While we’re glad we’ve made it easy for Cloudflare customers to manage AI Crawlers, not everyone uses Cloudflare. We want the Internet to be better for everyone. So we think that the industry should adopt a new protocol specifically for handling AI crawlers.
In the long run, AI bots respecting a new exclusion protocol gives website operators the most flexibility to change how they want to handle them over time. We think the key is to make it easier for customers to block these bots, or to allow them in some cases if they choose on their entire website or only on specific pages.
You’ll be hearing more about this from us in the next few months, so stay tuned.
But we didn’t want to wait to make sure our customers are protected, so we're making our new bot categories available today!
What’s next?
The first and most important step for us was to make it clear to every Cloudflare customer that you are already protected from AI crawlers you don’t want. Second, we wanted to give you granular control and make it easy to allow those crawlers, or other bots, that you deem useful for your site.
We encourage everyone to try out our new Verified Bot categories today. Log in to the Cloudflare dash, go to the WAF tab, create a rule, and choose one of the Verified Bot sub categories as the `Field`. And remember, this functionality is available to all Cloudflare customers, even on free plans.
Having launched Verified Bot categories, in the next few months we’ll be adding more detailed reporting based on the bot category, to better help you visualize the frequency at which different categories of bots are visiting your site over time. As AI continues to evolve at a breakneck pace, AI Crawlers are only going to become a larger part of the Internet. As that evolution happens, Cloudflare will be there every step of the way to help you evolve the way you deal with them.
For years, we’ve written that CAPTCHAs drive us crazy. Humans give up on CAPTCHA puzzles approximately 15% of the time and, maddeningly, CAPTCHAs are significantly easier for bots to solve than they are for humans. We’ve spent the past three and a half years working to build a better experience for humans that’s just as effective at stopping bots. As of this month, we’ve finished replacing every CAPTCHA issued by Cloudflare withTurnstile, our new CAPTCHA replacement (pictured below). Cloudflare will never issue another visual puzzle to anyone, for any reason.
Now that we’ve eliminated CAPTCHAs at Cloudflare, we want to make it easy for anyone to do the same, even if they don’t use other Cloudflare services. We’ve decoupled Turnstile from our platform so that any website operator on any platform can use it just by adding a few lines of code. We’re thrilled to announce that Turnstile is now generally available, and Turnstile’s ‘Managed’ mode is now completely free to everyone for unlimited use.
Easy on humans, hard on bots, private for everyone
There’s a lot that goes into Turnstile’s simple checkbox to ensure that it’s easy for everyone, preserves user privacy, and does its job stopping bots. Part of making challenges better for everyone means that everyone gets the same great experience, no matter what browser you’re using. Because we do not employ a visual puzzle, users with low vision or blindness get the same easy to use challenge flow as everyone else. It was particularly important for us to avoid falling back to audio CAPTCHAs to offer an experience accessible to everyone. Audio CAPTCHAs are often much worse than even visual CAPTCHAs for humans to solve, with only 31.2% of audio challenges resulting in a three-person agreement on what the correct solution actually is. The prevalence of free speech-to-text services has made it easy for bots to solve audio CAPTCHAs as well, with a recent study showing bots can accurately solve audio CAPTCHAs in over 85% of attempts.
We also created Turnstile to be privacy focused. Turnstile meets ePrivacy Directive, GDPR and CCPA compliance requirements, as well as the strict requirements of our own privacy commitments. In addition, Cloudflare's FedRAMP Moderate authorized package, "Cloudflare for Government" now includes Turnstile. We don’t rely on tracking user data, like what other websites someone has visited, to determine if a user is a human or robot. Our business is protecting websites, not selling ads, so operators can deploy Turnstile knowing that their users’ data is safe.
With all of our emphasis on how easy it is to pass a Turnstile challenge, you would be right to ask how it can stop a bot. If a bot can find all images with crosswalks in grainy photos faster than we can, surely it can check a box as well. Bots definitely can check a box, and they can even mimic the erratic path of human mouse movement while doing so. For Turnstile, the actual act of checking a box isn’t important, it’s the background data we’re analyzing while the box is checked that matters. We find and stop bots by running a series of in-browser tests, checking browser characteristics, native browser APIs, and asking the browser to pass lightweight tests (ex: proof-of-work tests, proof-of-space tests) to prove that it’s an actual browser. The current deployment of Turnstile checks billions of visitors every day, and we are able to identify browser abnormalities that bots exhibit while attempting to pass those tests.
For over one year, we used our Managed Challenge to rotate between CAPTCHAs and our own Turnstile challenge to compare our effectiveness. We found that even without asking users for any interactivity at all, Turnstile was just as effective as a CAPTCHA. Once we were sure that the results were effective at coping with the response from bot makers, we replaced the CAPTCHA challenge with our own checkbox solution. We present this extra test when we see potentially suspicious signals, and it helps us provide an even greater layer of security.
Turnstile is great for fighting fraud
Like all sites that offer services for free, Cloudflare sees our fair share of automated account signups, which can include “new account fraud,” where bad actors automate the creation of many different accounts to abuse our platform. To help combat this abuse, we’ve rolled out Turnstile’s invisible mode to protect our own signup page. This month, we’ve blocked over1 million automated signup attempts using Turnstile, without a reported false positive or any change in our self-service billings that rely on this signup flow.
Lessons from the Turnstile beta
Over the past twelve months, we’ve been grateful to see how many people are eager to try, then rely on, and integrate Turnstile into their web applications. It’s been rewarding to see the developer community embrace Turnstile as well. We list some of the community created Turnstile integrations here, including integrations with WordPress, Angular, Vue, and a Cloudflare recommended React library. We’ve listened to customer feedback, and added support for 17 new languages, new callbacks, and new error codes.
76,000+ users have signed up, but our biggest single test by far was the Eurovision final vote. Turnstile runs on challenge pages on over 25 million Cloudflare websites. Usually, that makes Cloudflare the far and away biggest Turnstile consumer, until the final Eurovision vote. During that one hour, challenge traffic from the Eurovision voting site outpaced the use of challenge pages on those 25 million sites combined! Turnstile handled the enormous spike in traffic without a hitch.
While a lot went well during the Turnstile beta, we also encountered some opportunities for us to learn. We were initially resistant to disclosing why a Turnstile challenge failed. After all, if bad actors know what we’re looking for, it becomes easier for bots to fool our challenges until we introduce new detections. However, during the Turnstile beta, we saw a few scenarios where legitimate users could not pass a challenge. These scenarios made it clear to us that we need to be transparent about why a challenge failed to help aid any individual who might modify their browser in a way that causes them to get caught by Turnstile. We now publish detailed client-side error codes to surface the reason why a challenge has failed. Two scenarios came up on several occasions that we didn’t expect:
First, we saw that desktop computers at least 10 years old frequently had expired motherboard batteries, and computers with bad motherboard batteries very often keep inaccurate time. This is because without the motherboard battery, a desktop computer’s clock will stop operating when the computer is off. Turnstile checks your computer’s system time to detect when a website operator has accidentally configured a challenge page to be cached, as caching a challenge page will cause it to become impassable. Unfortunately, this same check was unintentionally catching humans who just needed to update the time. When we see this issue, we now surface a clear error message to the end user to update their system time. We’d prefer to never have to surface an error in the first place, so we’re working to develop new ways to check for cached content that won’t impact real people.
Second, we find that a few privacy-focused users often ask their browsers to go beyond standard practices to preserve their anonymity. This includes changing their user-agent (something bots will do to evade detection as well), and preventing third-party scripts from executing entirely. Issues caused by this behavior can now be displayed clearly in a Turnstile widget, so those users can immediately understand the issue and make a conscientious choice about whether they want to allow their browser to pass a challenge.
Although we have some of the most sensitive, thoroughly built monitoring systems at Cloudflare, we did not catch either of these issues on our own. We needed to talk to users affected by the issue to help us understand what the problem was. Going forward, we want to make sure we always have that direct line of communication open. We’re rolling out a new feedback form in the Turnstile widget, to ensure any future corner cases are addressed quickly and with urgency.
Turnstile: GA and Free for Everyone
Announcing Turnstile’s General Availability means that Turnstile is now completely production ready, available for free for unlimited use via our visible widget in Managed mode. Turnstile Enterprise includes SaaS platform support and a visible mode without the Cloudflare logo. Self-serve customers can expect a pay-as-you-go option for advanced features to be available in early 2024. Users can continue to access Turnstile’s advanced features below our 1 million siteverify request limit, as has been the case during the beta. If you’ve been waiting to try Turnstile, head over to our signup page and create an account!
The Amazon Elastic Compute Cloud (Amazon EC2) Instance Metadata Service (IMDS) helps customers build secure and scalable applications. IMDS solves a security challenge for cloud users by providing access to temporary and frequently-rotated credentials, and by removing the need to hardcode or distribute sensitive credentials to instances manually or programmatically. The Instance Metadata Service Version 2 (IMDSv2) adds protections; specifically, IMDSv2 uses session-oriented authentication with the following enhancements:
IMDSv2 requires the creation of a secret token in a simple HTTP PUT request to start the session, which must be used to retrieve information in IMDSv2 calls.
The IMDSv2 session token must be used as a header in subsequent IMDSv2 requests to retrieve information from IMDS. Unlike a static token or fixed header, a session and its token are destroyed when the process using the token terminates. IMDSv2 sessions can last up to six hours.
A session token can only be used directly from the EC2 instance where that session began.
You can reuse a token or create a new token with every request.
Session token PUT requests are blocked if they contain an X-forwarded-for header.
In a previous blog post, we explained how these new protections add defense-in-depth for third-party and external application vulnerabilities that could be used to try to access the IMDS.
You won’t be able to get the full benefits of IMDSv2 until you disable IMDSv1. While IMDS is provided by the instance itself, the calls to IMDS are from your software. This means your software must support IMDSv2 before you can disable IMDSv1. In addition to AWS SDKs, CLIs, and tools like the SSM agents supporting IMDSv2, you can also use the IMDS Packet Analyzer to pinpoint exactly what you need to update to get your instances ready to use only IMDSv2. These tools make it simpler to transition to IMDSv2 as well as launch new infrastructure with IMDSv1 disabled. All instances launched with AL2023 set the instance to provide only IMDSv2 (IMDSv1 is disabled) by default, with AL2023 also not making IMDSv1 calls.
AWS customers who want to get the benefits of IMDSv2 have told us they want to use IMDSv2 across both new and existing, long-running AWS infrastructure. This blog post shows you scalable solutions to identify existing infrastructure that is providing IMDSv1, how to transition to IMDSv2 on your infrastructure, and how to completely disable IMDSv1. After reviewing this blog, you will be able to set new Amazon EC2 launches to IMDSv2. You will also learn how to identify existing software making IMDSv1 calls, so you can take action to update your software and then require IMDSv2 on existing EC2 infrastructure.
Identifying IMDSv1-enabled EC2 instances
The first step in transitioning to IMDSv2 is to identify all existing IMDSv1-enabled EC2 instances. You can do this in various ways.
Using the console
You can identify IMDSv1-enabled instances using the IMDSv2attribute column in the Amazon EC2 page in the AWS Management Console.
To view the IMDSv2 attribute column:
Open the Amazon EC2 console and go to Instances.
Choose the settings icon in the top right.
Scroll down to IMDSv2, turn on the slider.
Choose Confirm.
This gives you the IMDS status of your instances. A status of optional means that IMDSv1 is enabled on the instance and required means that IMDSv1 is disabled.
Figure 1: Example of IMDS versions for EC2 instances in the console
Using the AWS CLI
You can identify IMDSv1-enabled instances using the AWS Command Line Interface (AWS CLI) by running the aws ec2 describe-instances command and checking the value of HttpTokens. The HttpTokens value determines what version of IMDS is enabled, with optional enabling IMDSv1 and IMDSv2 and required means IMDSv2 is required. Similar to using the console, the optional status indicates that IMDSv1 is enabled on the instance and required indicates that IMDSv1 is disabled.
AWS Config continually assesses, audits, and evaluates the configurations and relationships of your resources on AWS, on premises, and on other clouds. The AWS Config rule ec2-imdsv2-check checks whether your Amazon EC2 instance metadata version is configured with IMDSv2. The rule is NON_COMPLIANT if the HttpTokens is set to optional, which means the EC2 instance has IMDSv1 enabled.
Figure 2: Example of noncompliant EC2 instances in the AWS Config console
Identifying if EC2 instances are making IMDSv1 calls
Not all of your software will be making IMDSv1 calls; your dependent libraries and tools might already be compatible with IMDSv2. However, to mitigate against compatibility issues in requiring IMDSv2 and disabling IMDSv1 entirely, you must check for remaining IMDSv1 calls from your software. After you’ve identified that there are instances with IMDSv1 enabled, investigate if your software is making IMDSv1 calls. Most applications make IMDSv1 calls at instance launch and shutdown. For long running instances, we recommend monitoring IMDSv1 calls during a launch or a stop and restart cycle.
Figure 6: Another example of using CloudWatch expressions to view account wide metrics
If you have multiple AWS accounts or use AWS Organizations, you can set up a centralized monitoring account using CloudWatch cross account observability.
IMDS Packet Analyzer
The IMDS Packet Analyzer is an open source tool that identifies and logs IMDSv1 calls from your software, including software start-up on your instance. This tool can assist in identifying the software making IMDSv1 calls on EC2 instances, allowing you to pinpoint exactly what you need to update to get your software ready to use IMDSv2. You can run the IMDS Packet Analyzer from a command line or install it as a service. For more information, see IMDS Packet Analyzer on GitHub.
Disabling IMDSv1 and maintaining only IMDSv2 instances
After you’ve monitored and verified that the software on your EC2 instances isn’t making IMDSv1 calls, you can disable IMDSv1 on those instances. For all compatible workloads, we recommend using Amazon Linux 2023, which offers several improvements (see launch announcement), including requiring IMDSv2 (disabling IMDSv1) by default.
You can also create and modify AMIs and EC2 instances to disable IMDSv1. Configure the AMI provides guidance on how to register a new AMI or change an existing AMI by setting the imds-support parameter to v2.0. If you’re using container services (such as ECS or EKS), you might need a bigger hop limit to help avoid falling back to IMDSv1. You can use the modify-instance-metadata-options launch parameter to make the change. We recommend testing with a hop limit of three in container environments.
To create a new instance
For new instances, you can disable IMDSv1 and enable IMDSv2 by specifying the metadata-options parameter using the run-instance CLI command.
If you’re using the console to launch instances, after selecting Launch Instance from AWS Console, choose the Advanced details tab, scroll down to Metadata version and select V2 only (token required).
Figure 7: Modifying IMDS version using the console
Using EC2 launch templates
You can use an EC2 launch template as an instance configuration template that an Amazon Auto Scaling group can use to launch EC2 instances. When creating the launch template using the console, you can specify the Metadata version and select V2 only (token required).
Figure 8: Modifying the IMDS version in the EC2 launch templates
In this state, retrieving the AWS Identity and Access Management (IAM) role credentials always returns IMDSv2 credentials; IMDSv1 credentials are not available.
On the Owned by Amazon tab, for Automation document, enter EnforceEC2InstanceIMDSv2, and then press Enter.
Choose EnforceEC2InstanceIMDSv2 document, and then choose Next.
For Execute automation document, choose Simple execution.
Note: If you need to run the automation on multiple targets, then choose Rate Control.
For Input parameters, enter the ID of EC2 instance under InstanceId
For AutomationAssumeRole, select a role.
Note: To change the target EC2 instance, the AutomationAssumeRole must have ec2:ModifyInstanceMetadataOptions and ec2:DescribeInstances permissions. For more information about creating the assume role for Systems Manager Automation, see Create a service role for Automation.
To maintain only IMDSv2 instances, you can implement service control policies and IAM policies that verify that users and software on your EC2 instances can only use instance metadata using IMDSv2. This policy specifies that RunInstance API calls require the EC2 instance use only IMDSv2. We recommend implementing this policy after all of the instances in associated accounts are free of IMDSv1 calls and you have migrated all of the instances to use only IMDSv2.
You can find more details on applicable service control policies (SCPs) and IAM policies in the EC2 User Guide.
Restricting credential usage using condition keys
As an additional layer of defence, you can restrict the use of your Amazon EC2 role credentials to work only when used in the EC2 instance to which they are issued. This control is complementary to IMDSv2 since both can work together. The AWS global condition context keys for EC2 credential control properties (aws:EC2InstanceSourceVPC and aws:EC2InstanceSourcePrivateIPv4) restrict the VPC endpoints and private IPs that can use your EC2 instance credentials, and you can use these keys in service control policies (SCPs) or IAM policies. Examples of these policies are in this blog post.
Conclusion
You won’t be able to get the full benefits of IMDSv2 until you disable IMDSv1. In this blog post, we showed you how to identify IMDSv1-enabled EC2 instances and how to determine if and when your software is making IMDSv1 calls. We also showed you how to disable IMDSv1 on new and existing EC2 infrastructure after your software is no longer making IMDSv1 calls. You can use these tools to transition your existing EC2 instances, and set your new EC2 launches, to use only IMDSv2.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS Compute re:Post or contact AWS Support.
Want more AWS Security news? Follow us on Twitter.
Based on immutable facts (events), event-driven architectures (EDAs) allow businesses to gain deeper insights into their customers’ behavior, unlocking more accurate and faster decision-making processes that lead to better customer experiences. In EDAs, modern event brokers, such as Amazon EventBridge and Apache Kafka, play a key role to publish and subscribe to events. EventBridge is a serverless event bus that ingests data from your own apps, software as a service (SaaS) apps, and AWS services and routes that data to targets. Although there is overlap in their role as the backbone in EDAs, both solutions emerged from different problem statements and provide unique features to solve specific use cases. With a solid understanding of both technologies and their primary use cases, developers can create easy-to-use, maintainable, and evolvable EDAs.
If the use case is well defined and directly maps to one event bus, such as event streaming and analytics with streaming events (Kafka) or application integration with simplified and consistent event filtering, transformation, and routing on discrete events (EventBridge), the decision for a particular broker technology is straightforward. However, organizations and business requirements are often more complex and beyond the capabilities of one broker technology. In almost any case, choosing an event broker should not be a binary decision. Combining complementary broker technologies and embracing their unique strengths is a solid approach to build easy-to-use, maintainable, and evolvable EDAs. To make the integration between Kafka and EventBridge even smoother, AWS open-sourced the EventBridge Connector based on Apache Kafka. This allows you to consume from on-premises Kafka deployments and avoid point-to-point communication, while using the existing knowledge and toolset of Kafka Connect.
Streaming applications enable stateful computations over unbound datasets. This allows real-time use cases such as anomaly detection, event-time computations, and much more. These applications can be built using frameworks such as Apache Flink, Apache Spark, or Kafka Streams. Although some of those frameworks support sending events to downstream systems other than Apache Kafka, there is no standardized way of doing so across frameworks. It would require each application owner to build their own logic to send events downstream. In an EDA, the preferred way to handle such a scenario is to publish events to an event bus and then send them downstream.
There are two ways to send events from Apache Kafka to EventBridge: the preferred method using Amazon EventBridge Pipes or the EventBridge sink connector for Kafka Connect. In this post, we explore when to use which option and how to build an EDA using the EventBridge sink connector and Amazon Managed Streaming for Apache Kafka (Amazon MSK).
EventBridge sink connector vs. EventBridge Pipes
EventBridge Pipes connects sources to targets with a point-to-point integration, supporting event filtering, transformations, enrichment, and event delivery to over 14 AWS services and external HTTPS-based targets using API Destinations. This is the preferred and most easy method to send events from Kafka to EventBridge as it simplifies the setup and operations with a delightful developer experience.
Alternatively, under the following circumstances you might want to choose the EventBridge sink connector to send events from Kafka directly to EventBridge Event Buses:
You are have already invested in processes and tooling around the Kafka Connect framework as the platform of your choice to integrate with other systems and services
You need to integrate with a Kafka-compatible schema registry e.g., the AWS Glue Schema Registry, supporting Avro and Protobuf data formats for event serialization and deserialization
You want to send events from on-premises Kafka environments directly to EventBridge Event Buses
Overview of solution
In this post, we show you how to use Kafka Connect and the EventBridge sink connector to send Avro-serialized events from Amazon Managed Streaming for Apache Kafka (Amazon MSK) to EventBridge. This enables a seamless and consistent data flow from Apache Kafka to dozens of supported EventBridge AWS and partner targets, such as Amazon CloudWatch, Amazon SQS, AWS Lambda, and HTTPS targets like Salesforce, Datadog, and Snowflake using EventBridge API destinations. The following diagram illustrates the event-driven architecture used in this blog post based on Amazon MSK and EventBridge.
The workflow consists of the following steps:
The demo application generates credit card transactions, which are sent to Amazon MSK using the Avro format.
An analytics application running on Amazon Elastic Container Service (Amazon ECS) consumes the transactions and analyzes them if there is an anomaly.
If an anomaly is detected, the application emits a fraud detection event back to the MSK notification topic.
The EventBridge connector consumes the fraud detection events from Amazon MSK in Avro format.
The connector converts the events to JSON and sends them to EventBridge.
In EventBridge, we use JSON filtering rules to filter our events and send them to other services or another Event Bus. In this example, fraud detection events are sent to Amazon CloudWatch Logs for auditing and introspection, and to a third-party SaaS provider to showcase how easy it is to integrate with third-party APIs, such as Salesforce.
Prerequisites
For this walkthrough, you should have the following prerequisites:
This walkthrough requires you to deploy an AWS CDK stack to your account. You can deploy the full stack end to end or just the required resources to follow along with this post.
Deploy the AWS CDK stack based on your preferences:
If you want to see the complete setup explained in this post, run the following command:
cdk deploy —context deployment=FULL
If you want to deploy the connector on your own but have the required resources already, including the MSK cluster, AWS Identity and Access Management (IAM) roles, security groups, data generator, and so on, run the following command:
cdk deploy —context deployment=PREREQ
Deploy the EventBridge sink connector on Amazon MSK Connect
If you deployed the CDK stack in FULL mode, you can skip this section and move on to Create EventBridge rules.
The connector needs an IAM role that allows reading the data from the MSK cluster and sending records downstream to EventBridge.
Download the release 1.0.0 with the AWS Glue Schema Registry dependencies included.
On the Amazon S3 console, choose Buckets in the navigation pane.
Choose Create bucket.
For Bucket name, enter eventbridgeconnector-bucket-${AWS_ACCOUNT_ID}.
As Because S3 buckets must be globally unique, replace ${AWS_ACCOUNT_ID} with your actual AWS account ID. For example, eventbridgeconnector-bucket-123456789012.
Open the bucket and choose Upload.
Select the .jar file that you downloaded from the GitHub repository and choose Upload.
Create a custom plugin
We now have our application code in Amazon S3. As a next step, we create a custom plugin in Amazon MSK Connect. Complete the following steps:
On the Amazon MSK console, choose Custom plugins in the navigation pane under MSK Connect.
Choose Create custom plugin.
For S3 URI – Custom plugin object, browse to the file named kafka-eventbridge-sink-with-gsr-dependencies.jar in the S3 bucket eventbridgeconnector-bucket-${AWS_ACCOUNT_ID} for the EventBridge connector.
For Custom plugin name, enter msk-eventBridge-sink-plugin-v1.
Enter an optional description.
Choose Create custom plugin.
Wait for plugin to transition to the status Active.
Create a connector
Complete the following steps to create a connector in MSK Connect:
On the Amazon MSK console, choose Connectors in the navigation pane under MSK Connect.
Choose Create connector.
Select Use existing custom plugin and under Custom plugins, select the plugin msk-eventBridge-sink-plugin-v1 that you created earlier.
Choose Next.
For Connector name, enter msk-eventBridge-sink-connector.
Enter an optional description.
For Clustertype, select MSK cluster.
For MSK clusters, select the cluster you created earlier.
For Authentication, choose IAM.
Under Connector configurations, enter the following settings (for more details on the configuration, see the GitHub repository):
Make sure to replace aws.eventbridge.eventbus.arn, aws.eventbridge.region, and value.converter.region with the values from the prerequisite stack.
In the Connector capacity section, select Autoscaled for Capacity type.
Leave the default value of 1 for MCU count per worker.
Keep all default values for Connector capacity.
For Worker configuration, select Use the MSK default configuration.
Under Access permissions, choose the custom IAM role KafkaEventBridgeSinkStack-connectorRole, which you created during the AWS CDK stack deployment.
Choose Next.
Choose Next again.
For Log delivery, select Deliver to Amazon CloudWatch Logs.
For Log group, choose /aws/mskconnect/eventBridgeSinkConnector.
Choose Next.
Under Review and Create, validate all the settings and choose Create connector.
The connector will be now in the state Creating. It can take up to several minutes for the connector to transition into the status Running.
Create EventBridge rules
Now that the connector is forwarding events to EventBridge, we can use EventBridge rules to filter and send events to other targets. Complete the following steps to create a rule:
On the EventBridge console, choose Rules in the navigation pane.
Choose Create rule.
Enter eb-to-cloudwatch-logs-and-webhook for Name.
Select eventbridge-sink-eventbus for Event bus.
Choose Next.
Select Custom pattern (JSON editor), choose Insert, and replace the event pattern with the following code:
For Target 1, select CloudWatch log group and enter kafka-events for Log Group.
Choose Add another target.
(Optional: Create an API destination) For Target 2, select EventBridge API destination for Target types.
Select Create a new API destination.
Enter a descriptive name for Name.
Add the URL and enter it as API destination endpoint. (This can be the URL of your Datadog, Salesforce, etc. endpoint)
Select POST for HTTP method.
Select Create a new connection for Connection.
For Connection Name, enter a name.
Select Other as Destination type and select API Key as Authorization Type.
For API key name and Value, enter your keys.
Choose Next.
Validate your inputs and choose Create rule.
The following screenshot of the CloudWatch Logs console shows several events from EventBridge.
Run the connector in production
In this section, we dive deeper into the operational aspects of the connector. Specifically, we discuss how the connector scales and how to monitor it using CloudWatch.
Scale the connector
Kafka connectors scale through the number of tasks. The code design of the EventBridge sink connector doesn’t limit the number of tasks that it can run. MSK Connect provides the compute capacity to run the tasks, which can be from Provisioned or Autoscaled type. During the deployment of the connector, we choose the capacity type Autoscaled and 1 MCU per worker (which represents 1vCPU and 4GiB of memory). This means MSK Connect will scale the infrastructure to run tasks but not the number of tasks. The number of tasks is defined by the connector. By default, the connector will start with the number of tasks defined in tasks.max in the connector configuration. If this value is higher than the partition count of the processed topic, the number of tasks will be set to the number of partitions during the Kafka Connect rebalance.
Monitor the connector
MSK Connect emits metrics to CloudWatch for monitoring by default. Besides MSK Connect metrics, the offset of the connector should also be monitored in production. Monitoring the offset gives insights if the connector can keep up with the data produced in the Kafka cluster.
Clean up
To clean up your resources and avoid ongoing charges, complete the following the steps:
On the Amazon MSK console, choose Connectors in the navigation pane under MSK Connect.
Select the connectors you created and choose Delete.
Choose Clusters in the navigation pane.
Select the cluster you created and choose Delete on the Actions menu.
On the EventBridge console, choose Rules in the navigation pane.
Choose the event bus eventbridge-sink-eventbus.
Select all the rules you created and choose Delete.
Confirm the removal by entering delete, then choose Delete.
If you deployed the AWS CDK stack with the context PREREQ, delete the .jar file for the connector.
On the Amazon S3 console, choose Buckets in the navigation pane.
Navigate to the bucket where you uploaded your connector and delete the kafka-eventbridge-sink-with-gsr-dependencies.jar file.
Independent from the chosen deployment mode, all other AWS resources can be deleted by using AWS CDK or AWS CloudFormation. Run cdk destroy from the repository directory to delete the CloudFormation stack.
Alternatively, on the AWS CloudFormation console, select the stack KafkaEventBridgeSinkStack and choose Delete.
Conclusion
In this post, we showed how you can use MSK Connect to run the AWS open-sourced Kafka connector for EventBridge, how to configure the connector to forward a Kafka topic to EventBridge, and how to use EventBridge rules to filter and forward events to CloudWatch Logs and a webhook.
Florian Mair is a Senior Solutions Architect and data streaming expert at AWS. He is a technologist that helps customers in Germany succeed and innovate by solving business challenges using AWS Cloud services. Besides working as a Solutions Architect, Florian is a passionate mountaineer, and has climbed some of the highest mountains across Europe.
Benjamin Meyer is a Senior Solutions Architect at AWS, focused on Games businesses in Germany to solve business challenges by using AWS Cloud services. Benjamin has been an avid technologist for 7 years, and when he’s not helping customers, he can be found developing mobile apps, building electronics, or tending to his cacti.
Some real numbers about the cost of AI components.
The AI tech stack and some of the industry solutions that have been built to serve it.
And, uncertainty.
Defining AI: Complexity and Cost Implications
While ChatGPT, DALL-E, and the like may be the most buzz-worthy of recent advancements, AI has already been a part of our daily lives for several years now. In addition to generative AI models, examples include virtual assistants like Siri and Google Home, fraud detection algorithms in banks, facial recognition software, URL threat analysis services, and so on.
That brings us to the first challenge when it comes to understanding the cost of AI: The type of AI you’re training—and how complex a problem you want it to solve—has a huge impact on the computing resources needed and the cost, both in the training and in the implementation phases. AI tasks are hungry in all ways: they need a lot of processing power, storage capacity, and specialized hardware. As you scale up or down in the complexity of the task you’re doing, there’s a huge range in the types of tools you need and their costs.
To understand the cost of AI, several other factors come into play as well, including:
Latency requirements: How fast does the AI need to make decisions? (e.g. that split second before a self-driving car slams on the brakes.)
Scope: Is the AI solving broad-based or limited questions? (e.g. the best way to organize this library vs. how many times is the word “cat” in this article.)
Actual human labor: How much oversight does it need? (e.g. does a human identify the cat in cat photos, or does the AI algorithm identify them?)
Adding data: When, how, and what quantity new data will need to be ingested to update information over time?
This is by no means an exhaustive list, but it gives you an idea of the considerations that can affect the kind of AI you’re building and, thus, what it might cost.
The Big Three AI Cost Drivers: Hardware, Storage, and Processing Power
In simple terms, you can break down the cost of running an AI to a few main components: hardware, storage, and processing power. That’s a little bit simplistic, and you’ll see some of these lines blur and expand as we get into the details of each category. But, for our purposes today, this is a good place to start to understand how much it costs to ask a bot to create a squirrel holding a cool guitar.
Still not quite there on the guitar. Or the squirrel. How much could this really cost?
First Things First: Hardware Costs
Running an AI takes specialized processors that can handle complex processing queries. We’re early in the game when it comes to picking a “winner” for specialized processors, but these days, the most common processor is a graphical processing unit (GPU), with Nvidia’s hardware and platform as an industry favorite and front-runner.
Google offers folks the ability to rent their TPUs through the cloud starting at $1.20 per chip hour for on-demand service (less if you commit to a contract). Meanwhile, Intel released a sub-$100 USB stick with a full NPU that can plug into your personal laptop, and folks have created their own models at home with the help of open sourced developer toolkits. Here’s a guide to using them if you want to get in the game yourself.
Clearly, the spectrum for chips is vast—from under $100 to millions—and the landscape for chip producers is changing often, as is the strategy for monetizing those chips—which leads us to our next section.
Using Third Parties: Specialized Problems = Specialized Service Providers
Building AI is a challenge with so many moving parts that, in a business use case, you eventually confront the question of whether it’s more efficient to outsource it. It’s true of storage, and it’s definitely true of AI processing. You can already see one way Google answered that question above: create a network populated by their TPUs, then sell access.
Other companies specialize in broader or narrower parts of the AI creation and processing chain. Just to name a few, diverse companies: there’s Hugging Face, Inflection AI, CoreWeave, and Vultr. Those companies have a wide array of product offerings and resources from open source communities like Hugging Face that provide a menu of models, datasets, no-code tools, and (frankly) rad developer experiments to bare metal servers like Vultr that enhance your compute resources. How resources are offered also exist on a spectrum, including proprietary company resources (i.e. Nvidia’s platform), open source communities (looking at you, Hugging Face), or a mix of the two.
This means that, whichever piece of the AI tech stack you’re considering, you have a high degree of flexibility when you’re deciding where and how much you want to customize and where and how to implement an out-of-the box solution.
Ballparking an estimate of what any of that costs would be so dependent on the particular model you want to build and the third-party solutions you choose that it doesn’t make sense to do so here. But, it suffices to say that there’s a pretty narrow field of folks who have the infrastructure capacity, the datasets, and the business need to create their own network. Usually it comes back to any combination of the following: whether you have existing infrastructure to leverage or are building from scratch, if you’re going to sell the solution to others, what control over research or dataset you have or want, how important privacy is and how you’re incorporating it into your products, how fast you need the model to make decisions, and so on.
Welcome to the Spotlight, Storage
And, hey, with all that, let’s not forget storage. At the most basic level of consideration, AI uses a ton of data. How much? Going knowledge says at least an order of magnitude more examples than the problem presented to train an AI model. That means you want 10 times more examples than parameters.
Parameters and Hyperparameters
The easiest way to think of parameters is to think of them as factors that control how an AI makes a decision. More parameters = more accuracy. And, just like our other AI terms, the term can be somewhat inconsistently applied. Here’s what ChatGPT has to say for itself:
That 10x number is just the amount of data you store for the initial training model—clearly the thing learns and grows, because we’re talking about AI.
Preserving both your initial training algorithm and your datasets can be incredibly useful, too. As we talked about before, the more complex an AI, the higher the likelihood that your model will surprise you. And, as many folks have pointed out, deciding whether to leverage an already-trained model or to build your own doesn’t have to be an either/or—oftentimes the best option is to fine-tune an existing model to your narrower purpose. In both cases, having your original training model stored can help you roll back and identify the changes over time.
The size of the dataset absolutely affects costs and processing times. The best example is that ChatGPT, everyone’s favorite model, has been rocking GPT-3 (or 3.5) instead of GPT-4 on the general public release because GPT-4, which works from a much larger, updated dataset than GPT-3, is too expensive to release to the wider public. It also returns results much more slowly than GPT-3.5, which means that our current love of instantaneous search results and image generation would need an adjustment.
And all of that is true because GPT-4 was updated with more information (by volume), more up-to-date information, and the model was given more parameters to take into account for responses. So, it has to both access more data per query and use more complex reasoning to make decisions. That said, it also reportedly has much better results.
Storage and Cost
What are the real numbers to store, say, a primary copy of an AI dataset? Well, it’s hard to estimate, but we can ballpark that, if you’re training a large AI model, you’re going to have at a minimum tens of gigabytes of data and, at a maximum, petabytes. OpenAI considers the size of its training database proprietary information, and we’ve found sources that cite that number as anywhere from 17GB to 570GB to 45TB of text data.
That’s not actually a ton of data, and, even taking the highest number, it would only cost $225 per month to store that data in Backblaze B2 (45TB * $5/TB/mo), for argument’s sake. But let’s say you’re training an AI on video to, say, make a robot vacuum that can navigate your room or recognize and identify human movement. Your training dataset could easily reach into petabyte scale (for reference, one petabyte would cost $5,000 per month in Backblaze B2). Some research shows that dataset size is trending up over time, though other folks point out that bigger is not always better.
On the other hand, if you’re the guy with the Intel Neural Compute stick we mentioned above and a Raspberry Pi, you’re talking the cost of the ~$100 AI processor, ~$50 for the Raspberry Pi, and any incidentals. You can choose to add external hard drives, network attached storage (NAS) devices, or even servers as you scale up.
Storage and Speed
Keep in mind that, in the above example, we’re only considering the cost of storing the primary dataset, and that’s not very accurate when thinking about how you’d be using your dataset. You’d also have to consider temporary storage for when you’re actually training the AI as your primary dataset is transformed by your AI algorithm, and nearly always you’re splitting your primary dataset into discrete parts and feeding those to your AI algorithm in stages—so each of those subsets would also be stored separately. And, in addition to needing a lot of storage, where you physically locate that storage makes a huge difference to how quickly tasks can be accomplished. In many cases, the difference is a matter of seconds, but there are some tasks that just can’t handle that delay—think of tasks like self-driving cars.
For huge data ingest periods such as training, you’re often talking about a compute process that’s assisted by powerful, and often specialized, supercomputers, with repeated passes over the same dataset. Having your data physically close to those supercomputers saves you huge amounts of time, which is pretty incredible when you consider that it breaks down to as little as milliseconds per task.
One way this problem is being solved is via caching, or creating temporary storage on the same chips (or motherboards) as the processor completing the task. Another solution is to keep the whole processing and storage cluster on-premises (at least while training), as you can see in the Microsoft-OpenAI setup or as you’ll often see in universities. And, unsurprisingly, you’ll also see edge computing solutions which endeavor to locate data physically close to the end user.
While there can be benefits to on-premises or co-located storage, having a way to quickly add more storage (and release it if no longer needed), means cloud storage is a powerful tool for a holistic AI storage architecture—and can help control costs.
And, as always, effective backup strategies require at least one off-site storage copy, and the easiest way to achieve that is via cloud storage. So, any way you slice it, you’re likely going to have cloud storage touch some part of your AI tech stack.
What Hardware, Processing, and Storage Have in Common: You Have to Power Them
Here’s the short version: any time you add complex compute + large amounts of data, you’re talking about a ton of money and a ton of power to keep everything running.
Fortunately for us, other folks have done the work of figuring out how much this all costs. This excellent article from SemiAnalysis goes deep on the total cost of powering searches and running generative AI models. The Washington Post cites Dylan Patel (also of SemiAnalysis) as estimating that a single chat with ChatGPT could cost up to 1,000 times as much as a simple Google search. Those costs include everything we’ve talked about above—the capital expenditures, data storage, and processing.
Consider this: Google spent several years putting off publicizing a frank accounting of their power usage. When they released numbers in 2011, they said that they use enough electricity to power 200,000 homes. And that was in 2011. There are widely varying claims for how much a single search costs, but even the most conservative say .03 Wh of energy. There are approximately 8.5 billion Google searches per day. (That’s just an incremental cost by the way—as in, how much does a single search cost in extra resources on top of how much the system that powers it costs.)
Power is a huge cost in operating data centers, even when you’re only talking about pure storage. One of the biggest single expenses that affects power usage is cooling systems. With high-compute workloads, and particularly with GPUs, the amount of work the processor is doing generates a ton more heat—which means more money in cooling costs, and more power consumed.
So, to Sum Up
When we’re talking about how much an AI costs, it’s not just about any single line item cost. If you decide to build and run your own models on-premises, you’re talking about huge capital expenditure and ongoing costs in data centers with high compute loads. If you want to build and train a model on your own USB stick and personal computer, that’s a different set of cost concerns.
And, if you’re talking about querying a generative AI from the comfort of your own computer, you’re still using a comparatively high amount of power somewhere down the line. We may spread that power cost across our national and international infrastructures, but it’s important to remember that it’s coming from somewhere—and that the bill comes due, somewhere along the way.
While the CVE process was created in response to real problems, it’s increasingly clear that CVE numbers are
creating problems of their own. At the 2023 GNU Tools Cauldron,
Siddhesh Poyarekar expressed the frustration that toolchain developers have
felt as the result of arguing with security researchers about CVE-number
assignments. In response, the GNU toolchain community is trying to better
characterize what is — and is not — considered to be a security-relevant
bug in its software.
This April, we announced Amazon Bedrock as part of a set of new tools for building with generative AI on AWS. Amazon Bedrock is a fully managed service that offers a choice of high-performing foundation models (FMs) from leading AI companies, including AI21 Labs, Anthropic, Cohere, Stability AI, and Amazon, along with a broad set of capabilities to build generative AI applications, simplifying the development while maintaining privacy and security.
Today, I’m happy to announce that Amazon Bedrock is now generally available! I’m also excited to share that Meta’s Llama 2 13B and 70B parameter models will soon be available on Amazon Bedrock.
Amazon Bedrock’s comprehensive capabilities help you experiment with a variety of top FMs, customize them privately with your data using techniques such as fine-tuning and retrieval-augmented generation (RAG), and create managed agents that perform complex business tasks—all without writing any code. Check out my previous posts to learn more about agents for Amazon Bedrock and how to connect FMs to your company’s data sources.
Note that some capabilities, such as agents for Amazon Bedrock, including knowledge bases, continue to be available in preview. I’ll share more details on what capabilities continue to be available in preview towards the end of this blog post.
Since Amazon Bedrock is serverless, you don’t have to manage any infrastructure, and you can securely integrate and deploy generative AI capabilities into your applications using the AWS services you are already familiar with.
Amazon Bedrock is integrated with Amazon CloudWatch and AWS CloudTrail to support your monitoring and governance needs. You can use CloudWatch to track usage metrics and build customized dashboards for audit purposes. With CloudTrail, you can monitor API activity and troubleshoot issues as you integrate other systems into your generative AI applications. Amazon Bedrock also allows you to build applications that are in compliance with the GDPR and you can use Amazon Bedrock to run sensitive workloads regulated under the U.S. Health Insurance Portability and Accountability Act (HIPAA).
Get Started with Amazon Bedrock You can access available FMs in Amazon Bedrock through the AWS Management Console,AWS SDKs, and open-source frameworks such as LangChain.
In the Amazon Bedrock console, you can browse FMs and explore and load example use cases and prompts for each model. First, you need to enable access to the models. In the console, select Model access in the left navigation pane and enable the models you would like to access. Once model access is enabled, you can try out different models and inference configuration settings to find a model that fits your use case.
For example, here’s a contract entity extraction use case example using Cohere’s Command model:
The example shows a prompt with a sample response, the inference configuration parameter settings for the example, and the API request that runs the example. If you select Open in Playground, you can explore the model and use case further in an interactive console experience.
Amazon Bedrock offers chat, text, and image model playgrounds. In the chat playground, you can experiment with various FMs using a conversational chat interface. The following example uses Anthropic’s Claude model:
As you evaluate different models, you should try various prompt engineering techniques and inference configuration parameters. Prompt engineering is a new and exciting skill focused on how to better understand and apply FMs to your tasks and use cases. Effective prompt engineering is about crafting the perfect query to get the most out of FMs and obtain proper and precise responses. In general, prompts should be simple, straightforward, and avoid ambiguity. You can also provide examples in the prompt or encourage the model to reason through more complex tasks.
Inference configuration parameters influence the response generated by the model. Parameters such as Temperature, Top P, and Top K give you control over the randomness and diversity, and Maximum Length or Max Tokens control the length of model responses. Note that each model exposes a different but often overlapping set of inference parameters. These parameters are either named the same between models or similar enough to reason through when you try out different models.
We discuss effective prompt engineering techniques and inference configuration parameters in more detail in week 1 of the Generative AI with Large Language Models on-demand course, developed by AWS in collaboration with DeepLearning.AI. You can also check the Amazon Bedrock documentation and the model provider’s respective documentation for additional tips.
Next, let’s see how you can interact with Amazon Bedrock via APIs.
Using the Amazon Bedrock API Working with Amazon Bedrock is as simple as selecting an FM for your use case and then making a few API calls. In the following code examples, I’ll use the AWS SDK for Python (Boto3) to interact with Amazon Bedrock.
List Available Foundation Models First, let’s set up the boto3 client and then use list_foundation_models() to see the most up-to-date list of available FMs:
Run Inference Using Amazon Bedrock’s InvokeModel API Next, let’s perform an inference request using Amazon Bedrock’s InvokeModel API and boto3 runtime client. The runtime client manages the data plane APIs, including the InvokeModel API.
The InvokeModel API expects the following parameters:
The modelId parameter identifies the FM you want to use. The request body is a JSON string containing the prompt for your task, together with any inference configuration parameters. Note that the prompt format will vary based on the selected model provider and FM. The contentType and accept parameters define the MIME type of the data in the request body and response and default to application/json. For more information on the latest models, InvokeModel API parameters, and prompt formats, see the Amazon Bedrock documentation.
Example: Text Generation Using AI21 Lab’s Jurassic-2 Model Here is a text generation example using AI21 Lab’s Jurassic-2 Ultra model. I’ll ask the model to tell me a knock-knock joke—my version of a Hello World.
Who's there?
Boo!
Boo who?
Don't cry, it's just a joke!
You can also use the InvokeModel API to interact with embedding models.
Example: Create Text Embeddings Using Amazon’s Titan Embeddings Model Text embedding models translate text inputs, such as words, phrases, or possibly large units of text, into numerical representations, known as embedding vectors. Embedding vectors capture the semantic meaning of the text in a high-dimension vector space and are useful for applications such as personalization or search. In the following example, I’m using the Amazon Titan Embeddings model to create an embedding vector.
Note that Amazon Titan Embeddings is available today. The Amazon Titan Text family of models for text generation continues to be available in limited preview.
Run Inference Using Amazon Bedrock’s InvokeModelWithResponseStream API The InvokeModel API request is synchronous and waits for the entire output to be generated by the model. For models that support streaming responses, Bedrock also offers an InvokeModelWithResponseStream API that lets you invoke the specified model to run inference using the provided input but streams the response as the model generates the output.
Streaming responses are particularly useful for responsive chat interfaces to keep the user engaged in an interactive application. Here is a Python code example using Amazon Bedrock’s InvokeModelWithResponseStream API:
response = bedrock_runtime.invoke_model_with_response_stream(
modelId=modelId,
body=body)
stream = response.get('body')
if stream:
for event in stream:
chunk=event.get('chunk')
if chunk:
print(json.loads(chunk.get('bytes').decode))
Data Privacy and Network Security With Amazon Bedrock, you are in control of your data, and all your inputs and customizations remain private to your AWS account. Your data, such as prompts, completions, and fine-tuned models, is not used for service improvement. Also, the data is never shared with third-party model providers.
Your data remains in the Region where the API call is processed. All data is encrypted in transit with a minimum of TLS 1.2 encryption. Data at rest is encrypted with AES-256 using AWS KMS managed data encryption keys. You can also use your own keys (customer managed keys) to encrypt the data.
You can configure your AWS account and virtual private cloud (VPC) to use Amazon VPC endpoints (built on AWS PrivateLink) to securely connect to Amazon Bedrock over the AWS network. This allows for secure and private connectivity between your applications running in a VPC and Amazon Bedrock.
Governance and Monitoring Amazon Bedrock integrates with IAM to help you manage permissions for Amazon Bedrock. Such permissions include access to specific models, playground, or features within Amazon Bedrock. All AWS-managed service API activity, including Amazon Bedrock activity, is logged to CloudTrail within your account.
Amazon Bedrock emits data points to CloudWatch using the AWS/Bedrock namespace to track common metrics such as InputTokenCount, OutputTokenCount, InvocationLatency, and (number of) Invocations. You can filter results and get statistics for a specific model by specifying the model ID dimension when you search for metrics. This near real-time insight helps you track usage and cost (input and output token count) and troubleshoot performance issues (invocation latency and number of invocations) as you start building generative AI applications with Amazon Bedrock.
Billing and Pricing Models Here are a couple of things around billing and pricing models to keep in mind when using Amazon Bedrock:
Billing – Text generation models are billed per processed input tokens and per generated output tokens. Text embedding models are billed per processed input tokens. Image generation models are billed per generated image.
Pricing Models – Amazon Bedrock offers two pricing models, on-demand and provisioned throughput. On-demand pricing allows you to use FMs on a pay-as-you-go basis without having to make any time-based term commitments. Provisioned throughput is primarily designed for large, consistent inference workloads that need guaranteed throughput in exchange for a term commitment. Here, you specify the number of model units of a particular FM to meet your application’s performance requirements as defined by the maximum number of input and output tokens processed per minute. For detailed pricing information, see Amazon Bedrock Pricing.
(Available in Preview) The Amazon Titan Text family of text generation models, Stability AI’s Stable Diffusion XL image generation model, and agents for Amazon Bedrock, including knowledge bases, continue to be available in preview. Reach out through your usual AWS contacts if you’d like access.
(Coming Soon) The Llama 2 13B and 70B parameter models by Meta will soon be available via Amazon Bedrock’s fully managed API for inference and fine-tuning.
Hyperdrive vous permet d’accéder très rapidement à vos bases de données existantes à partir de Cloudflare Workers, quel que soit leur lieu d’exécution. Il vous suffit de connecter Hyperdrive à votre base de données, de modifier une ligne de code pour vous connecter via Hyperdrive, et voilà : les connexions et les requêtes sont accélérées (et spoiler : vous pouvez l’utiliser dès aujourd’hui).
En un mot, Hyperdrive s’appuie sur notre réseau mondial pour accélérer les requêtes vers vos bases de données existantes, qu’elles se situent chez un fournisseur de cloud traditionnel ou chez votre fournisseur de base de données serverless préféré. La solution réduit considérablement la latence induite par l’établissement répété de nouvelles connexions avec la base de données. En outre, elle met en cache les requêtes de lecture les plus populaires adressées à votre base de données, une opération qui évite souvent d’avoir à s’adresser à nouveau à votre base de données.
Sans Hyperdrive, l’accès à votre base de données principale (celle qui contient les profils de vos utilisateurs, votre stock de produits ou qui exécute votre application web essentielle) hébergée dans la région us-east1 d’un fournisseur de cloud traditionnel se révèlera très lent pour les utilisateurs situés à Paris, Singapour et Dubaï, et plus lent qu’il ne devrait l’être pour les utilisateurs de Los Angeles ou de Vancouver. Chaque aller-retour pouvant prendre jusqu’à 200 ms, il est facile de perdre jusqu’à une seconde (ou plus !) lors des nombreux allers-retours nécessaires à l’établissement d’une connexion, avant même d’avoir envoyé la requête visant à récupérer vos données. Le service Hyperdrive est conçu pour remédier à cette situation.
Pour démontrer les performances d’Hyperdrive, nous avons développé une application de démonstration qui envoie des requêtes consécutives à la même base de données : à la fois avec Hyperdrive et sans Hyperdrive (directement donc). L’application commence par sélectionner une base de données située dans un continent voisin : elle sélectionne ainsi une base de données hébergée aux États-Unis si vous vous trouvez en Europe, par exemple (une expérience bien trop courante pour de nombreux internautes européens). De même, si vous vous trouvez en Afrique, elle sélectionnera une base de données située en Europe (et ainsi de suite). Elle renvoie ensuite les résultats bruts d’une requête « SELECT » simple, sans moyennes ni indicateurs choisis avec soin.
Tout au long de la phase de tests internes, les premiers rapports d’utilisateurs et les multiples tests d’évaluation réalisés révèlent qu’Hyperdrive améliore les performances de 17 à 25 fois par rapport à l’accès direct à la base de données pour les requêtes en cache, et de 6 à 8 fois pour les requêtes et les opérations d’écriture non mises en cache. La latence de la mise en cache ne vous surprendra peut-être pas, mais nous pensons que le fait d’accélérer 6 à 8 fois les requêtes non mises en cache vous fera changer d’idée, en passant de « Je ne peux pas interroger une base de données centralisée à partir de Cloudflare Workers » à « Mais où te cachais-tu, fonctionnalité de mes rêves ?! ». Nous continuons également à travailler sur l’amélioration des performances. Nous avons déjà identifié des économies supplémentaires en termes de latence et les mettrons en œuvre dans les semaines à venir.
Le plus beau dans tout ça ? Les développeurs titulaires d’une offre Workers payante peuvent commencer à utiliser immédiatement la bêta ouverte d’Hyperdrive : pas besoin de s’inscrire sur une liste d’attente ni de parcourir de formulaires d’inscription spéciaux.
Hyperdrive ? Vous n’en avez jamais entendu parler ?
Nous travaillons sur Hyperdrive en secret depuis quelque temps, mais le fait de permettre aux développeurs de se connecter aux bases de données dont ils disposent déjà (avec leurs données, leurs requêtes et leurs outils existants) nous trotte dans la tête depuis un bon moment.
Dans un environnement cloud distribué moderne comme Workers, au sein duquel les calculs sont distribués à l’échelle mondiale (ils sont donc effectués à proximité des utilisateurs) et les fonctions de courte durée (afin de ne pas être facturé plus que nécessaire), la connexion aux bases de données traditionnelles se montre à la fois lente et non évolutive. Lente, parce qu’il faut plus de sept allers-retours (négociation TCP, négociation TLS, authentification) pour établir la connexion et non évolutive, car les bases de données telles que PostgreSQL présentent un coût en ressources par connexion plutôt élevé. Même quelques centaines de connexions à une base de données peuvent consommer une quantité importante de mémoire, indépendamment de la mémoire nécessaire pour les requêtes.
Nos amis chez Neon (un fournisseur populaire de bases de données Postgres serverless) ont d’ailleurs écrit à ce sujet. Ils ont même lancé un proxy et un pilote WebSocket permettant de réduire la surcharge de connexion, mais ils ont toujours du mal à se sortir de l’ornière. Même avec un pilote personnalisé, nous en sommes à 4 allers-retours, chacun demandant potentiellement 50 à 200 millisecondes, voire plus. Ce délai ne pose aucun problème lorsque les connexions sont de longue durée (il surviendra une fois toutes les quelques heures au mieux), mais lorsque ces connexions se limitent à une invocation de fonction individuelle et qu’elles ne restent donc utiles que pendant quelques millisecondes ou quelques minutes, votre code passe plus de temps à attendre. Il s’agit en fait d’une autre sorte de démarrage à froid. Le fait d’avoir à établir une nouvelle connexion avec votre base de données avant d’envoyer une requête implique que l’utilisation d’une base de données traditionnelle au sein d’un environnement distribué ou serverless sera vraiment lente (pour le dire gentiment).
Pour remédier à ce problème, la solution Hyperdrive accomplit deux tâches.
Tout d’abord, elle entretient un ensemble de pools de connexions avec des bases de données régionales via le réseau Cloudflare, de sorte qu’un Worker Cloudflare puisse éviter d’établir une nouvelle connexion à une base de données pour chaque requête. À la place, le Worker peut établir une connexion à Hyperdrive (une opération des plus rapides !), car Hyperdrive dispose d’un pool de connexions prêtes à l’emploi vers la base de données. Comme une base de données peut être distante de 30 ms à (bien souvent) 300 ms lors d’un unique aller-retour (sans parler des sept ou plus dont vous avez besoin pour établir une nouvelle connexion), le fait de disposer d’un pool de connexions disponibles réduit considérablement le problème de latence dont souffriraient autrement les connexions de courte durée.
Ensuite, la solution comprend la différence entre les requêtes et les transactions de lecture (non mutantes) et d’écriture (mutantes). Elle peut ainsi mettre automatiquement en cache vos requêtes de lecture les plus populaires, qui représentent plus de 80 % de l’ensemble des requêtes adressées aux bases de données au sein des applications web typiques. Il peut, par exemple, s’agir de cette liste de produits que des dizaines de milliers d’utilisateurs visitent chaque heure, des annonces publiées sur un grand site d’offres d’emploi, voire de requêtes visant des données de configuration qui changent de temps en temps. Une grande partie des ressources visées par les requêtes des utilisateurs ne changent pas souvent et le fait de les mettre en cache à proximité de l’endroit d’où l’utilisateur envoie sa requête peut accélérer considérablement l’accès à ces données pour les dix mille utilisateurs suivants. Les requêtes d’écriture, qui ne peuvent pas être réellement mises en cache de manière sûre, bénéficient toujours des pools de connexions entretenus par Hyperdrive et du réseau mondial de Cloudflare. La possibilité d’emprunter les itinéraires les plus rapides sur Internet via notre infrastructure permet là aussi de réduire la latence.
Même si votre base de données se situe à l’autre bout du pays, 70 ms × 6 allers-retours, c’est beaucoup de temps pour un utilisateur qui attend une réponse à une requête.
Hyperdrive fonctionne non seulement avec les bases de données PostgreSQL (dont celles de Neon, de Google Cloud SQL, d’AWS RDS, et de Timescale), mais aussi avec les bases de données compatibles PostgreSQL, comme Materialize (une puissante base de données de traitement de flux), CockroachDB (une des principales bases de données distribuées), AlloyDB de Google Cloud, et Aurora Postgres d’AWS.
Nous travaillons également à la prise en charge de MySQL, notamment avec des fournisseurs comme PlanetScale, d’ici la fin de l’année. D’autres moteurs de base de données sont prévus par la suite.
La chaîne de connexion magique
L’un des principaux objectifs à l’origine de la conception d’Hyperdrive était de permettre aux développeurs de continuer à utiliser leurs outils existants, comme leurs pilotes, leurs générateurs de requêtes et leurs bibliothèques ORM (Object-Relational Mapper, mappeur objet-relationnel). La rapidité d’Hyperdrive n’aurait pas d’importance si nous vous avions demandé d’abandonner votre bibliothèque ORM préférée et/ou de réécrire des centaines (ou plus) de lignes de code et de tests pour bénéficier des performances de notre solution.
Pour ce faire, nous avons travaillé avec des éditeurs de pilotes open-source bien connus (notamment node-postgres et Postgres.js) afin d’aider leurs bibliothèques à prendre en charge la nouvelle API Socket TCP de Workers, qui est en cours de normalisation, et que nous espérons voir arriver dans Node.js, Deno et Bun également.
Langage partagé par les pilotes de base de données, la simple chaîne de connexion à la base de données se présente généralement ainsi :
La magie d’Hyperdrive réside dans le fait que vous pouvez commencer à l’utiliser dans vos applications Workers existantes, avec vos requêtes existantes, en remplaçant simplement votre chaîne de connexion par celle générée par Hyperdrive.
Création d’un Hyperdrive
Avec une base de données existante prête à l’emploi (dans cet exemple, nous utiliserons une base de données Postgres de Neon), il suffit de moins d’une minute pour faire fonctionner Hyperdrive (oui, nous avons chronométré le temps nécessaire).
Si vous ne disposez pas d’un projet Cloudflare Workers existant, vous pouvez rapidement en créer un :
$ npm create cloudflare@latest
# Call the application "hyperdrive-demo"
# Choose "Hello World Worker" as your template
À partir de là, nous avons juste besoin de la chaîne de connexion à notre base de données et d’une invocation rapide de la ligne de commande wrangler pour qu’Hyperdrive s’y connecte.
# Using wrangler v3.10.0 or above
wrangler hyperdrive create a-faster-database --connection-string="postgres://user:[email protected]:5432/neondb"
# This will return an ID: we'll use this in the next step
[[hyperdrive]]
name = "HYPERDRIVE"
id = "cdb28782-0dfc-4aca-a445-a2c318fb26fd"
Nous pouvons maintenant écrire un Worker (ou employer un script Worker existant) et utiliser Hyperdrive pour accélérer les connexions et les requêtes à notre base de données existante. Nous utilisons ici node-postgres, mais nous pourrions tout aussi bien utiliser Drizzle ORM.
import { Client } from 'pg';
export interface Env {
HYPERDRIVE: Hyperdrive;
}
export default {
async fetch(request: Request, env: Env, ctx: ExecutionContext) {
console.log(JSON.stringify(env));
// Create a database client that connects to our database via Hyperdrive
//
// Hyperdrive generates a unique connection string you can pass to
// supported drivers, including node-postgres, Postgres.js, and the many
// ORMs and query builders that use these drivers.
const client = new Client({ connectionString: env.HYPERDRIVE.connectionString });
try {
// Connect to our database
await client.connect();
// A very simple test query
let result = await client.query({ text: 'SELECT * FROM pg_tables' });
// Return our result rows as JSON
return Response.json({ result: result });
} catch (e) {
console.log(e);
return Response.json({ error: JSON.stringify(e) }, { status: 500 });
}
},
};
Le code ci-dessus est intentionnellement simple, mais j’espère que vous pouvez en voir la magie : notre pilote de base de données reçoit ainsi une chaîne de connexion d’Hyperdrive et reste indifférent. Il n’a pas besoin de connaître Hyperdrive, nous n’avons pas besoin de nous débarrasser de notre bibliothèque de génération de requêtes préférée et nous pouvons immédiatement réaliser les avantages en termes de rapidité lorsque nous envoyons des requêtes.
Les connexions sont automatiquement mises en commun et conservées, nos requêtes les plus populaires sont mises en cache et l’ensemble de notre application s’en trouve accélérée.
Nous considérons Hyperdrive comme un outil essentiel pour accéder à vos bases de données existantes lorsque vous développez sur Cloudflare Workers. Les bases de données traditionnelles n’ont tout simplement pas été conçues pour un monde dans lequel les clients sont distribués à l’échelle mondiale.
La mise en commun des connexions par Hyperdrive sous forme de pools sera toujours gratuite, à la fois pour les protocoles de base de données que nous prenons en charge aujourd’hui et pour les nouveaux protocoles que nous ajouterons à l’avenir. Tout comme pour notre service de protection contre les attaques DDoS et notre réseau CDN mondial, nous pensons que l’accès aux fonctionnalités principales d’Hyperdrive est trop utile pour être limité.
L’utilisation d’Hyperdrive ne sera pas facturée pendant la bêta ouverte, quelle que soit la manière dont vous vous en servez. Nous vous donnerons plus de détails sur la tarification d’Hyperdrive à l’approche de son lancement (début 2024), et ce bien à l’avance.
Le moment des questions
Quel est l’avenir pour Hyperdrive ?
Nous prévoyons de mettre Hyperdrive en disponibilité générale au début de l’année 2024 et nous concentrons actuellement sur la mise en place de davantage de mesures de contrôle sur la manière dont nous mettons en cache et invalidons automatiquement les ressources en nous appuyant sur les analyses des opérations d’écriture, des requêtes détaillées et des performances (bientôt !). Nous prévoyons aussi de prendre en charge davantage de moteurs de base de données (dont MySQL), tout en poursuivant nos travaux visant à rendre la solution encore plus rapide.
Nous travaillons également à la mise en place d’une connectivité réseau privée via Magic WAN et Cloudflare Tunnel, afin de vous permettre de vous connecter à des bases de données non exposées à l’Internet public (ou qui ne peuvent pas l’être). Pour connecter Hyperdrive à votre base de données existante, rendez-vous dans nos documents pour les développeurs. Il suffit de moins d’une minute pour créer un Hyperdrive et mettre à jour le code existant afin de pouvoir utiliser la solution. Rejoignez le canal #hyperdrive-beta de notre Discord pour développeurs si vous souhaitez poser des questions, signaler des bugs et discuter directement avec notre équipe produits et notre équipe technique.
Hyperdrive macht den Zugriff auf Ihre bestehenden Datenbanken von Cloudflare Workers aus hyperschnell, egal wo sie laufen. Sie verbinden Hyperdrive mit Ihrer Datenbank, ändern eine Codezeile, um eine Verbindung über Hyperdrive herzustellen, und voilà: Verbindungen und Abfragen werden schneller (und Spoiler: Sie können es schon heute nutzen).
Kurz gesagt: Hyperdrive nutzt unser globales Netzwerk, um Abfragen an Ihre bestehenden Datenbanken zu beschleunigen, unabhängig davon, ob sich diese bei einem alten Cloud-Provider oder bei Ihrem bevorzugten Provider für Serverless-Datenbanken befinden. Die Latenz, die durch das wiederholte Einrichten neuer Datenbankverbindungen entsteht, wird drastisch reduziert, und die beliebtesten Leseabfragen an Ihre Datenbank werden zwischengespeichert, sodass Sie oft gar nicht mehr zu Ihrer Datenbank zurückkehren müssen.
Wenn Ihre Kerndatenbank – mit Ihren Nutzerprofilen, Ihrem Produktbestand oder Ihrer wichtigen Web-App – in der us-east1-Region eines veralteten Cloud-Anbieters angesiedelt ist, wird der Zugriff für Nutzende in Paris, Singapur und Dubai ohne Hyperdrive sehr langsam sein und selbst für Nutzende in Los Angeles oder Vancouver langsamer, als er sein sollte. Da jeder Roundtrip bis zu 200 ms dauert, können die mehrfachen Roundtrips, die allein für den Verbindungsaufbau erforderlich sind, leicht bis zu einer Sekunde (oder mehr!) in Anspruch nehmen; und das, bevor Sie überhaupt eine Abfrage für Ihre Daten gemacht haben. Hyperdrive soll dieses Problem lösen.
Um die Performance von Hyperdrive zu demonstrieren, haben wir eine Demo-Anwendung erstellt, die Abfragen gegen dieselbe Datenbank durchführt: sowohl mit Hyperdrive als auch ohne Hyperdrive (direkt). Die App wählt eine Datenbank in einem Nachbarkontinent aus: Wenn Sie sich in Europa befinden, wählt sie eine Datenbank in den USA – etwas, das europäische Nutzende allzu häufig erleben – und wenn Sie sich in Afrika befinden, wählt sie eine Datenbank in Europa (und so weiter). Sie erhalten die Rohdaten einer einfachen SELECT-Abfrage, ohne sorgfältig ausgewählte Durchschnittswerte oder herausgepickte Metriken.
Wir haben eine Demo-App entwickelt, die echte Abfragen an eine PostgreSQL-Datenbank stellt, mit und ohne Hyperdrive.
Bei internen Tests, ersten Berichten von Nutzenden und mehreren Durchläufen in unserem Benchmark erzielte Hyperdrive bei gecachten Abfragen eine 17- bis 25-fache Performance-Verbesserung im Vergleich zur direkten Abfrage der Datenbank und eine sechs- bis achtfache Verbesserung bei ungecachten Abfragen und Schreibvorgängen. Die gecachte Latenz wird Sie vielleicht nicht überraschen, aber wir sind der Meinung, dass die sechs- bis achtfache Verbesserung bei nicht gecachten Abfragen aus „Ich kann keine zentralisierte Datenbank von Cloudflare Workers aus abfragen“ in „Wie bin ich nur solange ohne diese Möglichkeit ausgekommen?!“ verwandelt. Wir arbeiten auch weiterhin an der Verbesserung der Performance: Wir haben bereits weitere Einsparungen bei der Latenz festgestellt und werden diese in den kommenden Wochen veröffentlichen.
Wir arbeiten seit einiger Zeit im Verborgenen an Hyperdrive. Aber die Möglichkeit für Entwicklungsteams, sich mit bereits vorhandenen Datenbanken zu verbinden – mit ihren bestehenden Daten, Abfragen und Werkzeugen – beschäftigt uns schon seit geraumer Zeit.
In einer modernen verteilten Cloud-Umgebung wie der von Workers, in der die Rechenleistung global verteilt ist (also in der Nähe der Nutzenden) und die Funktionen kurzlebig sind (sodass nicht mehr als nötig in Rechnung gestellt wird), war die Verbindung zu herkömmlichen Datenbanken sowohl langsam als auch nicht skalierbar. Langsam, weil es für den Verbindungsaufbau mehr als sieben Runden braucht (TCP-Handshake, TLS-Verhandlung und Autorisierung). Und nicht skalierbar, weil Datenbanken wie PostgreSQL hohe Ressourcenkosten pro Verbindung verursachen. Schon einige hundert Verbindungen zu einer Datenbank können einen nicht zu unterschätzenden Arbeitsspeicher verbrauchen – den für die Abfragen benötigten Arbeitsspeicher nicht mitgerechnet.
Unsere Freunde bei Neon (einem beliebten Serverless Postgres-Provider) haben darüber geschrieben und sogar einen WebSocket-Proxy und -Treiber veröffentlicht, um den Verbindungsaufwand zu reduzieren. Aber sie haben trotzdem zu kämpfen: Selbst mit einem benutzerdefinierten Treiber sind wir bei vier Roundtrips, die jeweils 50–200 Millisekunden oder mehr dauern können. Wenn diese Verbindungen langlebig sind, ist das in Ordnung – es kann bestenfalls einmal alle paar Stunden passieren. Aber wenn sie auf einen einzelnen Funktionsaufruf beschränkt sind und nur wenige Millisekunden bis bestenfalls Minuten von Nutzen sind, verbringt Ihr Code mehr Zeit mit Warten. Das ist praktisch eine andere Art von Kaltstart: Da Sie vor einer Abfrage eine neue Verbindung zu Ihrer Datenbank herstellen müssen, ist die Verwendung einer herkömmlichen Datenbank in einer verteilten oder serverlosen Umgebung (vorsichtig ausgedrückt) sehr langsam.
Um dies zu verhindern, macht Hyperdrive zweierlei.
Erstens unterhält es eine Reihe regionaler Datenbankverbindungspools im gesamten Cloudflare-Netzwerk, sodass ein Cloudflare Worker nicht bei jeder Anfrage eine neue Verbindung zu einer Datenbank herstellen muss. Stattdessen kann der Worker eine Verbindung zu Hyperdrive herstellen (schnell!), wobei Hyperdrive einen Pool von einsatzbereiten Verbindungen zurück zur Datenbank unterhält. Da eine Datenbank bei einem einzigen Roundtrip zwischen 30 ms und (oft) 300 ms entfernt sein kann (ganz zu schweigen von den sieben Roundtrips oder mehr, die Sie für eine neue Verbindung benötigen), reduziert ein Pool verfügbarer Verbindungen das Latenzproblem, das bei kurzlebigen Verbindungen sonst auftreten würde, drastisch.
Zweitens versteht es den Unterschied zwischen lesenden (nicht verändernden) und schreibenden (verändernden) Abfragen und Transaktionen und kann Ihre beliebtesten lesenden Abfragen automatisch zwischenspeichern: Diese machen über 80 % der meisten Abfragen aus, die in typischen Webanwendungen an Datenbanken gestellt werden. Die Seite mit den Produktangeboten, die stündlich von Zehntausenden besucht wird, offene Stellen auf einer renommierten Karriereseite oder auch Abfragen von Konfigurationsdaten, die sich gelegentlich ändern. Ein Großteil der abgefragten Daten ändert sich nicht oft, und das Cachen dieser Daten in der Nähe des Ortes, von dem ein Nutzender sie abfragt, kann den Zugriff auf diese Daten für die nächsten zehntausend Nutzenden dramatisch beschleunigen. Schreibabfragen, die nicht sicher zwischengespeichert werden können, profitieren dennoch sowohl vom Verbindungspooling von Hyperdrive als auch vom globalen Netzwerk von Cloudflare: Da wir über unser Backbone die schnellsten Routen durch das Internet nehmen können, wird auch hier die Latenz reduziert.
Selbst wenn sich Ihre Datenbank auf der anderen Seite des Landes befindet, sind 70 ms x 6 Roundtrips eine Menge Zeit für Nutzende, die auf eine Antwort auf ihre Abfrage warten.
Hyperdrive funktioniert nicht nur mit PostgreSQL-Datenbanken – einschließlich Neon, Google Cloud SQL, AWS RDS und Timescale – sondern auch mit PostgreSQL-kompatiblen Datenbanken wie Materialize (einer leistungsstarken Stream-Processing-Datenbank), CockroachDB (einer großen verteilten Datenbank), AlloyDB von Google Cloud und AWS Aurora Postgres.
Wir arbeiten außerdem daran, bis zum Ende des Jahres Unterstützung für MySQL, einschließlich Providern wie PlanetScale, zu bieten, und planen für die Zukunft die Unterstützung weiterer Datenbank-Engines.
Der magische Verbindungsstring
Eines der wichtigsten Ziele bei der Entwicklung von Hyperdrive war, dass die Entwicklungsteams ihre bestehenden Treiber, Abfrage-Builder und ORM-Bibliotheken (Object-Relational Mapper) weiter verwenden können. Es wäre egal gewesen, wie schnell Hyperdrive ist, wenn wir von Ihnen verlangt hätten, von Ihrem bevorzugten ORM zu migrieren und/oder Hunderte (oder mehr) von Codezeilen und Tests neu zu schreiben, um von der Performance von Hyperdrive zu profitieren.
Um dies zu erreichen, haben wir mit den Betreuenden beliebter Open-Source-Treiber – einschließlich node-postgres und Postgres.js – zusammengearbeitet, damit ihre Bibliotheken die neue TCP-Socket-API von Workers unterstützen, die derzeit den Standardisierungsprozess durchläuft, und wir erwarten, dass sie auch in Node.js, Deno und Bun Einzug halten wird.
Der einfache Datenbankverbindungsstring ist die gemeinsame Sprache der Datenbanktreiber und hat normalerweise dieses Format:
Der Zauber von Hyperdrive besteht darin, dass Sie es in Ihren bestehenden Workers-Anwendungen mit Ihren bestehenden Abfragen einsetzen können, indem Sie einfach Ihren Verbindungsstring gegen den von Hyperdrive generierten austauschen.
Hyperdrive erstellen
Mit einer vorhandenen Datenbank – in diesem Beispiel verwenden wir eine Postgres-Datenbank von Neon – dauert es weniger als eine Minute, um Hyperdrive zum Laufen zu bringen (ja, wir haben die Zeit gemessen).
Wenn Sie kein bestehendes Cloudflare Workers-Projekt haben, können Sie schnell eines erstellen:
$ npm create cloudflare@latest
# Call the application "hyperdrive-demo"
# Choose "Hello World Worker" as your template
Von hier aus brauchen wir nur noch den Datenbankverbindungsstring für unsere Datenbank und einen kurzen Wrangler-Befehlszeilenaufruf, damit Hyperdrive sich mit ihr verbindet.
# Using wrangler v3.10.0 or above
wrangler hyperdrive create a-faster-database --connection-string="postgres://user:[email protected]:5432/neondb"
# This will return an ID: we'll use this in the next step
[[hyperdrive]]
name = "HYPERDRIVE"
id = "cdb28782-0dfc-4aca-a445-a2c318fb26fd"
Wir können nun einen Worker schreiben – oder ein bestehendes Worker-Skript nehmen – und Hyperdrive verwenden, um Verbindungen und Abfragen zu unserer bestehenden Datenbank zu beschleunigen. Wir verwenden hier node-postgres, aber wir könnten genauso gut Drizzle ORM nutzen.
import { Client } from 'pg';
export interface Env {
HYPERDRIVE: Hyperdrive;
}
export default {
async fetch(request: Request, env: Env, ctx: ExecutionContext) {
console.log(JSON.stringify(env));
// Create a database client that connects to our database via Hyperdrive
//
// Hyperdrive generates a unique connection string you can pass to
// supported drivers, including node-postgres, Postgres.js, and the many
// ORMs and query builders that use these drivers.
const client = new Client({ connectionString: env.HYPERDRIVE.connectionString });
try {
// Connect to our database
await client.connect();
// A very simple test query
let result = await client.query({ text: 'SELECT * FROM pg_tables' });
// Return our result rows as JSON
return Response.json({ result: result });
} catch (e) {
console.log(e);
return Response.json({ error: JSON.stringify(e) }, { status: 500 });
}
},
};
Der obige Code ist absichtlich einfach gehalten, aber die Magie ist hoffentlich nachvollziehbar: Unser Datenbanktreiber erhält einen Verbindungsstring von Hyperdrive und ist dabei völlig ahnungslos. Er muss nichts über Hyperdrive wissen, wir müssen unsere Lieblingsbibliothek für Abfrageerstellung nicht über Bord werfen und wir profitieren sofort von den Geschwindigkeitsvorteilen bei Abfragen.
Verbindungen werden automatisch gepoolt und warmgehalten, unsere beliebtesten Abfragen werden gecacht, und unsere gesamte Anwendung wird schneller.
Wir haben auch Leitfäden für alle wichtigen Datenbank-Provider erstellt, damit Sie das, was Sie von diesen Providern benötigen (einen Verbindungsstring), ganz einfach in Hyperdrive übertragen können.
Schnelles Tempo kann nicht günstig sein, oder?
Wir sind der Meinung, dass Hyperdrive für den Zugriff auf Ihre bestehenden Datenbanken entscheidend ist, wenn Sie auf Cloudflare Workers entwickeln: Herkömmliche Datenbanken wurden einfach nie für eine Welt entwickelt, in der Clients global verteilt sind.
Das Verbindungspooling von Hyperdrive wird immer kostenlos sein, sowohl für Datenbankprotokolle, die wir heute unterstützen, als auch für neue Datenbankprotokolle, die wir in Zukunft hinzufügen werden. Genau wie der DDoS-Schutz und unser globales CDN sind wir der Meinung, dass der Zugang zum Kernfeature von Hyperdrive zu nützlich ist, um ihn zurückzuhalten.
Während der offenen Beta-Phase wird Hyperdrive selbst keine Gebühren für die Nutzung erheben, unabhängig davon, wie Sie es verwenden. Weitere Details zur Preisgestaltung von Hyperdrive werden wir rechtzeitig vor der allgemeinen Freigabe (Anfang 2024) bekannt geben.
Zeit für eine Abfrage
Wie geht es nun mit Hyperdrive weiter?
Wir planen, Hyperdrive Anfang 2024 auf den Markt zu bringen – und arbeiten an mehr Kontrolle über das Caching und die automatische Invalidierung auf der Grundlage von Schreibvorgängen, detaillierten Abfrage- und Performance-Analytics (bald!), Unterstützung für weitere Datenbank-Engines (einschließlich MySQL) und möchten die Geschwindigkeit weiter ankurbeln.
Wir arbeiten auch daran, die Verbindung zu privaten Netzwerken über Magic WAN und Cloudflare Tunneling zu ermöglichen, sodass Sie auf Datenbanken zugreifen können, die nicht im öffentlichen Internet zugänglich sind (oder sein können).
Um Hyperdrive mit Ihrer bestehenden Datenbank zu verbinden, besuchen Sie unsere Dokumentation für die Entwicklung. Es dauert weniger als eine Minute, um einen Hyperdrive zu erstellen und bestehenden Code zu aktualisieren, um ihn zu verwenden. Treten Sie dem Kanal #hyperdrive-beta in unserem Entwicklungs-Discord bei, um Fragen zu stellen, Fehler zu melden und direkt mit unseren Produkt- und Entwicklungsteams zu sprechen.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Florian Mair is a Senior Solutions Architect and data streaming expert at AWS. He is a technologist that helps customers in Germany succeed and innovate by solving business challenges using AWS Cloud services. Besides working as a Solutions Architect, Florian is a passionate mountaineer, and has climbed some of the highest mountains across Europe.
Benjamin Meyer is a Senior Solutions Architect at AWS, focused on Games businesses in Germany to solve business challenges by using AWS Cloud services. Benjamin has been an avid technologist for 7 years, and when he’s not helping customers, he can be found developing mobile apps, building electronics, or tending to his cacti.
