Amazon Kendra — снова случай из серии «это, вероятно, чей-то настроенный инструмент», как уже разбиралось с MainWP, Silktide и ActiveComply, только здесь это конкретный компонент AWS: коннектор Web Crawler сервиса корпоративного поиска Amazon Kendra. Он не бродит по вебу самостоятельно — его запускает конкретный клиент AWS, который явно указал ваш сайт как источник данных для своего поискового индекса.
1. Что такое Amazon Kendra на самом деле
Amazon Kendra — «интеллектуальный» сервис корпоративного поиска на базе машинного обучения от AWS: он извлекает точные ответы из документов организации с указанием источника и уровня уверенности, а не просто выдаёт список ссылок по ключевым словам. Чтобы наполнить поисковый индекс, Kendra поддерживает более 14 коннекторов источников данных — Amazon S3, SharePoint, Confluence, Salesforce, Jira и другие — и один из них называется Web Crawler.
Ключевой момент: коннектор Web Crawler не обходит интернет произвольно. Клиент AWS сам создаёт индекс Kendra, добавляет источник данных типа «Web Crawler», указывает конкретные seed-URL или sitemap для обхода, настраивает глубину обхода, максимальное число ссылок на странице и лимиты троттлинга. Обход при этом ограничен только HTTPS-сайтами — публичными или внутренними (интранет) сайтами организации, к которым у неё есть право доступа.
| Параметр | Значение |
| Название | Amazon Kendra (коннектор Web Crawler) |
| Оператор | Amazon (AWS) — официально задокументированный сервис корпоративного поиска, конкретную конфигурацию обхода задаёт клиент AWS |
| Роль | Индексация страниц конкретных сайтов, явно указанных клиентом AWS, для построения его собственного корпоративного поискового индекса |
| User-Agent / паттерн | amazon-kendra |
| Кто обычно инициирует | Конкретный клиент AWS, настроивший индекс Kendra и добавивший ваш сайт как seed-URL или sitemap источника Web Crawler |
| Параметры обхода | Полностью настраиваются клиентом: диапазон обхода, глубина, ограничение ссылок на странице, троттлинг — версии коннектора v1.0 и v2.0 имеют разный набор поддерживаемых функций |
| Ограничение по протоколу | Только HTTPS-сайты — публичные или внутренние (интранет) с соответствующим правом доступа |
| robots.txt | Прямых данных о гарантированном соблюдении не найдено |
| Пометка TrafficVeil | Легитимный / Прочие краулеры и сервисы |
2. Зачем Amazon Kendra приходит на сайт
- организация (возможно, ваша собственная) построила корпоративный поиск на базе Kendra и явно включила ваш сайт как источник данных — например, для внутренней базы знаний, объединяющей документацию, вендорские сайты или отраслевые ресурсы;
- обход ограничен URL, которые клиент указал как seed или через sitemap — не системный обход всего интернета;
- частота и глубина обхода определяются настройками синхронизации (sync settings), которые задал администратор конкретного индекса Kendra.
Типичный кейс: сайт регулярно посещается Amazon Kendra в рамках заданного клиентом расписания синхронизации данных — прежде чем реагировать как на нежелательный трафик, стоит выяснить, не настроен ли на вашей же стороне (или стороне партнёра/клиента) такой индекс, включающий ваш сайт как источник.
3. Нагрузка и риски
Если это ваша собственная корпоративная поисковая инфраструктура — прямая польза очевидна: без индексации сайт не будет находиться через внутренний поиск компании. Блокировка в этом случае вредит не постороннему боту, а собственному корпоративному поиску.
Если сайт точно не связан ни с одним клиентом AWS, использующим Kendra с настроенным на него источником — прямой пользы, как правило, нет, и применима обычная логика «нежелательный, если пользы нет». Поскольку обход по конструкции сервиса ограничен явно указанными URL, а не свободным блужданием по сайту, нагрузка обычно предсказуема и ограничена конкретным набором страниц.
4. Как найти Amazon Kendra в логах
# Базовый поиск
grep -i "amazon-kendra" /var/log/nginx/access.log
# Топ URL — ожидаемо ограниченный набор seed-адресов или страниц из sitemap
grep -i "amazon-kendra" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head
# Топ IP за этим UA
grep -i "amazon-kendra" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# Суточная активность — ожидаемо по расписанию синхронизации, заданному клиентом
grep -i "amazon-kendra" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -cВерификация. Строку UA подделать может любой скрипт. Официального списка IP-диапазонов конкретно для этого коннектора не найдено — для решения allow/deny смотрите связку UA + IP/ASN (инфраструктура AWS) + ограниченный, предсказуемый набор URL, характерный для целевого, а не свободного обхода:
IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"5. robots.txt для Amazon Kendra
# Жёсткий запрет — если сайт не является источником для чьего-либо индекса Kendra
User-agent: amazon-kendra
Disallow: /
# Разрешить всё — необходимо, если сайт настроен как источник данных Web Crawler
User-agent: amazon-kendra
Allow: /6. Блокировка вручную и через TrafficVeil
Nginx:
if ($http_user_agent ~* "amazon-kendra") {
return 403;
}
limit_req_zone $binary_remote_addr zone=amazonkendra:10m rate=10r/m;
location / {
if ($http_user_agent ~* "amazon-kendra") {
limit_req zone=amazonkendra burst=20 nodelay;
}
}Apache (.htaccess):
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} amazon-kendra [NC]
RewriteRule ^ - [F,L]TrafficVeil:
- прежде чем блокировать — проверьте, не настроен ли на сайте (или у связанного с ним партнёра/клиента) индекс Kendra с источником Web Crawler, указывающим на этот домен;
- если используется — allow, блокировка сломает собственную корпоративную поисковую инфраструктуру;
- если сайт точно не связан ни с одним клиентом AWS Kendra — Disallow и запрет в TrafficVeil обоснованы;
- после изменения сверьте логи и, если применимо, убедитесь, что нужный поисковый индекс продолжает синхронизироваться.
7. Что делать: короткий алгоритм
- Первый шаг: выяснить, не настроен ли на вашей стороне (или у клиента/партнёра) индекс Kendra с этим сайтом в качестве источника;
- Настроен и нужен — allow, это собственная корпоративная поисковая инфраструктура;
- Сайт точно не связан ни с одним клиентом AWS Kendra — Disallow + запрет в TrafficVeil;
- Не блокируйте по маске
User-agent: *, чтобы не задеть Googlebot/YandexBot заодно.
8. С кем не путать Amazon Kendra
| Бот / сосед | Кластер | Комментарий |
| MainWP | Прочие краулеры и сервисы | Та же логика «сначала проверьте, не ваш ли это инструмент», но для управления WordPress |
| Silktide | Прочие краулеры и сервисы | Та же модель «настроено кем-то из вашей организации», но для веб-governance/доступности |
| ActiveComply | Прочие краулеры и сервисы (см. отдельную статью) | Та же логика для узкой отраслевой ниши — регуляторный compliance-мониторинг финансовых организаций |
| contxbot | Прочие краулеры и сервисы (см. отдельную статью) | Тоже официально задокументированный бот Amazon, но с другой задачей — товарные рекомендации для Native Shopping Ads, а не корпоративный поиск |
9. Стратегия allow/deny для Amazon Kendra
| Ситуация | Действие |
| Сайт настроен как источник данных для чьего-либо индекса Kendra | Allow — собственная (или партнёрская) корпоративная поисковая инфраструктура |
| Сайт не связан ни с одним клиентом AWS Kendra | Disallow + запрет в TrafficVeil |
| Неясно, кто и зачем настроил индексацию | Уточнить у своей команды или партнёрских организаций, использующих AWS |
| Нагрузка от обхода заметна, но источник легитимен | Обсудить настройки sync-расписания на стороне клиента, а не блокировать технически |
| Подозрение на подделку UA | Проверять IP/ASN на принадлежность инфраструктуре AWS и ограниченный, предсказуемый набор запрашиваемых URL |