Комментарии 15
Есть сторонний модуль для nginx — ngx_aws_auth. Если судить по исходникам, он поддерживает Signature v4. Однако проект выглядит заброшенным: более года отсутствуют изменения в кодовой базе, а также имеется проблема совместимости с другими модулями, на которую не реагирует разработчик. К тому же, добавление дополнительных модулей в nginx — это само по себе зачастую болезненный шаг.
Готовая сборка nginx + ngx_aws_auth. 2 года полёт нормальный.
А можно вместо nginx поставить Cloudfront/Cloudflare/Akamai/etc и не иметь проблем
Если же перед вашим приложением стоит задача разграничить права доступа к файлам, например, «разрешить скачивать файлы только из локалки» или «разрешить Пете скачивать документ Х, а остальным запретить», то с кастомным прокси это сделать проще всего.
Также, помимо проксирования, nginx позволяет обрабатывать файлы на лету, например, ресайзить картинки или накладывать вотермарки. Соответственно, если вы не хотите, чтобы оригиналы картинок ушли в сеть, то решение из статьи вам поможет.
Если мне надо будет делать то что вы описали то я возьму готовое решение и не буду заморачиваться и буду платить намного меньше чем вы
- Дать доступ на скачивание документа Х только Пете, остальным запретить. При этом контроль доступа лежит в недрах приложения, а не в конфигах AWS (работает принцип IaC).
- У вас сайт, которому требуется ресайзить картинки и клеить вотермерки на лету, а оригиналы картинок лежат в закрытом S3 (вы не хотите, чтобы оригиналы достались кому-то на стороне). При этом вы не хотите получать большие счета за реквесты к S3 и кешируете картинки у себя.
Принцип называется IaaC и заключается он в том что вы описываете все ресурсы в коде (бакет, его конфиг и все остальное) но никак не логика приложения
Поддерживаю. Учитывая ещё и локальность лямбды по отношению к бакету, то это вообще отличное решение. Nginx же годится как общий случай, когда не обязательно есть Амазон, а возможно существует какой-либо s3 в локалке (минио?)
Я не разбирался подробно, но задачи, описанные комментом выше, на одном пет-прожекте у меня решаются походом, параллельно с другими нагрузками на минимальном дроплете DO. То есть, для меня это выходит бесплатно, плачу только за (изрядный) объем хранения на AWS. Если заюзать лямбды и амазоновский фронт — то придется за это платить, и платить совсем немало.
Это уж я не говорю про то, что обработку у меня делает свободный серверок в докере, который работает as is, без допила, а как это все конвертировать в лямбды — отдельный вопрос и отдельное время.
Я вот заметил, что те кто работает в энтерпрайз автоматически считают, что "облака" — это дёшево, просто действительно для их клиентов это не значительная разница и они ее просто не считают.
Соответственно и на пет-проектах никакой нагрузки нет и тоже вроде как дёшево.
Но если считать деньги, то очень мало пока кейсов, где в "облаках" будет хоть какой-то смысл.
Так что, решение с локальным хранением при кешировании — идея правильная, хотя, конечно, Amazon не оценит.
Все зависит от нагрузки и кол-ва клиентов.
Если у вас 3 калеки в год, то конечно DO рулит на минимальном тарифе
Хотя вот минимальный дроплет на DO стоит $5/мес, t3.micro — $7.5/мес
трафик с Cloudfront дешевле чем с S3
Lambda ничего не стоит если нет запросов
С учетом того что трафик стоит $0.085/gb чтобы окупить просто стоимость даже дроплета вам надо чтобы у вас было минимум 60gb в месяц
А если перед этим поставить Cloudflare то вообще только за первый запрос заплатите
Нет разницы работаете вы в ентерпрайзе или в конторе "рога и копыта" чтобы научиться правильно подбирать инструмент и уметь произвести холодный рассчет
Проксируем файлы из AWS S3 средствами nginx