Позвольте мне начать с краткого знакомства с архитектурой системы, которую я рассматриваю для перехода на 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 я пропускаю, которые могут быть полезны? Есть какие-нибудь комментарии в целом?