Azure срещу AWS - Разлика между виртуалната мрежа на Azure (VNet) и виртуалния частен облак на AWS (VPC)

Azure Virtual Network (VNet) срещу AWS Virtual Private Cloud (VPC)

Azure VNet срещу AWS VPC

Пътуването до облака започва с избор на доставчик на облак и предоставяне на частни мрежи или разширяване на тяхната локална мрежа. Клиентите, които искат да предоставят ресурсите си в облака, могат да избират от различните частни мрежи, предлагани от различните доставчици на облаци. Двете най-разгърнати частни мрежи са Virtual Network (VNet) и Virtual Private Cloud (VPC) съответно от Microsoft и Amazon. Този блог разглежда сходствата и разликите между тези две предложения за частни мрежи с цел информиране на потенциалните клиенти за това, което разграничава двете частни мрежи и подпомагане на тяхното решение за това какво е подходящо за натовареността им.

Amazon е водещ участник в областта на облачните изчислителни технологии и е създал пионер в много индустриални революционни услуги като EC2, VPC и др. Първоначалното предлагане на EC2-класическа платформа позволява на клиентите да изпълняват ек2 екземпляри в плоска глобална мрежа, споделена от всички клиенти, освен това имаше други атрибути, включително споделено наемане, ограничения на групите за сигурност и липса на списъци за контрол на достъпа до мрежата, засягат клиентите, съобразени със сигурността. Тогава AWS представи EC2-VPC, усъвършенствана платформа, която осигурява логически изолирана секция от AWS Cloud. AWS EC2-VPC поддържа Споделено / Специализирано наемане, Подобрена група за сигурност на мрежата / Контрол на достъп до мрежата и др., Enterprise клиенти и SMB клиенти спечелиха повече доверие в архитектурата на VPC и започнаха да приемат AWS по-добре от преди.

През 2013 г. Azure превърна фокуса си от просто доставчик на PaaS в пълноправен доставчик на IaaS, за да избегне конкурентното предимство и загубата на пазара. За да се конкурира с ранния стартов AWS, Azure представи много нови услуги и най-важното Виртуални мрежи, „логически изолирана мрежа“, VPC версията на Azure в рамките на своя Център за данни. Виртуалната мрежа на Azure наподобява VPC в много аспекти и всъщност се държи подобно в много случаи, но има и малко разлики.

Концептуално и Azure VNet, и AWS VPC предоставят основата за предоставяне на ресурси и услуга в облака. И двете мрежи предоставят еднакви градивни елементи, но със степен на променливост в изпълнението. Следва резюмето на някои от тези градивни елементи:

подмрежата

За ефективен дизайн и контрол на ресурси, разположени в облака, Azure VNet и AWS VPC разделят мрежите с подмрежи. AWS VPC обхваща всички зони за наличност (AZs) в този регион, следователно подмрежите в AWS VPC се картографират в зоните за достъпност (AZs). Подмрежа трябва да принадлежи само на един AZ и не може да обхване AZ. Подмрежите Azure VNet се определят от блока на IP адреса, който му е присвоен. Комуникациите между всички подмрежи в AWS VPC са през гръбнакът на AWS и са позволени по подразбиране. Подмрежите AWS VPC могат да бъдат или частни, или публични. Подмрежата е обществена, ако има прикачен интернет шлюз (IGW). AWS позволява само един IGW за VPC, а публичната подмрежа позволява на ресурсите, разположени в тях, да имат достъп до интернет. AWS създава VPC и подмрежи по подразбиране за всеки регион. Този VPC по подразбиране има подмрежи за всеки регион, където пребивава VPC, и на всяко изображение (EC2 инстанция), разположено в този VPC, ще бъде присвоен публичен IP адрес и следователно има интернет връзка. Azure VNet не предоставя VNet по подразбиране и няма частна или обществена подмрежа, както в AWS VPC. Ресурсите, свързани с VNet, имат достъп до Интернет по подразбиране.

Подмрежите са градивните елементи на частните мрежи. Подмрежите са чудесен начин за разделяне на по-голямата мрежа на много по-малки мрежи и поставянето на натовареността зависи от характера на данните, с които се занимава. AWS като доставчик на IaaS има зрели инструменти като техния портал за управление, шаблони за формиране в облак, CLI и програмируеми API за стартиране на подмрежи. AWS също така предоставя Wizards за автоматизиране на общите VPC архитектури като

  • VPC с единна обществена подмрежа
  • VPC с публични и частни подмрежи
  • VPC с публични и частни подмрежи и хардуерен VPN достъп
  • VPC с частна подмрежа и хардуерен VPN достъп

Това помага на потребителите да намалят значително времето за настройка на VPC и опростява целия процес. AWS прави създаването на сложни мрежи като детска игра с помощта на съветника, съобщава от EC2 случаи. Всеки, който иска да създаде и предостави многостепенно уеб приложение или всяко натоварване в публично-частна подмрежа за минути.

Виртуалната мрежа Azure също ни позволява да създаваме подмрежи от произволно количество, използвайки портала за управление, PowerShell, CLI. За разлика от AWS, azure понастоящем няма магьосници, които да създават общите архитектури като споменатите по-горе.

IP адреси

Както AWS VPC, така и Azure VNET използват не глобално прехвърлящ се CIDR от диапазоните на частните IPv4 адреси, както е посочено в RFC 1918 - адресите от този RFC не са глобално маршрутизирани - но клиентите все още могат да използват други публични IP адреси. Azure VNet присвоява ресурси, свързани и разгърнати към VNet частен IP адрес от посочения CIDR блок. В Azure VNet най-малката поддържана подмрежа е / 29, а най-голямата е / 8. AWS също така позволява IP адреси от същите RFC 1918 или публично рутируеми IP блокове. Понастоящем AWS не поддържа директен достъп до интернет от публично рутируеми IP блокове, следователно те не са достъпни от интернет дори през интернет шлюза (IGW). Те са достъпни само чрез виртуалния частен шлюз. Поради това, екземплярите на Windows не могат да се зареждат правилно, ако са стартирани в VPC с диапазони от 224.0.0.0 до 255.255.255.255 (IP адреси от клас D и клас E). За подмрежата AWS препоръчва минимален адресен блок от / 28 и максимум от / 16. Поддръжката на Microsoft Azure VNet за IPv6 е ограничена по време на писането на този блог, но AWS VPC поддържа IPv6 за всички региони, с изключение на Китай, от януари 2017 г. За IPv6 VPC е фиксиран размер / 56 (в нотация на CIDR) и размерът на подмрежата е фиксиран да бъде / 64. В IPv6 всеки адрес е подвижен за интернет и може да говори с Интернет по подразбиране. AWS VPC предоставя само изходен интернет шлюз (EGW) за ресурси в частната подмрежа. Той блокира входящия трафик, като същевременно позволява изходящ трафик. AWS позволява активирането на IPv6 за съществуващи ресурси, а за ресурси в частната подмрежа, които изискват достъп до интернет, е предоставен само портал за достъп от Интернет. Само порталът за достъп до интернет ще позволи достъп до интернет, но блокира всеки входящ трафик. Разбирането как да се разпределят IP адреси от тези блокове на CIDR е от ключово значение за създаването на AWS VPC мрежа, тъй като промяната на подмрежата IP адреси след проектирането не е тривиална. Azure VNet предлага повече гъвкавост в тази област - IP адресите на подмрежата могат да бъдат променени след първоначалния дизайн. Но ресурсите в текущата подмрежа ще трябва да бъдат мигрирани извън текущата подмрежа.

Таблица за маршрутизация

AWS използва таблицата на маршрутите, за да определи разрешените маршрути за изходящ трафик от подмрежата. Всички подмрежи, създадени в VPC, автоматично се свързват с основната таблица за маршрутизиране, следователно всички подмрежи в VPC могат да позволяват трафик от други подмрежи, освен ако изрично не са отказани от правилата за сигурност. В Azure VNet всички ресурси в VNet позволяват потока на трафика чрез използване на системния маршрут. Не е нужно да конфигурирате и управлявате маршрути, тъй като по подразбиране Azure VNet осигурява маршрутизация между подмрежи, VNets и локални мрежи. Използването на системни маршрути улеснява трафика автоматично, но има случаи, в които искате да контролирате маршрутизирането на пакетите чрез виртуален уред. Azure VNet използва таблицата на системния маршрут, за да гарантира, че ресурсите, свързани към която и да е подмрежа във всяка VNet, комуникират помежду си по подразбиране. Съществуват обаче сценарии, когато може да искате да отмените маршрутите по подразбиране. За такива сценарии можете да внедрите определените от потребителя маршрути (UDR) - контрол, където трафикът се пренасочва за всяка подмрежа - или / и BGP маршрути (вашият VNet към локалната ви мрежа с помощта на Azure VPN Gateway или ExpressRoute връзка). UDR се прилага само за трафик, напускащ подмрежата и може да осигури слой сигурност за разгръщане на Azure VNet, ако целта на UDR е да изпрати трафик към някакъв вид проверка NVA или други подобни. С UDR пакетите, изпратени до една подмрежа от друга, могат да бъдат принудени да преминат през мрежов виртуален уред по набор от маршрути. В хибридна настройка, Azure VNet може да използва някоя от трите маршрутни таблици - UDR, BGP (ако се използва ExpressRoute) и системни таблици за маршрутизиране. В Azure VNet подмрежата разчита на системните маршрути за своя трафик, докато таблицата на маршрутите не бъде изрично свързана с подмрежа. След като се установи асоциация, т.е. UDR и / или BGP маршрут съществува, маршрутизирането се извършва въз основа на Longest Prefix Match (LPM). В случаите, когато има повече от един маршрут с една и съща дължина на префикса, маршрут се избира въз основа на неговия произход в следния ред: Потребителски дефиниран маршрут, BGP маршрут (когато се използва ExpressRoute) и Системен маршрут. Докато в AWS VPC таблиците за маршрутизиране могат да бъдат повече от една, но от един и същи тип.

Персонализираните таблици за маршрутизиране съдържат списък с правила за маршрутизиране, за да определи как трафикът трябва да протича в подмрежата

В AWS всяка подмрежа трябва да бъде свързана с маршрутна таблица, която контролира маршрута за подмрежата. Ако не асоциирате изрично подмрежа с определена маршрутна таблица, подмрежата използва основната таблица на маршрута на VPC.

Windows Azure осигурява маршрутизиране по подразбиране в подмрежи в рамките на една виртуална мрежа, но не предоставя никакъв тип мрежова ACL възможност по отношение на вътрешните IP адреси. За да ограничат достъпа до машини в рамките на една виртуална мрежа, тези машини трябва да използват защитната стена на Windows с разширена защита (вижте диаграмата).

Microsoft трябва да готви тази функция в кухните си. Очакваме скоро тази вкусна функция в ресторант Azure.

Сигурност

AWS VPC осигурява две нива на сигурност за ресурси, внедрени в мрежата. Първата се нарича групи за сигурност (SG). Групата за сигурност е състоятелен обект, който се прилага на ниво инстанция EC2 - технически правилото се прилага на ниво Elastic Network Interface (ENI). Трафикът на отговор се разрешава автоматично, след като трафикът е разрешен. Вторият механизъм за защита се нарича Контрол на достъп до мрежа (NACL). NACL са правила за филтриране без състояние, които се прилагат на ниво подмрежа и се прилагат за всеки ресурс, разположен в подмрежата. Той е без гражданство, защото ако е разрешен входящ трафик, отговорът не е разрешен автоматично, освен ако изрично не е разрешено в правилото за подмрежата. NACL работят на ниво подмрежа, като изследват трафика, влизащ и излизащ от подмрежата. NACL могат да се използват за задаване както на Allow и Deny правила. Можете да свържете NACL с множество подмрежи; подмрежа обаче може да бъде асоциирана само с един NACL наведнъж. Правилата на NACL се номерират и оценяват, за да се започне с правилото с най-ниска номерировка, за да се определи дали трафикът е разрешен във или извън някоя подмрежа, свързана с мрежовия ACL. Най-голямото число, което можете да използвате за правило, е 32766. Последното номерирано правило винаги е звездичка и отказва трафик към подмрежата. Забележете, стигате до това правило само ако нито едно правило от списъка на NACL не съответства на трафика. Azure VNet осигурява групи за мрежова сигурност (NSGs) и комбинира функциите на AWS SGs и NACL. NSG са състоятелни и могат да се прилагат на ниво подмрежа или NIC. Само един NSG може да бъде приложен към NIC, но в AWS можете да приложите повече от една група за сигурност (SG) към еластичен мрежов интерфейс (ENI).

Сигурността е основната движеща сила, поради която виртуалната мрежа е предпочитана пред обществените крайни точки. AWS предоставя различни услуги за виртуална сигурност, за да осигури максимална сигурност както на ниво виртуална инстанция, ниво на подмрежа, така и на цялостно ниво на мрежата.

Група за сигурност

AWS „Групи за сигурност“ помага за защита на случаи чрез конфигуриране на входящи и изходящи правила. Потребителите могат да конфигурират кои портове да се отворят, за да приемат трафик от какъв източник и по подобен начин да конфигурират изходящи портове от EC2 случаи.

Конвенцията за именуване на Azure е „Група за сигурност на мрежата“ понастоящем е достъпна само за регионални виртуални мрежи (Прочетете каква е регионалната мрежа) и не е достъпна за VNet, който е свързан с Affinity Group. Можете да имате максимум 100 NSG на абонамент (надявам се, че това е твърдо наложеното ограничение, MSDN не го обяснява допълнително).

AWS ни позволява да създадем 200 групи за сигурност за VPC, например ако имате 5 VPC, можете да създадете общо 200 * 5 = 1000 групи за сигурност, но групите за сигурност в двата облака не могат да обхващат региони.

За разлика от AWS, групата за мрежова сигурност на Azure може да бъде асоциирана към VM Instance, подмрежи и хибрид, т.е. (подмрежа и VM), това е мощна многослойна защита, която може да получи VM, щракнете тук, за да прочетете повече. Понастоящем Azure не предлага потребителски интерфейс за добавяне / редактиране на групи за сигурност, така че потребителите трябва да използват API на PowerShell и REST, за да настроят едно и също (вижте по-долу Powershell Workflow).

Мрежови ACLS

Azure и AWS поддържа списък за контрол на мрежовия достъп. ACL позволяват на потребителите избирателно да разрешават или отказват трафик към вашите мрежи. И двете облаци го заявяват като подобрение или незадължителен механизъм за защита отгоре на групите за сигурност и други механизми за сигурност. ACL в лазурен цвят понастоящем е ограничено до осигуряване на крайни точки (Какво е крайни точки) и не предлага същата гъвкавост и контрол, както AWS предоставя.

Докато пишете тази статия, можете да създавате мрежови ACL само с помощта на командите Powershell и REST API. ACL в AWS ни позволява да зададем контрол на достъпа на ниво подмрежа, т.е. ако разрешите http трафик на подмрежа, всички EC2 инстанции в подмрежата могат да получават HTTP трафик, но ако сте конфигурирали да не позволяват HTTP трафик в определени EC2 тези трафикът ще бъде филтриран от групите за сигурност. Мрежовите ACL на Azure се държат почти подобно, освен че работят за крайна точка.

Забележка: Azure препоръчва или Списък за контрол на мрежовия достъп или група за сигурност, не и двете едновременно, тъй като функционално те правят същото. Ако сте конфигурирали мрежовия ACL и искате да преминете към групи за сигурност, първо трябва да премахнете ACL за крайни точки и да конфигурирате група за сигурност.

Свързаност

Gateways

Както VNet, така и VPC предлагат различни шлюзове за различни цели на свързване. AWS VPC използва предимно три шлюза, четири, ако добавите NAT шлюза. AWS позволява на един Internet Gateway (IGW) да осигури свързаност с интернет чрез IPv4 и само за Egress Internet Gateway за интернет свързаност към ресурси с IPv6. В AWS всяка подмрежа без IGW се счита за частна подмрежа и няма интернет свързаност без NAT шлюз или NAT екземпляр (AWS препоръчва NAT Gateway за висока наличност и мащабируемост). Друг AWS шлюз, Virtual Private Gateway (VPG) позволява на AWS да осигури свързаност от AWS към други мрежи чрез VPN или Direct Connect. В мрежата, която не е AWS, AWS изисква Customer Gateway (CGW) от страна на клиента, за да се свърже към AWS VPC. Azure VNet предоставя два типа шлюз, а именно VPN Gateway и ExpressRoute Gateway. Шлюзът VPN позволява криптиран трафик за VNet към VNet или VNet до локално местоположение през обществена връзка или през гръбнака на Microsoft в случай на VNet към VNet VPN. Обаче ExpressRoute и VPN Gateway също изискват подмрежа на шлюза. Подмрежата на шлюза съдържа IP адресите, които услугите на шлюза на виртуалната мрежа използват. Azure VNET към VNET може да се свърже изначално чрез VPN, но в AWS, такъв VPC към VPC изисква трета страна NVA, ако VPC са в различни региони.

Хибридна свързаност

И AWS VPC, и Azure VNet позволяват хибридни връзки, използвайки съответно VPN и / или Direct Connect и ExpressRoute. С Direct Connect или ExpressRoute са налични връзки до 10Gbps. AWS DC връзка се състои от единична специална връзка между портовете на вашия рутер и Amazon маршрутизатор. С една DC връзка можете да създавате виртуални интерфейси директно към обществени AWS услуги (например към Amazon S3) или към Amazon VPC. Преди да използвате AWS DC, трябва да създадете виртуален интерфейс. AWS позволява 50 виртуални интерфейса на AWS Direct Connect връзка и това може да се увеличи, като се свържете с AWS. AWS DC връзката не е излишна и е необходима втора връзка, ако се изисква съкращаване. AWS VPN създава два тунела между AWS VPC и локалната мрежа. За да осигури толерантност на грешките за Direct Connect, AWS препоръчва да се използва един от тунелите за свързване към локалната мрежа за данни чрез VPN и BGP. Azure ExpressRoute също осигурява две връзки и SLA за свързаност - Azure гарантира минимум 99.95% наличност на ExpressRoute Dedicated Circuit - и следователно предсказуема производителност на мрежата.

Интер свързаността позволява на различни мрежи да се свързват помежду си. Облачните доставчици предлагат 3 основни опции за свързване

Директна интернет връзка - AWS позволява на потребителите да свързват публични IP адреси към EC2 случаи там, като позволяват интернет връзка към тези машини и подобно VM в частната подмрежа да получат достъп до интернет чрез маршрутизиране през NAT в публичната подмрежа.

Azure позволява на потребителите да конфигурират обществени крайни точки, известни като Public IP адреси към VM в подмрежата, като по този начин VMS може да бъде свързан с други системи.

VPN over IPsec - VPN over IPsec е IP базирана методология за свързване за свързване на две различни мрежи, независимо от мрежи в облак / извън, облак към локална мрежа и т.н., като цяло има два типа протоколи за маршрутизиране на VPN, използвани 1. Статичен протокол за маршрутизиране 2. Протокол за динамична маршрутизация.

Azure и AWS предоставят поддръжка за статична и динамична маршрутизация, но Azure в този момент не поддържа активна поддръжка на маршрутизация (BGP), но Azure публикува огромен списък от производители на VPN устройства, които поддържат маршрутизиране на BGP.

Частна свързаност чрез Exchange Provider - Опция за частно свързване, фокусирана основно към корпоративни клиенти, които имат голяма натоварване на честотната лента. Частната връзка от интернет доставчиците може да осигури много по-добра производителност от Интернет. И AWS, и Azure си партнират с големи телекомуникационни и ISV-та, за да предложат частна връзка между облаците и клиентската инфраструктура. Azure поддържа повечето от техните функции чрез Express Route, с изключение на някои функции като Service Bus, CDN, RemoteApp, Push Notifications и др. (Щракнете тук, за да прочетете повече). По същия начин AWS поддържа всички AWS услуги, включително Amazon Elastic Compute Cloud (EC2), Amazon Virtual Private Cloud (VPC), Amazon Simple Storage Service (S3) и Amazon DynamoDB могат да се използват с AWS Direct Connect. Що се отнася до SLA, AWS не предоставя SLA за тази услуга, но Azure от друга страна обещава 99,9% SLA, в противен случай клиентът може да поиска кредитни услуги.

Честито облаче !!!