Навіщо нам потрібна приватна підмережа в VPC?

У налаштуваннях AWS VPC є 4 сценарії . Але давайте розглянемо ці два:

• Сценарій 1: 1 загальнодоступна підмережа.
• Сценарій 2: 1 загальнодоступна підмережа та 1 приватна підмережа.

Оскільки будь-який екземпляр, запущений у загальнодоступній підмережі, не має EIP (якщо він не призначений), він вже не може бути адресований через Інтернет. Тоді:

• Чому потрібна приватна підмережа?
• Які саме відмінності між приватною та публічною підмережами?

Оновлення: наприкінці грудня 2015 року AWS оголосила про нову функцію - керований NAT шлюз для VPC . Цей необов'язковий сервіс забезпечує альтернативний механізм для випадків VPC в приватній підмережі для доступу до Інтернету, де раніше загальним рішенням був екземпляр EC2 у публічній підмережі в межах VPC, функціонуючи як "екземпляр NAT", забезпечуючи переклад мережевих адрес ( технічно - переклад адрес порту ) для примірників інших приватних підмереж, що дозволяє цим машинам використовувати публічну IP-адресу екземпляра NAT для виходу з Інтернету.

Новий керований сервіс NAT принципово не змінює застосовність наступної інформації, однак ця опція не розглядається у наведеному нижче змісті. Екземпляр NAT все ще може використовуватися, як описано, або замість цього може бути надана служба керованого NAT шлюзу. Подана розширена версія цієї відповіді, що містить більше інформації про NAT Gateway та про те, як він порівнює з екземпляром NAT, оскільки вони мають відношення до парадигми приватної / публічної підмережі в VPC.

Зауважте, що Internet Gateway та NAT Gateway - це дві різні функції. Усі конфігурації VPC з доступом до Інтернету матимуть віртуальний об'єкт Internet Gateway.

Щоб зрозуміти різницю між "приватною" та "публічною" підмережами в Amazon VPC, потрібно зрозуміти, як працюють маршрутизація IP та трансляція мережевих адрес (NAT) взагалі та як вони спеціально реалізовані в VPC.

Основна диференціація між публічною та приватною підмережею в VPC визначається тим, яким є маршрут за замовчуванням цієї підмережі, у таблицях маршрутизації VPC.

Ця конфігурація, в свою чергу, диктує дійсність використання або не використання публічних IP-адрес у випадках у цій конкретній підмережі.

Кожна підмережа має рівно один маршрут за замовчуванням, який може бути лише однією з двох речей:

• об’єкт "Інтернет-шлюз" VPC у випадку "загальнодоступної" підмережі, або
• пристрій NAT - тобто або шлюз NAT, або екземпляр EC2, який виконує роль "екземпляра NAT", у випадку "приватної" підмережі.

Інтернет - шлюз робить ніякого перетворення мережевих адрес для примірників без яких IP - адрес , тому екземпляр без IP адреси громадськості не може підключитися назовні до Інтернету - робити такі речі , як завантаження оновлень програмного забезпечення, або доступ до інших AWS ресурсів , таким як S3 ¹ і SQS - якщо маршрут за замовчуванням у його підмережі VPC є об'єктом Internet Gateway. Отже, якщо ви є екземпляром у "загальнодоступній" підмережі, тоді вам потрібна загальнодоступна IP-адреса, щоб зробити значну кількість речей, які зазвичай повинні робити сервери.

Для випадків із приватною IP-адресою існує альтернативний вихідний доступ до Інтернету. Тут надходять мережеві переклади2 і екземпляр NAT.

Машини приватної підмережі можуть отримувати доступ до Інтернету, оскільки маршрут за замовчуванням у приватній підмережі не є об’єктом VPC "Internet Gateway" - це екземпляр EC2, налаштований як екземпляр NAT.

Екземпляр NAT - це екземпляр у загальнодоступній підмережі з загальнодоступним IP-адресою та певною конфігурацією. Є AMI, які попередньо створені для цього, або ви можете створити свій власний.

Коли машини з приватною адресою надсилають трафік назовні, трафік передається VPC до екземпляра NAT, який замінює вихідну IP-адресу в пакеті (приватну IP-адресу приватної машини) своєю власною загальнодоступною IP-адресою, передає трафік. з Інтернету, приймає пакети відповідей і пересилає їх назад на приватну адресу машини-виробника. (Він також може переписати вихідний порт, і в будь-якому випадку він запам'ятовує відображення, щоб він знав, яка внутрішня машина повинна отримувати пакети відповідей). Екземпляр NAT не дозволяє жодному "несподіваному" вхідному трафіку діставатися до приватних примірників, якщо тільки це не було спеціально налаштовано для цього.

Таким чином, під час доступу до зовнішнього ресурсу Інтернету з приватної підмережі, трафік проходить через екземпляр NAT і, здається, до місця призначення, походить із загальнодоступної IP-адреси інстанції NAT ... так що трафік відповідей повертається до екземпляра NAT. Ні група безпеки, призначена для екземпляра NAT, ні група безпеки, призначена приватному екземпляру, не повинні бути налаштовані так, щоб "дозволити" цей трафік відповідей, оскільки групи безпеки є статними. Вони розуміють, що трафік відповідей пов'язаний із сеансами, що виникли всередині країни, тому він дозволений автоматично. Несподіваний трафік, звичайно, відмовляється, якщо група безпеки не налаштована на дозвіл.

На відміну від звичайної маршрутизації IP, де ваш шлюз за замовчуванням знаходиться у вашій підмережі, спосіб його роботи в VPC відрізняється: екземпляр NAT для будь-якої приватної підмережі завжди знаходиться в іншій підмережі, а інша підмережа завжди є публічною підмережею, оскільки екземпляр NAT повинен мати відкритий зовнішній IP, і його шлюзом за замовчуванням повинен бути об’єкт VPC "Internet Gateway".

Аналогічно ... ви не можете розгорнути примірник із загальнодоступним IP в приватній підмережі. Це не працює, оскільки маршрут за замовчуванням у приватній підмережі - це (за визначенням) екземпляр NAT (який виконує NAT у трафіку), а не об'єкт Internet Gateway (що не робить). Вхідний трафік з Інтернету впливав би на загальнодоступну IP-адресу цього примірника, але відповіді намагалися прокласти назовні через екземпляр NAT, який би або скинув трафік (оскільки він буде складатися з відповідей на з'єднання, про які він не знає, тому вони вважатиметься недійсним) або переписував би трафік відповіді на використання власної загальнодоступної IP-адреси, яка не працювала б, оскільки зовнішнє походження не приймало б відповідей, що надходили з IP-адреси, відмінної від тієї, з якою вони намагалися ініціювати зв’язок. .

По суті, тоді "приватні" та "публічні" позначення насправді не стосуються доступності чи недоступності з Інтернету. Йдеться про види адрес, які будуть присвоєні примірникам цієї підмережі, що актуально через необхідність перекладати - або уникати перекладу - тих IP-адрес для взаємодії в Інтернеті.

Оскільки VPC має неявні маршрути від усіх підмереж VPC до всіх інших підмереж VPC, маршрут за замовчуванням не грає ролі у внутрішньому трафіку VPC. Екземпляри з приватними IP-адресами підключатимуться до інших приватних IP-адрес у VPC "від" їх приватної IP-адреси, а не "від" їхньої загальнодоступної IP-адреси (якщо у неї є) ... до тих пір, поки адреса призначення буде іншою приватною адресою в межах VPC.

Якщо ваші примірники з приватними IP-адресами ні за яких обставин не потребують вихідного інтернет-трафіку, вони технічно можуть бути розгорнуті в "загальнодоступній" підмережі і все ще будуть недоступними для Інтернету ... але за такої конфігурації, їм неможливо породжувати вихідний трафік до Інтернету, який включає з'єднання з іншими інфраструктурними службами AWS, знову ж таки, як S3 ¹ або SQS.

^{1. Зокрема, щодо S3 сказати, що завжди потрібен доступ до Інтернету - це надмірне спрощення, яке, ймовірно, зростатиме з часом і поширюватиметься на інші служби AWS, оскільки можливості VPC продовжують зростати та розвиватися. Існує порівняно нова концепція, яка називається VPC Endpointщо дозволяє вашим екземплярам, ​​включаючи лише приватні IP-адреси, безпосередньо отримувати доступ до S3 з вибраних підмереж в VPC, не торкаючись "Інтернету" і не використовуючи примірник NAT або шлюз NAT, але це вимагає додаткової конфігурації, і це доступний лише для доступу до відра у тому ж регіоні AWS, що і ваш VPC. За замовчуванням S3 - це єдиний сервіс, який виявив можливість створення кінцевих точок VPC - доступний лише зсередини VPC через Інтернет. Коли ви створюєте кінцеву точку VPC, це створює список префіксів (pl-xxxxxxxx), яку ви можете використовувати у своїх таблицях маршрутів VPC, щоб надсилати трафік, пов'язаний для цієї конкретної послуги AWS, безпосередньо до служби через віртуальний об'єкт "VPC Endpoint". Він також вирішує проблему обмеження вихідного доступу до S3 для конкретного екземпляра, оскільки список префіксів може використовуватися у вихідних групах безпеки, замість цільової IP-адреси або блоку призначення, а кінцева точка VPC S3 може бути предметом додаткових заяв про політику , обмежуючи доступ до ковша зсередини, за бажанням.}

^{2. Як зазначено в документації, тут фактично обговорюється порт, а також переклад мережевих адрес. Загальноприйнято, хоча і технічно трохи неточно, називати комбіновану операцію "NAT". Це дещо схоже на те, як багато хто з нас схильні говорити "SSL", коли ми маємо на увазі "TLS". Ми знаємо, про що говоримо, але не використовуємо найбільш правильне слово для його опису. "Примітка. У цій документації ми використовуємо термін NAT для дотримання загальної практики ІТ, хоча фактична роль NAT-пристрою - це і переклад адрес, і переклад адрес порту (PAT)."}

Я б запропонував інший такт - канаву "приватних" підмереж та NAT-екземпляри / шлюзи. Вони не потрібні. Якщо ви не хочете, щоб машина була доступною з Інтернету, не ставте її до групи безпеки, яка дозволяє такий доступ.

Викидаючи примірник / шлюз NAT, ви виключаєте поточну вартість екземпляра / шлюзу, і ви усуваєте обмеження швидкості (будь то 250 Мбіт або 10 Гбіт).

Якщо у вас є машина, яка також не потребує прямого доступу до Інтернету (і я б запитав, як ви її виправляєте *), тоді, не призначайте загальнодоступну IP-адресу.

* Якщо відповідь тут - це якийсь проксі, ну ви несете накладні витрати, але кожен свій.

Я не маю репутації додавати коментар до відповіді Майкла вище, отже, додаючи мій коментар як відповідь.

Варто зазначити, що шлюз, керований AWS, у 3 рази дорожчий на дату порівняно із запуском власного екземпляра. Звичайно, якщо припустити, що вам потрібен лише один екземпляр NAT (тобто у вас немає декількох екземплярів NAT, налаштованих для відмови тощо), що, як правило, справедливо для більшості сценаріїв малого та середнього використання. Припускаючи щомісячну передачу даних 100 Гб через NAT-шлюз,

Щомісячна вартість керованого екземпляру NAT = $ 33,48 / місяць ($ 0,045 / годину * 744 години на місяць) + 4,50 $ (0,045 $ за ГБ, оброблювані дані * 100 ГБ) + 10 $ ($ 10,10 / ГБ стандартні тарифи за передачу даних AWS за всі дані, передані через NAT шлюз) = $ 47,98

t2.nano екземпляр, сконфігурований як екземпляр NAT = 4,84 дол. США на місяць (0,0065 дол. США * 744 години на місяць) + 10 дол.

Це, звичайно, змінюється, коли ви звертаєтесь до надмірних екземплярів NAT, оскільки на шлюзі NAT, керованого AWS, є вбудована надмірність для високої доступності. Якщо ви не турбуєтесь про зайві $ 33 / місяць, то керований екземпляр NAT, безумовно, варто зменшити головний біль, коли не потрібно підтримувати інший екземпляр. Якщо ви використовуєте екземпляр VPN (наприклад, OpenVPN) для доступу до своїх примірників в VPC, ви можете просто налаштувати цей екземпляр, щоб він також виконував роль шлюзу NAT, і тоді вам не доведеться підтримувати додатковий екземпляр лише для NAT ( хоча деякі люди можуть нахмуритися ідеєю поєднання VPN та NAT).

Відповідь Майкла - sqlbot робить неявне припущення, що потрібні приватні IP-адреси. Я вважаю, що варто засумніватися в цьому припущенні - чи нам взагалі потрібно використовувати приватні IP-адреси? Принаймні один коментатор задав те саме питання.

Яка перевага сервера в приватній підмережі з екземпляром NAT [проти] сервера [в a] публічній підмережі із суворою політикою безпеки? - abhillman 24 червня 14 о 23:45

Уявіть собі сценарій, коли ви використовуєте VPC і призначаєте загальнодоступні IP-адреси для всіх своїх екземплярів EC2. Не хвилюйтеся, це не означає, що вони обов'язково доступні через Інтернет, тому що ви використовуєте групи безпеки для обмеження доступу точно так само, як це працювало з EC2 classic. Використовуючи загальнодоступні IP-адреси, ви маєте перевагу в тому, що зможете легко піддавати певні послуги обмеженій аудиторії без необхідності використовувати щось на зразок ELB. Це звільняє вас від необхідності налаштування екземпляра NAT або шлюзу NAT. А оскільки вам потрібно вдвічі більше підмереж, ви можете вибрати менший розподіл CIDR для свого VPC або ви можете зробити більші підмережі з однаковим розміром VPC. А менше підмереж означає, що ви також платите менше за трафік між АЗ.

То чому б ми цього не зробили? Чому AWS каже, що найкращою практикою є використання приватних ІС?

Amazon Web Services має обмежений запас публічних IPv4-адрес, оскільки Інтернет в цілому має обмежений доступ до публічних IPv4-адрес. Вам цікаво використовувати приватні IP-адреси, які фактично необмежені, а не надмірно споживають обмежені публічні IPv4-адреси. Ви можете побачити деякі докази цього в тому, як AWS ціни на Elastic IP; EIP, приєднаний до примірника, є безкоштовним, але невикористаний EIP коштує грошей.

Але заради аргументу, припустимо, що нас не хвилює дефіцит загальнодоступних IPv4 адрес в Інтернеті. Адже моя заява особлива. Що буде далі?

Є лише два способи приєднати публічну IP-адресу до екземпляра EC2 у VPC.

1. Асоційована публічна IP-адреса

Ви можете запитувати публічну IP-адресу під час запуску нового екземпляра EC2. Цей параметр відображається як прапорець у консолі, як прапор --associate-public-ip-адреси при використанні aws-cli, і як прапор AssociatePublicIpAddress на вбудованому об’єкті мережевого інтерфейсу при використанні CloudFormation. У будь-якому випадку публічна IP-адреса призначається eth0(DeviceIndex = 0). Цей підхід можна використовувати лише при запуску нового примірника. Однак це має деякі недоліки.

Недоліком є ​​те, що зміна групи захисту екземпляра, який використовує вбудований мережевий інтерфейс, змусить негайно замінити екземпляр, принаймні, якщо ви використовуєте CloudFormation.

Ще одним недоліком є ​​те, що присвоєна таким чином публічна IP-адреса втрачається при зупинці примірника.

2. Еластичний IP

Загалом, переважним підходом є еластичні ІС, оскільки вони безпечніші. Ви гарантовано продовжуєте використовувати ту саму IP-адресу, ви не ризикуєте випадково видалити будь-які екземпляри EC2, ви можете будь-коли вільно приєднати / зняти Elastic IP, і у вас є свобода змінювати групи безпеки, застосовані до ваших екземплярів EC2.

... Але AWS обмежує вас до 5 EIP на регіон. Ви можете запитувати більше, і ваш запит може бути задоволений. Але AWS так само ймовірно може відмовити в цьому запиті, виходячи з міркувань, про які я згадував вище. Тому ви, мабуть, не хочете покладатися на EIP, якщо плануєте коли-небудь масштабувати свою інфраструктуру понад 5 екземплярів EC2 на регіон.

На закінчення, використання загальнодоступних IP-адрес має певні переваги, але ви зіткнетесь з адміністративними проблемами чи масштабуванням, якщо ви будете намагатися використовувати лише публічні IP-адреси. Сподіваємось, це допомагає проілюструвати та пояснити, чому найкращі практики такі, якими вони є.