Transit Gateway משותף: למי שייכים המסלולים ב-AWS RAM
שיתוף דרך RAM מאפשר לחשבון אחר לחבר VPC, אבל טבלאות מסלולים, שיוכים והפצות נשארים אצל בעל השער. זה הגבול.
שיתוף Transit Gateway באמצעות Resource Access Manager עושה דבר אחד ספציפי: הוא מאפשר לחשבון אחר לקרוא לקבוצה מוגדרת של API חיבור מול משאב שאינו בבעלותו. הוא אינו מעביר את השער, את טבלאות המסלולים שלו או את הזכות להחליט כיצד התעבורה מועברת. אנשים מניחים אחרת כי החיבור מופיע בקונסולה של הנמען ועובד מיד, מה שמרגיש כמו בעלות. המנגנון שמתחת הוא הענקת הרשאה על משאב משותף, וכל אובייקט בן נשאר בתוך גבול החשבון של הבעלים. ההפרדה הזו מסבירה את רוב הכרטיסים של גישה נדחתה סביב מעבר משותף.
מה השיתוף בעצם מאציל
שיתוף משאב נוקב במשאב, בגורם ראשי ובהרשאה מנוהלת. ההרשאה מפרטת את הפעולות שהגורם הראשי הזה רשאי לבצע, ועבור Transit Gateway הרשימה מכסה פעולות חיבור על המשאב המשותף.
כל מה שמחוץ לרשימה נכשל ב-API ולא בקונסולה, ולכן השגיאה מופיעה לעתים קרובות בהרצה הראשונה של סקריפט.
טבלאות מסלולים, שיוכים והפצות נשארים אצל הבעלים
ההעברה נקבעת על ידי שלושה אובייקטים בני: לאיזו טבלת מסלולים משויך חיבור, לאילו טבלאות הוא מופץ, ואילו מסלולים מכילות הטבלאות האלה. תיעוד השיתוף של AWS קובע שנמען אינו יכול ליצור, לשנות או למחוק טבלאות מסלולים של שער מעבר או את השיוכים וההפצות שלהן דרך השיתוף. הקריאות האלה שייכות לחשבון הבעלים. נמען שצריך שיוך חדש מבקש שינוי מנהלי, ולא מפעיל הרשאה ששכח להפעיל.
הטבלה שלמטה היא החלוקה שאני מכניס למסמכי תכנון, כי היא שורדת חילופי צוות.
| Role | What it controls |
|---|---|
| Transit Gateway owner | The gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here. |
| VPC owner using the share | Its own attachment, subnet route tables and security policy for the workloads. |
| Shared-subnet participant | Workload traffic only, following routes the VPC owner already set. |
קראו את השורה האמצעית בקפידה: בעל ה-VPC שולט במסלולי תת-הרשת שלו, בעל השער שולט בהחלטת ההעברה המרכזית, ונתיב עובד צריך את שניהם. אף אחד משני החשבונות לא יכול להשלים אותו לבד.
נתיב אחד, שני חשבונות
עקבו אחרי חבילה מ-VPC spoke ועד לתחילית מקומית. טבלת המסלולים של תת-הרשת spoke חייבת לשלוח את התחילית לחיבור שער המעבר, ובעל ה-VPC יכול לשנות זאת. לאחר מכן לשער חייב להיות מסלול בטבלה המשויכת של החיבור שמצביע על חיבור ה-VPN, ורק הבעלים יכול לשנות זאת. תעבורת החזרה צריכה את המראה של שניהם. אם תפספסו צד כלשהו תקבלו נתיב מותקן למחצה שנראה כמו בעיית חומת אש.
כתבו את שני השינויים בכרטיס אחד עם שני אחראים, אחרת הם יסתיימו בשבועות שונים.
השתמשו במזהי אזור זמינות כשהמיקום חשוב
שמות אזורים הם כינויים מקומיים לחשבון. us-east-1a בחשבון אחד אינו מובטח להיות אותו אזור פיזי כמו us-east-1a בחשבון אחר. כשהתכנון דורש חיבור ועומס עבודה באותו אזור, השוו מזהי AZ ותעדו אותם.
השוואת שמות מייצרת דיאגרמה שנראית נכונה ופרופיל השהיה שאינו כזה. בדקו זאת בזמן שהדיאגרמה עדיין מצוירת, לא אחרי שמישהו מדד את ההבדל.
ביטול השיתוף אינו מנתק את נתיב הנתונים
הסרת השיתוף מרגישה כמו שלילה, והיא אינה עצירת תעבורה מיידית. AWS מתעדת שחיבור נשאר מתפקד כאשר השער מוסר מהשיתוף. ההרשאה לנהל את המשאב נעלמת, בעוד החיבור הקיים ממשיך להעביר עד שמישהו מוחק או משבית אותו. תכננו שלילה בשני שלבים: הסירו את השיתוף, ואז את החיבור, כשהבעלים מבצע את השני.
אם השיתוף הוא הבקרה היחידה שלכם, אין לכם בקרה.
שמרו את רשומת השיתוף ואת רשומת הניתוב יחד
שני חפצים עונים על שתי שאלות שונות. רשומת השיתוף אומרת מי רשאי לעבוד עם המשאב. טבלאות המסלולים אומרות אילו רשתות באמת יכולות לדבר. אחסנו אותם יחד עם אותה רשימת בעלים, אחרת התקרית הבאה תתחיל עם מישהו שמוכיח הרשאה שמעולם לא הייתה הבעיה.
לאחר מכן בדקו זרימה אחת בכל כיוון ותחילית אחת שאמורה להישאר בלתי נגישה.