Агульная Transit Gateway: каму належаць маршруты ў AWS RAM

Абагульванне Transit Gateway праз Resource Access Manager робіць адну канкрэтную рэч: дазваляе іншаму ўліковаму запісу выклікаць пэўны набор API далучэння да рэсурсу, якім ён не валодае. Яно не перадае шлюз, яго табліцы маршрутаў або права вырашаць, як перадаецца трафік. Людзі лічаць інакш, бо далучэнне з’яўляецца ў кансолі атрымальніка і адразу працуе, што адчуваецца як уласнасць. Механізм пад гэтым — выдача дазволу на агульны рэсурс, і кожны даччыны аб’ект застаецца ў межах уліковага запісу ўладальніка. Гэтае раздзяленне тлумачыць большасць заявак пра адмову ў доступе вакол агульнага транзіту.

Што абагульванне сапраўды дэлегуе

Абагульванне рэсурсу называе рэсурс, прынцыпал і кіраваны дазвол. Дазвол пералічвае дзеянні, якія гэты прынцыпал можа выконваць, і для Transit Gateway гэты спіс ахоплівае аперацыі далучэння да агульнага рэсурсу.

Усё па-за спісам церпіць няўдачу на ўзроўні API, а не ў кансолі, таму памылка часта з’яўляецца пры першым запуску скрыпта.

Табліцы маршрутаў, асацыяцыі і распаўсюджванні застаюцца ўладальніку

Перадача вызначаецца трыма даччынымі аб’ектамі: з якой табліцай маршрутаў звязана далучэнне, у якія табліцы яно распаўсюджваецца і якія маршруты гэтыя табліцы ўтрымліваюць. Дакументацыя AWS па абагульванні сцвярджае, што атрымальнік не можа ствараць, змяняць або выдаляць табліцы маршрутаў транзітнага шлюза ці іх асацыяцыі і распаўсюджванні праз абагульванне. Гэтыя выклікі належаць уліковаму запісу ўладальніка. Атрымальнік, якому патрэбна новая асацыяцыя, просіць адміністрацыйную змену, а не рэалізуе дазвол, які забыўся ўключыць.

Табліца ніжэй — гэта раздзяленне, якое я змяшчаю ў праектныя дакументы, бо яно перажывае змены супрацоўнікаў.

Чытайце сярэдні радок уважліва: уладальнік VPC кіруе маршрутамі сваёй падсеткі, уладальнік шлюза кіруе цэнтральным рашэннем аб перадачы, і працоўны шлях патрабуе абодвух. Ні адзін з уліковых запісаў не можа завяршыць гэта самастойна.

Адзін шлях, два ўліковыя запісы

Прасочзіце пакет ад spokes-VPC да лакальнага прэфікса. Табліца маршрутаў падсеткі spokes павінна адправіць гэты прэфікс на далучэнне транзітнага шлюза, што ўладальнік VPC можа змяніць. Затым шлюз павінен мець у звязанай табліцы далучэння маршрут, які паказвае на VPN-далучэнне, і гэта можа змяніць толькі ўладальнік. Зваротны трафік патрабуе люстэрка абодвух. Прапусціце любы бок, і вы атрымаеце шлях, усталяваны напалову, які выглядае як праблема з фаерволам.

Запішыце абедзве змены ў адзін тыкет з двума прызначанымі, інакш іх завершаць у розныя тыдні.

Выкарыстоўвайце ID зон даступнасці, калі размяшчэнне мае значэнне

Назвы зон — гэта лакальныя псеўданімы ўліковага запісу. us-east-1a у адным уліковым запісе не гарантавана з’яўляецца той жа фізічнай зонай, што і us-east-1a у іншым. Калі праект патрабуе далучэння і працоўнай нагрузкі ў адной зоне, параўнайце ID AZ і запішыце іх.

Параўнанне назваў дае схему, якая выглядае правільна, і профіль затрымкі, які такім не з’яўляецца. Праверце гэта, пакуль схема яшчэ малюецца, а не пасля таго, як хтосьці вымерае розніцу.

Адмена абагульвання не перарывае шлях даных

Выдаленне абагульвання адчуваецца як адкліканне, і гэта не імгненная прыпынка трафіку. AWS дакументуе, што далучэнне застаецца працаздольным, калі шлюз выключаны з абагульвання. Дазвол кіраваць рэсурсам знікае, а існуючае далучэнне працягвае перадачу, пакуль хтосьці яго не выдаліць або не адключыць. Плануйце адкліканне ў два крокі: выдаліце абагульванне, затым далучэнне, прычым другі крок выконвае ўладальнік.

Калі абагульванне — ваш адзіны кантроль, у вас няма кантролю.

Трымайце запіс абагульвання і запіс маршрутызацыі разам

Два артэфакты адказваюць на два розныя пытанні. Запіс абагульвання кажа, хто можа працаваць з рэсурсам. Табліцы маршрутаў кажуць, якія сеткі сапраўды могуць гаварыць. Захоўвайце іх разам з адным і тым жа спісам уладальнікаў, інакш наступны інцыдэнт пачнецца з чалавека, які даказвае дазвол, які ніколі не быў праблемай.

Затым праверце адзін паток у кожным кірунку і адзін прэфікс, які павінен застацца недасяжным.