Не понятно как это ложится на экономику. Чтобы стать гос-ву "привлекательным" нужны деньги, деньги в гос-ве преимущественно берутся с налогов на добавленную стоимость. Для этого необходимо чтобы население было работоспособным. А помимо снижения рождаемости, над человечеством нависла гигантская проблема старения населения и многие гос-ва уже начинают повышать пенсионный возраст, потому что не сходятся цифры. Соответственно "привлекательные" гос-ва должны избавляться от старых (не прибыльных) людей. И оно уже не такое "привлекательное" для миграции. Мне эта теория потому выглядит не работоспособной.
Было бы очень итересно такое пощупать, еще можно прикрутить к онлайну и с каждым диалогом прилагать идентификатор пользователя. То нпс сможет отвечать вроде "А вот твой предшественник U123456 то был похитрее и разгадал задачку, хо-хо-хо". Правда ChatGPT 3.5 сильно быстро забывает контекст :)
Во-первых, best practices - это общепринятые решения, потрудитесь мне привести аналог решения моей задачи, либо это голословные утверждения. Во-вторых, я не AWS архитектор, я могу признать, что решение не оптимальное, но если выше @lair расписал подробно и объяснил его точку зрения. То вы даже не потрудились привести примерный пайплайн решения проблемы, при чем я скинул ссылку на доки где указано, что генератор CloudFront URL требует публичный ключ.
Особенно после следующего утверждения:
ни API Gateway из-за лимита 10Мб/30с, ни короткоживущая лямбда ... не подходят
Интересно послушать как выполнить аутентификацию на стороннем API api.myapp.com, обработать (сжать, конвертировать) изображение и сохранить его в S3 bucket.
ссылки генерятся на загрузку, а не отдачу, раздача идет через Cloudfront. У Cloudfront другой механизм генерации ссылок (если он вообще нужен).
Но в таком случае доступен только функционал загрузки, но как отдать конечному юзеру файл, в вашем варианте? У Signed URLs необходимо задать публичный ключ, для верификации, это удобно для взаимодействия между сервисами, но не с тысячами пользователей.
Предложенный вами подход с генерацией presign url не подходит, так как у них ограниченное время жизни ссылок (как я уже отвечал выше). Допустим для заметки вы загрузили картинку, вставили на нее ссылку в эту заметку, а через 36 часов она не валидна и не отображается.
Доступ извне вы не ограничите по IAM, когда клиенты приходят из разных уголков мира и доступ к entries (заметкам в журнале) в которые вы планируете сохранять картинки через lambda хранятся в виде зарегистрированных юзеров в вашем приложении, к которому необходимо постоянно обращаться, можно ли сохранять или отдавать картинку конкретному пользователю. Думаю, я не достаточно развернуто описал usecase в статье. :)
Если цель — сделать красивый адрес, то API Gateway + Custom Domain прекрасно решают задачу без создания лоадбалансера.
API Gateway + Custom Domain известный подход, думаю тут нужно отталкиваться от инфраструктуры. Аналогов данной статьи я не встречал, где мы имеем VPC с двумя подсетями. Конкретно это подход можно развивать уже далее, размещая сервера в приватную сеть, организовывая доступ через бастион хост и тд.
Вот только может так оказаться, что намного эффективнее это делать не в лямбде при загрузке, а в лямбде, которая обрабатывает уже загруженный файл по событию — потому что она может читать файл из S3 чанками, а не обязана съесть все, что пришло в HTTP-запросе.
Да, как вариант, если нам не нужна авторизация (можно ли сохранять картинку или нет)
Без VPC вы не создадите subnet, без subnet вы не создадите TargetGroup и LoadBalancer и в свою очередь сможете настроить Alias в Route53 во время создания записи с красивым uri формата images.myapp.com.
Не соглашусь, что это плохая идея, в зависимости от того какие цели преследуете, например как вы убедитесь, что картинка не та же самая, что уже была загружена для данной заметки? Тут нам нужно посчитать хэш и без сервера не обойтись. Тут конечно, можно рассчитать, что будет выгоднее, хранение одинаковых файлов в S3 bucket или лишний раз загрузить файл в lambda. И конечно, функционал может быть расширен очень сильно - вычищать метаданные картинки (что делают все уважающие себя соц сети), сжимать и тд.
Ваш подход имеет место быть при одном условии, если S3 bucket имеет публичный доступ, в противном случае без прослойки в виде сервера не обойтись. Иначе не получится организовать аутентификацию. Можно конечно генерировать временные ссылки на объект, но они имеют ограниченный период действия, точно не помню 24 часа или 3 дня..
Не понятно как это ложится на экономику. Чтобы стать гос-ву "привлекательным" нужны деньги, деньги в гос-ве преимущественно берутся с налогов на добавленную стоимость. Для этого необходимо чтобы население было работоспособным. А помимо снижения рождаемости, над человечеством нависла гигантская проблема старения населения и многие гос-ва уже начинают повышать пенсионный возраст, потому что не сходятся цифры. Соответственно "привлекательные" гос-ва должны избавляться от старых (не прибыльных) людей. И оно уже не такое "привлекательное" для миграции. Мне эта теория потому выглядит не работоспособной.
Надеюсь на разбор ошибок и следующий полет!
Грустно видеть на ресурсе технической направленности столько злорадства вместо конструктивных диалогов по теме.
Было бы очень итересно такое пощупать, еще можно прикрутить к онлайну и с каждым диалогом прилагать идентификатор пользователя. То нпс сможет отвечать вроде "А вот твой предшественник U123456 то был похитрее и разгадал задачку, хо-хо-хо". Правда ChatGPT 3.5 сильно быстро забывает контекст :)
Во-первых, best practices - это общепринятые решения, потрудитесь мне привести аналог решения моей задачи, либо это голословные утверждения.
Во-вторых, я не AWS архитектор, я могу признать, что решение не оптимальное, но если выше @lair расписал подробно и объяснил его точку зрения. То вы даже не потрудились привести примерный пайплайн решения проблемы, при чем я скинул ссылку на доки где указано, что генератор CloudFront URL требует публичный ключ.
Особенно после следующего утверждения:
Интересно послушать как выполнить аутентификацию на стороннем API api.myapp.com, обработать (сжать, конвертировать) изображение и сохранить его в S3 bucket.
Не использовал Cloud Functions, по прайсу примерно одно и то же.
Но в таком случае доступен только функционал загрузки, но как отдать конечному юзеру файл, в вашем варианте? У Signed URLs необходимо задать публичный ключ, для верификации, это удобно для взаимодействия между сервисами, но не с тысячами пользователей.
Предложенный вами подход с генерацией presign url не подходит, так как у них ограниченное время жизни ссылок (как я уже отвечал выше). Допустим для заметки вы загрузили картинку, вставили на нее ссылку в эту заметку, а через 36 часов она не валидна и не отображается.
Методы решения задачи могут любые, в данном примере решено через Load Balancer, можно через CloudFront, можно через API Gateway.
Доступ извне вы не ограничите по IAM, когда клиенты приходят из разных уголков мира и доступ к entries (заметкам в журнале) в которые вы планируете сохранять картинки через lambda хранятся в виде зарегистрированных юзеров в вашем приложении, к которому необходимо постоянно обращаться, можно ли сохранять или отдавать картинку конкретному пользователю.
Думаю, я не достаточно развернуто описал usecase в статье. :)
API Gateway + Custom Domain известный подход, думаю тут нужно отталкиваться от инфраструктуры. Аналогов данной статьи я не встречал, где мы имеем VPC с двумя подсетями. Конкретно это подход можно развивать уже далее, размещая сервера в приватную сеть, организовывая доступ через бастион хост и тд.
Да, как вариант, если нам не нужна авторизация (можно ли сохранять картинку или нет)
AWS SAM прекрасный инструмент, просто другой подход, в отличии от использования terraform, который конкретно мне ближе. :)
Без VPC вы не создадите subnet, без subnet вы не создадите TargetGroup и LoadBalancer и в свою очередь сможете настроить Alias в Route53 во время создания записи с красивым uri формата images.myapp.com.
Не соглашусь, что это плохая идея, в зависимости от того какие цели преследуете, например как вы убедитесь, что картинка не та же самая, что уже была загружена для данной заметки? Тут нам нужно посчитать хэш и без сервера не обойтись. Тут конечно, можно рассчитать, что будет выгоднее, хранение одинаковых файлов в S3 bucket или лишний раз загрузить файл в lambda.
И конечно, функционал может быть расширен очень сильно - вычищать метаданные картинки (что делают все уважающие себя соц сети), сжимать и тд.
Ваш подход имеет место быть при одном условии, если S3 bucket имеет публичный доступ, в противном случае без прослойки в виде сервера не обойтись. Иначе не получится организовать аутентификацию.
Можно конечно генерировать временные ссылки на объект, но они имеют ограниченный период действия, точно не помню 24 часа или 3 дня..