Частный контент Cloudfront + архитектура подписанных URL-адресов

Позвольте мне начать с краткого введения в архитектуру системы, которую я планирую перейти на S3 + Cloudfront.

У нас есть порядок объектов в дереве. . Листья дерева имеют ряд ресурсов (в частности, изображения jpg), обычно порядка 20-5000, в среднем ~ 200. У каждого ресурса есть уникальный URL-адрес, который обслуживается сегодня через нашу настройку colo.

Я мог бы просто перенести все эти ресурсы на S3, настроить Cloudfront поверх этого и готово. Если бы мне не пришлось защищать ресурсы.

Большинство сущностей являются общедоступными (то есть ~ 99%), остальные защищены одним из многих способов (логин, IP, время и т. Д.). После того, как объект защищен, все ресурсы также должны быть защищены, и к ним можно будет получить доступ только после выполнения действительной авторизации.

Я мог бы решить эту проблему, создав две корзины S3 - одну частную и одну общедоступную. Для частного контента я сгенерировал подписанные URL Cloudfront после авторизации пользователя. Однако состояние объекта может произвольно меняться с публичного на частное и наоборот. Администратор системы может изменить сущность на любом уровне дерева сущностей, вызывая тем самым каскадное изменение по всему дереву. Одно изменение может вызвать изменение ~ 20 тыс. Объектов, умноженных на 200 ресурсов, что повлияет на 4 миллиона ресурсов.

Я мог бы запустить службу в фоновом режиме мониторинга изменений состояния, но это было бы обременительно, и изменить списки управления доступом для 4 миллиона элементов S3 потребуют значительного времени, и пока это происходит, у нас будет либо незащищенный частный контент, либо общедоступный контент, для которого нам придется генерировать подписанные URL-адреса.

Другой возможностью было бы сделать все ресурсы частными по умолчанию . При каждом запросе, сделанном к объекту, мы генерируем настраиваемую политику, предоставляющую доступ для этого конкретного пользователя ко всем ресурсам, содержащимся в объекте (с использованием URL-адресов с подстановочными знаками в настраиваемой политике). Это потребует создания политики для каждого посетителя, для каждой сущности - хотя это не будет проблемой. Однако это будет означать, что наши пользователи больше не могут ничего кэшировать, поскольку URL-адрес будет изменяться для каждого нового сеанса. Хотя это не проблема для частного контента, для нас было бы отстойно отказываться от кеширования для ~ 99% общедоступных сущностей.

Еще одним вариантом было бы сохранить весь контент частным и использовать описанный выше подход для частных сущностей. . Для публичных сущностей мы могли бы создать единую настраиваемую политику для каждой публичной сущности, которой будут пользоваться все пользователи. Если мы установим срок жизни 6 часов и убедимся, что новая политика будет сгенерирована через 5 часов, пользователю будет гарантировано время жизни политики не менее одного часа. Это имеет то преимущество, что позволяет кэшировать до 6 часов, а частный контент может быть общедоступным в течение 6 часов после изменения состояния. Это было бы приемлемо, но я не уверен, что оно того стоит (сейчас пытаюсь вычислить соотношение кеш / попаданий запросов). Очевидно, мы могли бы настроить 5/6 часовую границу, чтобы включить более длинный / более короткий кеш за счет более длительного / более короткого доступа к частным объектам.

Кто-нибудь развертывал подобное решение? Какие функции AWS, которые я упускаю из виду, могут быть полезны? Есть общие комментарии?