Технологии
AWS показала, как встраивать отдельные Quick Sight-визуализации в React с доступом для каждого пользователя
Serverless-схема связывает Cognito, API Gateway и Lambda, а embed URL ограничивает просмотр конкретными DashboardId, SheetId и VisualId.

Не весь дашборд, а нужный элемент интерфейса
AWS опубликовала практическую архитектуру для команд, которым нужно встроить аналитику в React-приложение, но не хочется отправлять пользователя в отдельный BI-интерфейс. Вместо полного дашборда приложение показывает отдельный график, метрику или диаграмму Amazon Quick Sight. Такой уровень встраивания даёт разработчику контроль над компоновкой страницы: аналитический элемент можно поставить рядом с рабочей формой, карточкой клиента или собственными фильтрами, сохранив единый пользовательский сценарий.
Главная сложность здесь не в iframe, а в идентификации. Каждый вошедший пользователь должен увидеть только разрешённые ему данные и визуализации. В предложенной AWS схеме Amazon Cognito отвечает за вход и выдаёт JWT, API Gateway проверяет токен, а Lambda создаёт временный embed URL. Запрос к Quick Sight сужается до конкретной комбинации DashboardId, SheetId и VisualId, поэтому ссылка не превращается в универсальный пропуск ко всей аналитике организации.
Фронтенд раздаётся из S3 через CloudFront, а AWS WAF фильтрует вредоносные запросы на границе. В браузере работает Amazon Quick Sight Embedding SDK: createEmbeddingContext() создаёт контекст, а embedVisual() помещает выбранную визуализацию в контейнер React. Домен CloudFront необходимо заранее добавить в allowlist Quick Sight — без этого браузер заблокирует вложенный контент из-за ограничений между источниками.
Автоматическая синхронизация пользователей
Cognito и Quick Sight хранят пользователей раздельно, поэтому одной успешной авторизации недостаточно. Lambda берёт email из проверенного JWT и вызывает describe_user. Если соответствующей записи в Quick Sight нет, функция выполняет register_user и создаёт её с ролью READER — минимальной ролью, подходящей для просмотра встроенной аналитики. Благодаря такой синхронизации новый пользователь появляется при первом запросе, без ручного предварительного создания в двух системах.
Регистрация сама по себе не открывает дашборд. Родительский dashboard нужно поделить с пользователем и выдать Viewer: вручную через консоль либо программно через update_dashboard_permissions после регистрации. Уже поверх этого базового разрешения embed URL ограничивает сессию одной визуализацией. Для разграничения строк внутри разрешённого объекта AWS предлагает добавить Row-Level Security, привязав доступ к имени пользователя или группе.
В демонстрационном сценарии первый вход может закончиться пустой визуализацией: Lambda уже создала READER, но администратор ещё не поделился dashboard. AWS прямо описывает этот промежуточный этап, а не маскирует его как ошибку SDK. После выдачи Viewer и обновления страницы визуализация должна появиться. Если доступ назначается автоматически, этот разрыв можно убрать, но тогда Lambda получает дополнительную ответственность и права.
Развёртывание и собственные фильтры
Backend разворачивается одним CloudFormation stack. Из его Outputs фронтенду нужны ApiGatewayUrl, UserPoolId, UserPoolClientId, CloudFrontDomainName и S3BucketName. Отдельно разработчик копирует идентификаторы dashboard, sheet и visual из панели Embed visual. После сборки React статические файлы загружаются в S3, а инвалидация CloudFront очищает старую версию из кэша. Такой маршрут делает образец воспроизводимым, но не отменяет проверки IAM и стоимости созданных ресурсов.
Embedding SDK версии 2.5.0 и новее позволяет управлять фильтрами из собственного интерфейса. Методы addFilterGroups, updateFilterGroups, removeFilterGroups и getFilterGroups связывают, например, фирменный date picker или выпадающее меню с визуализацией без перезагрузки страницы. Quick Sight продолжает вычислять данные и рисовать график, а пользователь взаимодействует с контролами приложения, поэтому BI-компонент меньше ощущается как сторонний виджет.
Для production особенно важны границы доверия. Cognito Authorizer должен отклонить неавторизованный запрос ещё до Lambda; роль функции должна разрешать только необходимые операции; dashboard нельзя считать закрытым лишь потому, что его visual показывается по ограниченному URL. После эксперимента AWS советует удалить stack, тестовых пользователей, домен из allowlist и проверить остаточные ресурсы: CloudWatch logs, IAM policies, непустые S3 buckets и внешние Quick Sight-объекты могут пережить автоматическое удаление.
Практический вывод — начинать стоит с одной визуализации и пройти путь полностью: вход, регистрация READER, выдача Viewer, генерация URL, рендер в браузере и применение фильтра. Только после такой проверки имеет смысл собирать из отдельных visual полноценный аналитический экран. Архитектура полезна именно тем, что разделяет аутентификацию, разрешение на dashboard и узкий контекст встраивания вместо попытки решить всё одним секретным URL.