Що рекомендується CIDR при створенні VPC на AWS?

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

Я рекомендую наступні міркування:

Якщо ви створюєте IPSEC-з'єднання між корпоративною локальною мережею та VPC, використовуйте CIDR, який відрізняється від того, який використовується у вашій корпоративній локальній мережі. Це запобіжить перекриття маршрутизації та створить розрізнення ідентичності для довідки.

Для дуже великих мереж використовуйте принаймні різні 16-бітові маски в різних регіонах, наприклад

eu-west-1 10.1.0.0/16
us-east-1 10.2.0.0/16
us-west-1 10.3.0.0/16

Для менших мереж використовуйте 24-бітну маску в різних регіонах, наприклад

eu-west-1 10.0.1.0/24
us-east-1 10.0.2.0/24
us-west-1 10.0.3.0/24

Розглянемо можливість розмежування приватних та публічних підмереж, наприклад

private 10.0.1.0/24 (3rd byte < 129)
public 10.0.129.0/24 (3rd byte > 128)

Не перерозподіляйте адресний простір підмережам, наприклад

eu-west-1 10.0.1.0/26
eu-west-1 10.0.1.64/26
eu-west-1 10.0.1.128/26
eu-west-1 10.0.1.192/26

(62 hosts per subnet)

Не виділяйте їх також. Якщо ви використовуєте навантаження еластичних балансирів навантаження, пам’ятайте, що вони також будуть споживати доступні ip-адреси у ваших підмережах. Це особливо вірно, якщо ви використовуєте ElasticBeanstalk.

Деякі речі, які я розглядав востаннє, коли я створював новий VPC:

1. Переконайтесь, що діапазони IP-адрес у різних регіонах не перетинаються. Ви не повинні мати 172.31.0.0/16ін us-west eu-ireland, наприклад. Це зробить VPN між цими двома регіонами проблемою, для вирішення якої потрібен подвійний NAT. Ні, дякую.
2. Переконайтеся, що діапазон IP досить великий, щоб вмістити всі екземпляри, які, на вашу думку, знадобляться x.x.x.x/24, вміщатимуть 254 різних адреси. Напевно, є сотні калькуляторів CIDR, які допоможуть вам зрозуміти це.
3. Я створюю багато різних підмереж в одному VPC, а не створюю декілька VPC. Підмережі можуть спілкуватися один з одним - я можу мати приватні та загальнодоступні підмережі, щоб зберігати деякі випадки, захищені від відкритого Інтернету. Використовуйте екземпляр NAT, щоб приватна підмережа могла спілкуватися із загальнодоступною підмережею. Використовуйте групи безпеки, щоб ізолювати групи примірників один від одного.

Amazon, здається, не рекомендує конкретного розміру мережі для вашого VPC (див . Посібник адміністратора мережі VPC та відзначимо використання / 16s), але загалом є дві причини врахувати ефективність CIDR на ефективність:

1. Маршрутизація . Менший префікс (більша мережа) часто використовується для агрегації маршрутів і може фактично підвищити продуктивність.
2. Трансляція та багатоадресова передача , що більше відповідає вашій ситуації та може призвести до зниження продуктивності для менших префіксів. Ви можете пом'якшити наслідки цього трафіку шляхом подальшої підмережі VPC, як показано в посібнику адміністратора мережі.

Розгляньте початкову кількість вузлів у вашому VPC та прогнозований приріст протягом очікуваного терміну експлуатації проекту, і ви повинні мати хорошу вихідну точку для розміру префікса. Пам’ятайте, що починати з невеликого префіксу типу / 16 немає шкоди, оскільки ви завжди можете створювати підмережі.

Інша думка полягає в тому, чи потрібно вам використовувати AWS ClassicLink, щоб дозволити доступ до VPC з екземплярів EC2 за межами VPC. З документації AWS:

VPC з маршрутами, які суперечать приватному діапазону IP-адрес EC2-Classic 10/8, не можуть бути включені для ClassicLink. Це не включає VPC з діапазонами 10.0.0.0/16 та 10.1.0.0/16 IP-адреси, які вже мають локальні маршрути в своїх таблицях маршрутів. Для отримання додаткової інформації див. Маршрут для ClassicLink.

від http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-classiclink.html#classiclink-routing