שני חשבונות AWS, רשת מקומית אחת: איזה נתיב?
Transit Gateway משותף, שני VPN עצמאיים או פרוקסי צר אחד: בחרו לפי בעלות והיקף ההשפעה, לא לפי איזה נתיב הכי קל להוסיף היום.
המסגור הברור הוא peering מול VPN, וזה המסגור השגוי. VPC שעברה peering לא יכולה לשאול את חיבור ה-VPN של שכנתה לניתוב מקצה לקצה, כך שהאפשרות הזו מעולם לא הייתה על השולחן, יהיה אשר יאמר טבלת הנתיבים. מה שאתם בוחרים בו בפועל הוא בין רכזת רשת משותפת, שני נתיבי VPN עצמאיים וכניסת יישום צרה. כל אחת מהן עונה על שאלה אחרת לגבי מי הבעלים של הניתוב.
שלוש אפשרויות והאחת שאינה אפשרות
התחילו במחיקת הרעיון של peering, ואז השוו את מה שנשאר לפי בעלות ולא לפי פשטות התרשים. הטבלה שלמטה היא ההחלטה בצורה דחוסה.
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New auth, logging and availability surface, and only one service |
אם חשבון A זקוק לנגישות לרשת מקומית שלמה, שורת הפרוקסי היא בצורה הלא נכונה. אם חשבון A זקוק ל-API אחד, שתי השורות הראשונות הן יותר רשת ממה שהדרישה ביקשה.
מתי Transit Gateway משותף מנצח
Transit Gateway מחבר כל VPC ואת ה-VPN כרשתות נפרדות, ושיתוף בין חשבונות מאפשר לבעלי ה-VPC להשתמש ברכזת בלי למזג חשבונות. זהו הקסם: מקום אחד שבו הקידומות המקומיות פוגשות את רשתות AWS, ומקום אחד לחשוב בו איזה חיבור לומד איזה נתיב.
חיבור של הכול אינו אומר אישור של הכול. שיוך והפצה קובעים איזה חיבור משתמש באיזו טבלת נתיבים, כך ששתי קידומות VPC יכולות כל אחת להגיע לשירות מקומי בעוד הגישה ההדדית שלהן נשארת מחוץ לעיצוב הרכזת. בצד המקומי עדיין דרושים נתיבי חזור לקידומות AWS, וזה שינוי של צוות אחר.
העלות ארגונית לא פחות משהיא כספית. בעל הרכזת שולט ביחסי ניתוב שצוותים אחרים תלויים בהם, כך ששינוי בחיבור אחד יכול להזיז תעבורה של שירות ששמו של הרכזת מעולם לא שמע. שעות חיבור ועיבוד נתונים מצטברים עם כל רשת שמחברים, ולכן רכזות נוטות לגדול מהר יותר מהצוות שמפעיל אותן.
מתי VPN נפרדים או פרוקסי צר מנצחים
שני VPN עצמאיים מתאימים לפריסה קטנה עם גבולות תפעוליים אמיתיים: כל חשבון משנה את המנהרות שלו, ואף אחד לא יכול לשבור את השני על ידי עריכת טבלת נתיבים. הגבולות נמצאים בצד המקומי. שער העמית זקוק לקיבולת עבור המנהרות הנוספות, תוכניות הכתובות אינן רשאיות לחפוף, ושתי תצורות שמפרסמות את אותן קידומות זקוקות להעדפה מכוונת ולא לתקווה.
פרוקסי הוא הממשק הצר ביותר. אם חשבון A זקוק למסד נתונים אחד או ל-API אחד בחשבון B, מתווך מוגדר נותן לכם כניסה מוגדרת עם סיפור אימות, רישום וזמינות משלו. זו גם האפשרות שהכי קל לנצל לרעה: מתווך שמעביר לכל יעד פרטי הפך לממסר בלתי מוגבל עם צעדים נוספים, והוא לא יתנהג כמו מעבר שקוף מ-VPC לרשת מקומית לשום דבר אחר.
כדאי לקרוא את מגבלות ה-peering של VPC לפני כל זה, כי הן מסבירות למה הרעיון הרביעי חוזר שוב ושוב ולמה הוא לא יכול לעבוד.
בחרו את הממשק הצר ביותר שעונה על הדרישה
סדרו את השאלות: האם A זקוק לרשת, לקבוצת רשתות או לשירות אחד? האם הצוות המקומי רוצה נתיב אחד או כמה? מי רשאי לשנות את הניתוב לתעבורה של הצוות השני? התשובה הראשונה שמייצרת את הממשק הצר ביותר היא הארכיטקטורה, וכל מה שאחריה הוא יישום.
תעדו את התשובה יחד עם תוכנית הקידומות, הבעלות על הנתיבים, מלאי המנהרות או החיבורים ומצב הכשל שכל צד מצפה לו. כשמישהו ישאל מאוחר יותר למה חשבון A לא יכול פשוט להשתמש ב-VPN של חשבון B, התיעוד הזה הוא התשובה, והוא חוסך מכם לדון מחדש באותן שלוש אפשרויות בפרויקט הבא.