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

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

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

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

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

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

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

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

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