Vitaly Karasik

DNS тут ни при чём, nginx это веб-сервер.

Если я правильно вас понял, вам нужно стандартное обратное проксирование сайта, описанное примерно в любой инструкции, например.

Посмотри установлен ли bash completion?

bashrc

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
    . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
  fi
fi

На сайте используется TLS Fingerprint (вероятно, JA3) как один из индикаторов сессии в системе перед веб-сервером, вероятно, это анти-DDoS.
Так как браузер и curl используют разные SSL-библиотеки и передают разные наборы шифров, сервер предлагает вам пройти challenge.

Предполагаю что как-то так.
1. Погуглить AWS S3 access to one folder
2. Наткнуться на ответ в KB AWS https://repost.aws/knowledge-center/s3-folder-user...
3. Реализовать изменение политик любым удобным иструментом - cli, powershell, terraform etc

Есть два направления решения:
1. Перенести опции запуска в файл настроек ( ~/.ssh/config)
https://www.digitalocean.com/community/tutorials/h...

Тогда не потребуется вводить эти ключи и сработает ssh-copy-id

2. Ssh-copy-id всего лишь скрипт, который добавляет ключ в файл ~/.ssh/authorized_keys
Содержимое можно перенести или через scp или вообще через буфер обмена. Файл текстовый, ключ не особо длинный....
То-есть руками выполнить необходимые действия.

Критичны права на каталог ~/.ssh и сам файл. ~/.ssh/authorized_keys.
Права записи должны быть только у владельца.
Проще ставить 700 на каталог и 600 файл.

Запускайте эти скрипты как systemd service - это несложно, надёжно, и именно так решается эта задача.

В postgresql создаётся физически новая версия строки при update (с обновлением всех индексов либо hot update если применимо) даже если ни одно поле не меняет своё действительное значение. Есть встроенный триггер suppress_redundant_updates_trigger, который можно повесить на таблицу, тогда ничего действительно не меняющий в данных update будет пропускаться.

Если меняется хотя бы одно значение - оптимизации не подлежит, должна быть записана новая версия строки в таблицу (чтобы MVCC обеспечить). Если возможно, оптимизация HOT update исключит сопутствующее обновление индексов.

В общем, чтобы не издеваться над девушкой, объясним на пальцах.

Во-первых, заголовок у вопроса чудовищно некорректный. Это все равно что спросить, "что быстрее - пылесос или стиральная машина?"
Во-вторых, ответ на вопрос "производить ли обработку данных в БД или же запросить все данные в клиентское приложение и обрабатывать там" совершенно очевиден: обработку данных следует производить в общем случае только в БД. Она для этого и придумана. Чтобы обрабатывать значительные объемы данных.

Да, js тоже "может" обрабатывать большие объемы данных.
Но чтобы значительный объем данных обработать, его сначала надо передать, полностью забив канал между сайтом и базой
Чтобы значительный объем данных обработать, его надо сначала проиндексировать. Причем делать это каждый раз, а не использовать уже имеющийся набор индексов
Чтобы значительный объем данных обработать, надо иметь значительный объем памяти или упасть из-за её недостатка
Чтобы значительный объем данных обработать в многопоточном режиме (а сайт как раз является многопоточной системой), все вышеперечисленное надо умножить на количество посетителей сайта - при каждом запросе перегонять весь массив данных, выделять память, индексировать, считать. Если же вы оставляете все данные в памяти приложения, то их тогда надо как-то синхронизировать с БД. То есть вы себе собираете кучу проблем на пустом месте.

Несомненно, из любого правила есть исключения. И бывают ситуации, когда приходится считать в приложении.
Но на вопрос в общем виде ответ будет совершенно однозначный. Не "может так, может сяк", а только в БД.