Amazon Kendra: возможно, ваш корпоративный поиск

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-сайтами — публичными или внутренними (интранет) сайтами организации, к которым у неё есть право доступа.

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

9. Стратегия allow/deny для Amazon Kendra