1.1.Создать вир­ту­аль­ную сеть и 2 под­се­ти,  1 пуб­лич­ная дру­гая  приватная
1.2 Nat для приватной
1.3 Security Groups
1.4 Instance - Созда­ние сер­ве­ра в пуб­лич­ной и при­ват­ной сетях
1.5 под­клю­че­ние к instance через Session Manager
1.5.1 Созда­дим IAM роль
1.5.2 под­клю­че­ние к private instance через Session Manager исполь­зуя endpoint
2.хранилище S3 доступ до кото­ро­го толь­ко из при­ват­ной сети
3.Auto scaling group -  гори­зон­таль­ное масштабирование
3.1 Target Groups
3.2 Load Balancer
3.3 Launch Templates
3.4 Autoscaling Group

 

 

1.1 Создаём 2 подсети

для нача­ла созда­дим вир­ту­аль­ную сеть в кото­рой будем созда­вать наши подсети:

созда­ём 2 подсети
10.5.1.0/24. - будет публичной
10.5.2.0/24. - будет приватной

пока созда­ём под­се­ти в одной зоне доступности:

под­се­ти мы созда­ли но досту­па в интер­нет у них нету, чтоб появил­ся надо создать internet-gateway

Теперь надо при­со­еди­нить его к наше­му VPC

Теперь настро­им авто­ма­ти­че­скую выда­чу пуб­лич­ных айпи-адре­сов тем сер­ве­рам, кото­рые будут запу­ще­ны в пуб­лич­ной под­се­ти. Выбе­рем первую пуб­лич­ную под­сеть в спис­ке подсетей

Теперь настро­им таб­ли­цы марш­ру­ти­за­ции - без соот­вет­ству­ю­щих марш­ру­тов наш интер­нет-шлюз всё рав­но оста­нет­ся недоступен

там уже авто­ма­ти­че­ски создан route table про­ас­со­ци­и­ру­ем его с нашей пуб­лич­ной подсеткой:

под­ре­дак­ти­ру­ем марш­ру­ты,  новый дол­жен идти ПОСЛЕ локаль­но­го и захва­ты­вать все адре­са назна­че­ния (0.0.0.0/0). Точ­кой назна­че­ния выбе­ри­те наш новый интер­нет-шлюз. Затем сохра­ни­те маршруты.

выби­ра­ем наш создан­ный IGW

 

1.2 Nat для приватной

Для пуб­лич­ной сети мы настро­и­ли выход в интер­нет, теперь настро­им выход в интер­нет для при­ват­ной под­се­ти и настро­им NAT

Отме­чу что NAT gateway созда­ёт­ся в пуб­лич­ной подсети:

созда­ние NAT зани­ма­ет вре­мя, как толь­ко он создаст­ся мож­но созда­вать марш­ру­ти­за­цию route table

Отре­дак­ти­ру­ем таб­ли­цу маршрутизации

новый марш­рут: идея точ­но такая же, весь тра­фик (0.0.0.0/0), кото­рый не попа­да­ет в local, дол­жен идти в NAT Gateway этой подсети

теперь при­вя­жем эту таб­ли­цу к соот­вет­ству­ю­щей при­ват­ной подсети

 

1.3 Security Groups

Преж­де чем добав­лять сер­ве­ра, при­дёт­ся доба­вить груп­пы безопасности

Созда­ём Security Groups для пуб­лич­ной сети

Пра­ви­ла будут сле­ду­ю­щие HTTP отку­да угод­но, так­же доба­вим SSH и ICMP

созда­ём ещё одну груп­пу для при­ват­ной подсети:

доступ по 22 раз­ре­ша­ем толь­ко с Security Groups пуб­лич­ной подсети

 

Созда­ём kep pair, фор­ма­та - pem, если его ещё нет. Исполь­зуй­те его при созда­нии инстансов.

после его созда­ния, он будет авто­ма­ти­че­ски ска­чан в фор­ма­те pem на ваш комп.

 

1.4 Создание сервера в публичной и приватной сетях

добав­ля­ем User data  это гру­бо гово­ря скрипт кото­рый будет запус­кать при запус­ке инстан­са, в моём слу­чае я став­лю nginx

 

а стро­кой
echo "Hello from `curl http://169.254.169.254/latest/meta-data/public-ipv4`" > /usr/share/nginx/html/index.html
я дёр­гаю meta data внут­рен­ний айпишник

далее если надо добав­ля­ем жёст­кий диск или выби­ра­ем его тип:

добав­ля­ем тэги если надо

назна­ча­ем Security Group кото­рый мы созда­ли для пуб­лич­ной подсети

запус­ка­ем:

выби­ра­ем наш ключ:

как видим всё нор­маль­но созда­лось, про­бу­ем подключиться:

про­ве­ря­ем в бра­у­зе­ре что по пуб­лич­но­му айпиш­ни­ку отда­ют­ся наши данные:

всё ОК  теперь запус­ка­ем  наш вто­рой инстанс в при­ват­ной сети:

всё тоже самое кро­ме момен­та выбо­ра подсети:

User data так же добав­ля­ем чтоб про­ве­рить что доступ в интер­нет есть:

выби­ра­ем в security groups нашу приватную :

осталь­ное всё также.

как видим наш инстанс запу­стил­ся и у него есть толь­ко при­ват­ный айпиш­ник из нашей подсети:

про­бу­ем под­клю­чить­ся и у нас ниче­го не долж­но полу­чить­ся так как пуб­лич­но­го айпиш­ни­ка нету:

но мы можем под­клю­чить­ся с пуб­лич­но­го инстан­са, так как отту­да у нас есть доступ соглас­но настро­ен­ной security group

Под­клю­ча­ем­ся к пуб­лич­но­му инстансу:

про­ве­ря­ем что до при­ват­но­го есть доступ по 22 порту:

[ec2-user@ip-10-5-1-78 ~]$ telnet 10.5.2.127 22
Trying 10.5.2.127…
Connected to 10.5.2.127.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.4
^]
telnet> quit
Connection closed.

копи­ру­ем ключ на пуб­лич­ный инстанс
[root@centos7 ~]# scp -i andr-key-pair.pem andr-key-pair.pem ec2-user@3.135.198.211:~/

и под­клю­ча­ем­ся с помо­щью него на приватный:

ssh -i andr-key-pair.pem 10.5.2.127

как видим мы под­клю­чи­лись и nginx уста­нов­лен, сле­до­ва­тель­но у нас есть доступ  интер­не­ту через наш NAT Gateway

 

1.5 подключение к instance через Session Manager

для рабо­ты session manage необ­хо­ди­мо что­бы был доступ в интер­нет, настро­им под­клю­че­ние к пуб­лич­но­му instance и при­ват­но­му как через NAT gateway так и через endpoint

1.5.1 Создадим IAM роль

 

теперь рас­смот­рим Security Groups, для рабо­ты ssm необ­хо­дим как мини­мум доступ по 443 пор­ту из 0.0.0.0/0

а теперь добав­ля­ем наше­му инстан­су IAM роль:

всё ок.

 

1.5.2 подключение к private instance через Session Manager используя endpoint

а теперь под­клю­чим­ся к наше­му при­ват­но­му инстан­су исполь­зуя endpoint но пред­ва­ри­тель­но уда­лим NAT

уда­лим subnet associations  у Route tables

уда­ля­ем айпишник

Всё у при­ват­ной под­се­ти досту­па в мир нету теперь можем настро­ить ENDPOINT

но нам ещё надо вклю­чить Edit DNS hostnames для наше­го VPC

 

Всё теперь нуж­но доба­вить 3 endpoint  ssm ssmmessages ec2messages

 

точ­но так же добав­ля­ем для ssmmessages и ec2messages, после созда­ния какое то вре­мя всё висит в ста­ту­се pending

 

после чего надо про­ве­рить что под­се­ти внутренние:

 

ну всё ок 3 энд­по­ин­та созданы:

теперь созда­ём IAM роли, но мы её уже созда­ли ранее,  когда настра­и­ва­ли доступ для пуб­лич­но­го инстанса:

вот этот пункт:  1.5.1 Созда­дим IAM роль

но нам необ­хо­ди­мо доба­вить к нашей роли поли­ти­ку AmazonSSMManagedInstanceCore

 

 

теперь мож­но назна­чать IAM роль для наше­го private instance

Поми­мо досту­па из нашей пуб­лич­ной сети, для рабо­ты ssm необ­хо­дим как мини­мум доступ по 443 пор­ту из 0.0.0.0/0

поэто­му пра­вим нашу private Security Groups

всё мож­но подключаться:

как видим всё нор­маль­но под­клю­чи­лось и досту­па в мир у нас нету:

 

2.хранилище S3 доступ до которого только из приватной сети

Simple Storage Service с созда­ния кон­тей­не­ра для фай­лов - так назы­ва­е­мо­го баке­та. В рам­ках это­го зада­ния мы долж­ны создать бакет, куда мы смо­жем загру­жать фай­лы, доступ­ные для ска­чи­ва­ния кому угод­но, то есть пуб­лич­ное хранилище.

Для нача­ла перей­дём в служ­бу S3 и нажмём на Create Bucket. В пер­вом шаге надо вве­сти уни­каль­ное имя и выбрать регион:

созда­ём поли­ти­ку на удаление:

 

Теперь надо создать роль IAM.

 

Вер­нём­ся к спис­ку инстан­сов, выбе­рем наш и изме­ним IAM роль: Actions -> Security -> Modify IAM Role.

под­клю­ча­ем­ся и про­ве­ря­ем доступ­ность S3 бакета

[ec2-user@ip-10-5-1-78 ~]$ aws s3 ls s3://and-bucket
[ec2-user@ip-10-5-1-78 ~]$

Гото­во, там пусто. Теперь загру­зим любой файл при помо­щи коман­ды copy и про­ве­рим его нали­чие преды­ду­щей командой.

[ec2-user@ip-10-5-1-78 ~]$ touch test-file
[ec2-user@ip-10-5-1-78 ~]$ aws s3 cp test-file s3://and-bucket/
upload: ./test-file to s3://and-bucket/test-file
[ec2-user@ip-10-5-1-78 ~]$ aws s3 ls s3://and-bucket
2021-09-19 13:57:47 0 test-file

как видим всё ок:

 

3.Auto scaling group -  горизонтальное масштабирование

3.1 Target Groups

 

Что­бы осво­ить балан­си­ров­ку нагруз­ки и мас­шта­би­ро­ва­ние, созда­дим и настро­им груп­пу сер­ве­ров для про­сто­го веб-приложения.
Для нача­ла, созда­дим Target Group - целе­вую груп­пу. Сде­лать это мож­но в раз­де­ле Load Balancing сер­ви­са EC2

зада­ём имя группы

далее не забы­ва­ем ука­зать нашу VPC

Груп­па гото­ва, но совер­шен­но пуста. Перей­дём во вклад­ку Instances и запу­стим Launch Wizard, нажав на “Launch”/

Созда­ём инстанс как ука­за­но в дан­ной инструкции:
1.4 Instance - Созда­ние сер­ве­ра в пуб­лич­ной и при­ват­ной сетях
исполь­зу­ем сле­ду­ю­щие данные:

• AMI: Amazon Linux 2
• Type: t2.micro
• Number of Instances: 2
• Subnet: pubclic
• User Data:

создай­те ещё сер­вер с таки­ми же настрой­ка­ми, но уже в дру­гой Availability Zone. Ваши под­се­ти могут отли­чать­ся - это неваж­но, но важ­но, что­бы сер­ве­ра были в раз­ных под­се­тях одно­го региона.

Сер­ве­ра созда­ны, но не добав­ле­ны в груп­пу, давай­те сде­ла­ем это. Перей­ди­те в Target Groups и выбе­ри­те нашу группу.

Нажми­те на “Register targets“, выбе­ри­те создан­ные сер­ве­ра и добавь­те их, нажав на “Include as pending below”. Завер­ши­те реги­стра­цию целей кноп­кой “Register pending targets”.

После того как груп­па сфор­ми­ро­ва­на, необ­хо­ди­мо под­клю­чить балан­си­ров­щик. Перей­дём во вклад­ку “Load Balancers” и созда­дим новый

3.2 Load Balancer

Ука­жи­те любое под­хо­дя­щее назва­ние для балан­си­ров­щи­ка. Нам потре­бу­ет­ся “Internet-facing” балан­си­ров­щик с под­держ­кой IPv4 Для Application Load Balancer будет авто­ма­ти­че­ски создан listener на порт 80. Это­го доста­точ­но, здесь нече­го менять

Далее необ­хо­ди­мо выбрать зоны доступ­но­сти, мини­мум две. Выбор зон осу­ществ­ля­ет­ся через выбор под­се­тей, посколь­ку каж­дая под­сеть отно­сит­ся к конкретной

В раз­де­ле Security Groups созда­дим новую груп­пу спе­ци­аль­но для это­го балан­си­ров­щи­ка. Пока что про­сто раз­ре­шим все вхо­дя­щие соеди­не­ния по пор­ту 80.

сохра­ня­ем, пере­хо­дим на преды­ду­щую вклад­ку и выби­ра­ем на security group

В сле­ду­ю­щем шаге нам нуж­но ука­зать целе­вую груп­пу. Выби­ра­ем “Exisistring Target Group” и ука­зы­ва­ем нашу группу

как видим всё ок, теперь про­ве­рим по наше­му домен­но­му име­ни кото­рое выдал Load balancer

http://andr-lb-1512071376.us-east-2.elb.amazonaws.com/

как видим если обно­вить то выда­ют­ся дан­ные с раз­ных инстансов(с раз­ных зон доступности)

Так как ранее мы настро­и­ли Security group для наших сер­ве­ров с пуб­лич­ным досту­пом то наши instans доступ­ны и по сво­им пуб­лич­ным IP адресам:

Настроим доступ ТОЛЬКО с Load balancer

Созда­дим security group с досту­пом по 80 пор­ту ТОЛЬКО с security group наше­го баллансировщика

 

далее уда­лим теку­щую security group

и доба­вим создан­ную from-load-ballance-to-instance

для вто­ро­го сер­ве­ра дела­ем тоже самое.

всё теперь по пуб­лич­но­му айпиш­ни­ку наши instance недоступны

доступ­ны толь­ко по домен­но­му имени:

http://andr-lb-1512071376.us-east-2.elb.amazonaws.com/

 

3.3 Launch Templates

Для настрой­ки авто­ма­ти­зи­ро­ван­но­го мас­шта­би­ро­ва­ния инфра­струк­ту­ры нам пона­до­бит­ся шаб­лон запуска

Перей­дём в Instances -> Launch Templates (Обра­ти­те вни­ма­ние, не Configurations, а имен­но Templates - Configurations счи­та­ют­ся уста­рев­ши­ми и вытес­не­ны шаблонами)

В каче­стве AMI ука­жем Amazon Linux 2, а тип инстан­са - t2.micro (помни­те, что это един­ствен­ный тип, под­хо­дя­щий под усло­вия Free Tier.) Добавь­те KeyPair, если пла­ни­ру­е­те исполь­зо­вать SSH, но в рам­ках это­го моду­ля нам подой­дёт и EC2 Connect.

В настрой­ках сети выбе­ри­те VPC - это более про­дви­ну­тый спо­соб, заме­ща­ю­щий уста­рев­ший EC2 Classic. Важ­но: в Security Groups добавь­те груп­пу, кото­рую мы будем исполь­зо­вать для настрой­ки досту­па балан­си­ров­щи­ка к инстан­сам целе­вой группы.

Очень важ­ная настрой­ка в Advanced Details: добавь­те уже зна­ко­мый скрипт в User Data.

гото­во

 

3.4 Autoscaling Group

 

В сле­ду­ю­щем шаге мы можем выбрать вари­ан­ты исполь­зу­е­мых инстан­сов: при­ме­нять выбор из шаб­ло­на или ком­би­ни­ро­вать он-деманд и спот инстан­сы. выбе­рем более про­стой вари­ант, поэто­му выби­ра­ем “Adhere to launch template”.

далее мож­но создать load ballancer или исполь­зо­вать суще­ству­ю­щий, я выбе­ру исполь­зо­вать уже существующий:

ука­зы­ва­ем параметры:

и сохра­ня­ем:

гото­во.
как ниже мож­но уви­деть мы наш auto scaling group под­нял 3 instance и мак­си­мум смо­жет их уве­ли­чи­вать до 9 штук

на скрин­шо­те ниже мы можем уви­деть 5 instances это 2 наших под­ня­тых вруч­ную и 3 под­ня­тых с помо­щью auto scaling group

Что­бы убе­дить­ся, что всё работает

Сло­ма­ем пару сер­ве­ров, два спо­со­ба на выбор:

1. cat /dev/random > /dev/null (уве­ли­чим нагруз­ку на CPU и будет скейл до 9)
2. sudo systemctl stop nginx (оста­нав­ли­ва­ем служ­бу. При этом под­ни­мет­ся новый, а теку­щий уда­лит­ся и scale оста­нет­ся на 3-ёх)

как видим новые тач­ки поднимаются:

Уби­ра­ем нагруз­ку на CPU, что­бы scale упал до 3-ёх. Ждём око­ло 10 минут. Что­бы scale сра­бо­тал быст­рее нуж­но под­клю­чить плат­ный сер­вис - CloudWatch.

Не забы­ва­ем под­чи­щать за собой. Уда­ле­ние абстрак­ции - auto scaling group, уда­ля­ет авто­ма­ти­че­ски создан­ные им инстансы.