Андрей Мельников, и тут у меня вознкили подозрения. Где вы регались и куда вв пробуете залогиниться. Amazon и AWS это разные сервисы и у них разные списки пользователей
Иван Шумов
@inoise Куратор тега Amazon Web Services
yellowmew, очень хорошие замечания и дополнения, конечно) и заодно возьму на заметку как делается пиринг, хотя это все абсолютно, черт, возьми) Курсы по AWS много дают, конечно. Я сейчас закрыл все, кроме ML и IOT по нему: Solution Architect Associate, Developer Associate, Networking Speciality, Security Speciality, Event-Driven Security, Advanced CF, Complete Serverless, S3 masterclass, DDB Deep Dive .... Да много чего и все-равно приятно учиться новому. Еще бы почаще приходилось с этим работать.
А что касается реальности ... "гравитация, бессердечная ты c****" (с) TBBT Шелдон Купер. Любая идея может встретить проблему - главное принимать ошибки и стараться их решить. Какой там первый столп в Security? Правильно, Visibility
Иван Шумов
@inoise Куратор тега Amazon Web Services
sailorpapay, в RDS нельзя обращаться по внутреннему IP - за нас это делает route53 (у сервисов вообще нет статических ip, ваш кэп). DNS resolve происходит разным образом. Я вам советую пройти курсы от ACloud Guru, например. Там очень хорошо рассказано. Сам я VPC Peering не настраивал, знаю только что он сделан именно для решения подобных проблем.
Иван Шумов
@inoise Куратор тега Amazon Web Services
hOtRush, Все надо считать и проверять, но давай разделим на несколько частей задачу:
USER->CDN->EC2 (внутри AWS Network, low latency) это быстрее чем USER->EC2 (over Internet, high latency) из-за Edge Location Network
RDS Public access - не обрабатывается через CDN, а значит == USER->EC2(over Internet, high latency)
Private RDS via VPC Peering (внутри AWS Network, low latency)
Делаем выводы.
Бэкэнд в разных регионах нужен в первую очередь ради отказоустойчивости через Route53. VPC Peering все-равно нужен в таком случае, иначе боль и унижение. А CDN полезен вообще всегда. Он еще и дешевле прямых запросов, если память не изменяет
MamaLuyba, в Европе и штатах что-то порядка 40-45%, что у нас точно не в курсе - платит же организация. А человек говорит про значения чисто на руки, то есть после вычета налогов. То есть в его видении там должно быть 4500$
ince, они платят очень большой налог в стране, гораздо выше нашего, отсюда и ЗП выше. На удаленке другие правила и поэтому стоимость ниже. Добавьте к этому свободный график, отсутствие необходимости ездить в офис (готовить сотруднику рабочее место и убираем расходы на организацию всего этого) и получаем что удаленному сотруднику будут платить в 2,3... 5 раз меньше. По тому что работа сдельная, почасовая и с другими налогами. Фуллтайм получить тоже можно, но свободный английский нужен, присутствие в той же часовой зоне в основном +- пара часов, но опять же столько же вы не получите
Иван Шумов
@inoise Куратор тега Amazon Web Services
hOtRush, и надо не забывать что даже у AWS есть предел скорости передачи информации. CF Network очень крутая вещь, но если у вас сервер на земле, а клиент на луне то магии ждать не стоит)
Иван Шумов
@inoise Куратор тега Amazon Web Services
hOtRush, да, по тому что ec2 инстанс должен находиться в том же vpc что и rds. Таким образом проблема в обработке запросов уходит сама по себе (ее и не было у автора, пока он в другой регион не залез)
CDN ускоряет взаимодействие по http/rtmp протоколам между клиентом и сервером в ОБЕ стороны
Иван Шумов
@inoise Куратор тега Amazon Web Services
hOtRush, он не только для статики. Он для доставки контента, а подавляющее число проектов - вебмордочки различные. Если это так то где исполняется код не важно - CDN по внутренним каналам доставит его без кэширования даже с минимальным лэтенси и огромной скоростью.
Но вообще я подозреваю что человек просто выкинул базу наружу из облака и пошли задержки. А надо было VPС Peering сделать
Сергей Горностаев, и решается всеми и повсеместно. Можно сочинять книги и про разнице между красным и длинным, но только оно от этого красным и длинным быть не перестанет же)
