Когда data silos становятся data bridges
Представьте: у вас десятки AWS-аккаунтов по отделам (продажи, логистика, финансы). Каждый хранит свои данные в S3 и каталогизирует через Glue. А BI-аналитики, работающие в Quick, хотят построить единый дашборд, но упираются в стену: нельзя напрямую запросить таблицу из соседнего аккаунта. Раньше выход был один — копировать данные или настраивать сложные Lambda-функции. Честно говоря, это ад.
В мае 2026 года AWS наконец-то сделала то, о чём просили enterprise-клиенты годами: прямой кросс-аккаунтный доступ между Quick и Athena. Теперь можно выполнять запросы к данным из любого аккаунта, не перемещая их физически. Звучит как магия, но за кулисами — продуманная архитектура на базе AWS Glue Data Catalog и Resource Access Manager.
Ключевое новшество: Quick «видит» таблицы из чужих аккаунтов через общий Glue Data Catalog, а Athena разрешает кросс-аккаунтные запросы благодаря IAM ролям и политикам. Никакого дублирования данных.
Как это работает (без кода, только логика)
Владелец аккаунта А публикует свои Glue-базы данных через Resource Access Manager. Владелец аккаунта B (где живёт Quick) принимает «приглашение» и создаёт новую роль IAM с доступом к этим базам. Всё остальное — прозрачно: Quick видит общие таблицы рядом со своими, а Athena автоматически маршрутизирует запрос в нужный аккаунт.
Для BI-аналитика это выглядит как обычный дашборд. Он не знает, что данные физически лежат в разных регионах или аккаунтах. Просто пишет SQL-запрос в Athena, а фоновые механизмы AWS делают всё остальное.
Enterprise — бенефициар номер один
Крупные компании с децентрализованной инфраструктурой наконец-то получают единую картину. Отдел маркетинга может смотреть воронку продаж вместе с финансовыми транзакциями, не дёргая DevOps для копирования данных. Безопасность не страдает: доступ контролируется на уровне IAM, Glue и RAM. Никакого случайного экспорта.
Кстати, похожая идея объединения разрозненных источников (только не в BI, а в RAG) реализована в корпоративной RAG-системе PDI на AWS. Там объединяют Confluence и SharePoint, здесь — аккаунты с S3 и Glue. И в том, и в другом случае главная ценность — бесшовная интеграция.
Но есть и обратная сторона. Если вы не продумаете политики RAM, можно случайно открыть доступ к данным, которые должны быть изолированы (например, сырые логи пользователей). Совет: всегда используйте теги и строгие условия в IAM, чтобы точно знать, кому и что разрешено.
Ещё один момент — производительность. Кросс-аккаунтные запросы немного медленнее внутриаккаунтных из-за сетевых прослоек. AWS это компенсирует через оптимизации в Athena, но на больших объёмах разница может быть заметной. Поэтому стратегически лучше размещать часто используемые данные в одном аккаунте, а остальное запрашивать удалённо.
Что дальше? Предсказания без хрустального шара
Сейчас мы видим только первый шаг. Логично ожидать, что в следующих релизах AWS добавит автоматическое обнаружение «сиротских» таблиц и рекомендации по объединению схем. Возможно, появится визуальный редактор кросс-аккаунтных связей прямо внутри Quick. А ещё — интеграция с Lake Formation, чтобы управлять доступом на уровне строк и столбцов поверх многих аккаунтов.
Если вы уже используете Quick, но до сих пор страдали от копирования данных — попробуйте фичу. А если только присматриваетесь к BI на AWS, обратите внимание на кастомные коннекторы к Quick через OpenAPI. Гибрид стандартного хранилища и кастомных источников — это то, что отличает архитектуру от «сферического коня в вакууме».
Кросс-аккаунтный доступ — не rocket science, но именно такие точечные улучшения превращают облачные инструменты в настоящие предприятия. Data silos уходят в прошлое, а data bridges приходят им на смену.
