Ну тут явно не в сертификате дело

с одних машин заходит с других не заходит - может фаервол? проверьте резелв с тех что заходит и с тех что нет, на один айпи они идут?

Спасибо за помощь, вроде разобрались. Нехорошие люди поменяли почту в контактных данных регистрации домена некоторое время назад. Письмо с подтверждением попало в спам и их всех пропустили. Вчера final notice присылали, и сегодня засуспендили домен были.

Ух

Смотрите на типы интеграции с функцией

Всем привет! У меня есть react, amplify, Cognito с user pool-ом и API GAteway, который через лямбды берет данные из БД.
Есть 1 тестовый юзер. Также есть отдельно база PostgreSQL, в которой много нужных юзеру данных.

Я хочу добавить роли, типа "Admin", "User", "Inspector", чтобы на UI отключать какие-то элементы (запретить удалять). А также, проверять на стороне API (лямбды), что данный запрос пришел от пользователя с такакой-то ролью и ему удалять нельзя.

Как эти роли, собственно ,внедрять?

Мой первый варинт был - тригер перед генерацией токена, который пойдет в постгрес, возьмет user_id, который sub и глянет какая роль и добавит как claims. Это верное направление?

Второй вариант был, зная sub (из сессии amplify), я могу по нему зайти в постгрес и там глянуь уже, что юзер может, а чего не может. Но это как бы отдельный вызов АИ юудет

Вопросы архитектуры это всегда баланс плюсов и минусов.  aws тем и прекрасен что можно одну и ту же задачу решить сотней разных способов. Рекомендую рассмотреть оба решения подробно с разных сторон стоимость, безопасность и тд. Может быть в процессе решения у вас появится какая-то база в которой роль-юзер будут кешироваться, может быть в имени юзера будет ответ о его правах и тд.

Благодарю за совет) я думал, что это может быть типовой задачей, которую кто-то уже решал))

я не настоящий сварщик но cognito + JWT токен + custom claim с ролью юзера в этом токене = имеем на фронте в amplify роль, дальше уже в UI включаем-отключаем элементы

https://aws.amazon.com/blogs/mobile/how-to-use-cognito-pre-token-generators-to-customize-claims-in-id-tokens/

Хорошее место для знакомства, проверки и углубления своих знаний по CloudFormation:

https://scaleyourcloudformation.com/

Фичи, популярные заблуждения и ошибки, проблемы и места скопления бесплатных шаблонов. Советую.

#CloudFormation

Супер история о том, как Амазон чуть не умер и переехал с серверов Sun на Linux. Это — история зарождения Amazon Web Services — облака, на котором сегодня работает добрая половина интернета.

Рассказывает один из непосредственных участников.

Самые впечатляющие моменты:

❧ в 2000 лопнул пузырь доткомов — технические компании обесценились в сотни раз, на фондовом рынке кончились деньги и Amazon начал жечь собственные средства — 1 миллиард долларов в год; самой крупной статьей расходов были серверы — их делал Sun, они стоили дорого;

❧ можно было перекупить серверы Sun у компаний, обанкротившихся на пузыре доткомов, но техдир Амазона пошел ва-банк — решил переехать с Sun на обычное железо Hewlett Packard на Линуксе; ядру лунукса тогда было всего 6 лет;

❧ на время переезда они остановили ВСЮ продуктовую разработку! ВСЕ занимались только переездом. В бэклоге лежали сотни функций для увеличения продаж, но все ждали, пока закончится переезд;

❧ заморозка развития сервиса привела к падению продаж →  пришлось повышать цены на товары → продажи упали ещё сильнее, запустилась «спираль смерти»;

❧ у Амазона оставалось буквально несколько кварталов до смерти, когда деньги на счету кончатся, но они успели и запустили всё нормально, стоимость масштабирования инфраструктуры упала на 80%;

❧ продажи — сезонный бизнес и Безос придумал, почему бы не сдавать простаивающие серверы в низкий сезон другим компаниям? На презентации он привел аналогию с электрической сетью — в 1900 годы каждый завод строил свою собственную электростанцию, почему бы не сделать «электрическую сеть» для IT? Плюс это круто сочеталось с его идеей разделить команды внутри компании, чтобы команды могли развиваться самостоятельно — каждая команда стала независимым API.

Ну а дальше вы знаете. Сегодня Амазон — это не только интернет-магазин, но и одна из крупнейших IT компаний планеты.

https://twitter.com/DanRose999/status/1347677573900242944

Коллеги, поделитесь мнением. Про странности в Вашингтоне слышали все (наверное)

А вот последствия

Но и это не все. Сегодня Parler отключат от серверов — услуги хостинга им предоставлял Amazon, но потом работники компании и активисты потребовали прекратить это сотрудничество от руководства.

Если соцсеть не найдет нового партнера, то просто прекратит свое существование.

Это каким боком к авс? Это ближе к политики

Уберем все про политику. Оставим про авс.

Опять же к авс тебе технически (а чат все таки технический) не имеет отношения никакого

Авс в праве не предоставлять ресурсы

Я всего лишь спросил мнения. Как технически поступать в подобных случаях