Хорошие и плохие примеры архитектур в AWS

[VitohA]

Предлагаю тут обсуждать примеры правильных и не правильных подходов при реализации проектов в AWS.

Начну, пожалуй, первым. На глаза попалась статья про 2-tier инфраструктуру (ну там, где всё, кроме базы, в одном приложении) и как оное реализовать через Terraform: https://blog.numericaideas.com/deplo...with-terraform
Классический пример, как не нужно делать, о чём и написал автору в LI, ответа пока нет
Что тут не так, как думаете? Картинку с архитектурой сразу тут прикрепил, там уже интересно.

[VitohA]

Цитата (VitohA) »

Что тут не так, как думаете? Картинку с архитектурой сразу тут прикрепил, там уже интересно.

Автор так и не удосужился ответить, что не мудрено

По факту: в публичной сети есть ALB и инстанс, содержащий фронт-энд. Одно из двух лишнее, тут либо надо убирать ALB, либо EC2 двигать в приватную сеть, ибо масло маслянное.
Но самое интересное начинается в коде для security groups и смысле публичной сети:

# Create a security  group for production node to allow traffic 
resource "aws_security_group" "production-instance-sg" {
  name        = "production-instance-sg"
  description = "Security from who allow inbound traffic on port 22 and 9090"
  vpc_id      = aws_vpc.infrastructure_vpc.id

  # dynamic block who create two rules to allow inbound traffic 
  dynamic "ingress" {
    for_each = var.inbound_port_production_ec2
    content {
      from_port   = ingress.value
      to_port     = ingress.value
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = -1
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Правилами разрешён любой входящий трафик на порты, используемые приложением. Отовсюду. А у EC2 в публичной сети имеется вполне себе публичный IP адрес. Т.е. можно достучаться до приложения по 4 IP адресам: 2 у ALB и 2 у EC2 инстансов. Причём последний это именно прямой доступ, а не через reverse proxy, как в случае с ALB. Там даже могут всплыть ошибки уровня приложения именно по причине отсутствия rewrite'ов.

По итогу имеем классический пример, как не надо делать.

[Smirnoff]

Цитата (VitohA) »

можно достучаться до приложения по 4 IP адресам: 2 у ALB и 2 у EC2 инстансов.

Как-то многовато. Классический "перебор"...

[VitohA]

Цитата (Smirnoff) »

Как-то многовато. Классический "перебор"...

Ага, так ещё и переплата за дополнительные 2 публичных адреса, которые не нужны так-то.

[Majesty]

Модели облачных сервисов iaas, paas, SaaS чем отличаются?

[VitohA]

Цитата (Majesty) »

Модели облачных сервисов iaas, paas, SaaS чем отличаются?

Из насколько крупных "кирпичиков" это состоит
iaas - конструктор уровня ДЦ, собери инфру себе сам. Можешь настроить всё, будешь настраивать всё.
paas - за тебя уже установили коммутаторы и ОС накатили, работай уже с этим. Но софтом рулить тебе.
saas - уже и бекенд есть и софт поставили - продавай, как конечный продукт

[Majesty]

VitohA
Какой лучше использовать? Какой бы ты использовал?

[VitohA]

Цитата (Majesty) »

VitohA
Какой лучше использовать? Какой бы ты использовал?

Ну так it depends, прямо зависит от требований)
Мне больше по душе iaas и paas, что является самыми основными подходами у aws. Всегда выбираю проекты под эти модели.

[Majesty]

VitohA
iaas и paas то есть с ними можно без разработчиков?

[VitohA]

Цитата (Majesty) »

VitohA
iaas и paas то есть с ними можно без разработчиков?

Как раз нет, это классический случай разработки под клиента. В saas можно без оных, и то не всегда.

[Majesty]

Цитата (VitohA) »

iaas - конструктор уровня ДЦ, собери инфру себе сам.

Я подумал, что это конструктор No Code решения

[VitohA]

Цитата (Majesty) »

Я подумал, что это конструктор No Code решения

No code - это, в принципе, яркий пример фразы "скупой платит дважды". Сначала за no code, а потом за его переделывание. Если и есть полурабочее решение, то оно в saas может есть только.

Кстати, по поводу базовых архитектур, вот тут прям отличное пособие по классическим 3-tier аппам. Всё по отдельным подсеточкам, правильно security groups настроили. Правда на примере NLB, но оно тоже более чем рабочее решение, особенно когда не только http нужен.

[garniv]

Цитата (VitohA) »

Сначала за no code, а потом за его переделывание.

это точно.

[Smirnoff]

Цитата (VitohA) »

ещё и переплата за дополнительные 2 публичных адреса

Сильно подозреваю, что, в сравнении с общей стоимостью решения, эти доли копеек вообще никого не затруднят...

Цитата (VitohA) »

No code - это, в принципе, яркий пример фразы "скупой платит дважды". Сначала за no code, а потом за его переделывание.

Далеко не всегда это от скупости - часто вовсе от тупости. Сунется ба-альшой начальник в рекламки (или вовсе побывает на какой конференции ) - и тут же принимает решение: "вот эту хачу, заверните!".
Потом "эту" пытаются всем отделом IT "допилить" (порой теряя при этом наиболее продвинутую часть отдела ), потом выясняется, что "эту" под нужные требования вообще "допилить" принципиально невозможно.
И дальше - классика: тупой платит трижды, как минимум; как максимум - просто всегда.

[VitohA]

Цитата (Smirnoff) »

Сильно подозреваю, что, в сравнении с общей стоимостью решения, эти доли копеек вообще никого не затруднят...

Так то да, но всё же


Амазон 2 месяца назад выпустил новую ревизию AWS Well-Architected Framework пособия. Всё забывал про неё, хоть и добавлена в todo. Чтиво на пару недель

[VitohA]

Есть простая архитектурная задачка: имеется классическое 3-tier приложение, с фронтом, бэком и базой. Есть vpc с публичной и приватной подсетями (для упрощения ограничимся именно этими двумя подсетками). Как бы вы разместили приложения по этим подсетям с точки зрения Амазона? Подавляющее большинство фронт помещают в публичную сеть почему-то.

Это как раз отсылка к ссылке выше, как правильно хостить сервисы в Амазоне. Даже далеко не новички ошибаются в этом, по моей статистике ~90%. Ну как так то?

[VitohA]

Про боль переезда сервисов, когда они доросли до Big Data. У меня кейс несколько другой, но парней понимаю оч хорошо. Redshift, который надстройка над постгре, Athena, которая есть переделка трино, и т.д. Как правильно и подешевле всё разместить, когда кейсы не стандартные?

Как мы переезжали с PostgreSQL на Data Lake в AWS и какие грабли собрали по пути.