AWS Elastic Load Balancer

אחד מהרכיבים הבסיסיים של ה Elastic Cloud Compute (בקיצור: EC2) של אמזון הוא ה Elastic Load Balancer (בקיצור: ELB).

Load Balancer הוא "לא כזה נושא מורכב" - הוא מחלק תעבורה בין כמה nodes ב cluster.

אם כך, אז מה יש להמשיך ולהתעמק?!


אם כל מה שיש לנו באמזון הוא cluster יחיד של אפליקציה מונוליטית - זה באמת לא כ"כ מסובך.
אם המערכת שלנו היא מערכת מורכבת ומבוזרת - למשל: מיקרו שירותים (פוסט), ו / או אנו מגדירים תצורת רשת מורכבת - למשל: VPC (פוסט) זה עדיין לא כ"כ מסובך, אך ה ELB הופך למרכיב יותר משמעותי בסביבת הריצה של המערכת שלנו. רכיב שכדאי להכיר קצת יותר לעומק.

אמנם ELB הוא "רק Load Balancer", אך הוא גם מערכת מבוזרת בפני-עצמה, עם קשרים הדוקים לשירותים אחרים של אמזון כמו EBS, CloudWatch, Route53, ו Auto-Scaling.

מצד שני, ELB הוא גם דיי פשוט בפונקציונליות שלו, מה שהופך אותו לקצת שונה מ Load Balancers של "העולם הישן": Nginx, HAProxy, או (F5 Local Traffic Manager (LTM.


כשה ELB היה שירות חדש ב AWS, המשתמשים התחלקו בערך שווה בשווה לאלו שהשתמשו בו (מאוד בסיסי, אך חלק מהמערכת) לבין אלו שהשתמשו בפתרונות אחרים שניתן להציב באמזון (כמו Nginx או HAProxy - מבוססי התוכנה). היו הרבה תלונות על חוסרים בשירות של ELB (למשל: כל ELB היה חשוף לרשת האינטרנט, לא ניתן היה להגדיר ELB "פנימי", לא ניתן לבצע ניתוב ע"פ URL, וכו') - תלונות שאנשים עד היום גוררים, ולא מודעים לכך שהמצב השתנה.


כיום, סט היכולות של ELB הוא כבר יפה והוא יכול לשרת תסריטים רבים. הדרישות החשובות של ELB הן: זמינות, אבטחה, ו scalability - מה שגורר את הרצון להשאיר אותו פשוט ככל האפשר, ולא להעמיס אותו ביכולות.

נראה היום שכמעט כל לקוחות AWS משתמשים כבר ב ELB. הנוחות של כלי שהוא well-integrated לכלל התשתיות באמזון, וגם זול ופשוט להפעלה - גרמו לארגונים להתאים את תצורת הרשת שלהם בכדי לעבוד עם ELB.

רק לקוחות מעטים, עדיין משתמשים בפתרונות כמו HAProxy או Client-Side Load Balancing - פתרונות שיכולים לספק יותר אמינות וגמישות, אך במחיר לא קטן של תפעול מורכב יותר. התפעול של Load Balancing בין AZs הוא לא דבר פשוט.

בפוסט זה אנסה לתת סקירה קצרה אך מעמיקה מספיק - בכדי להביא את הקורא להבנה טובה של ה Amazon Elastic Load Balancer.

תסריט בסיסי

נתחיל עם הת'כלס: תצורת הבסיס של ELB נראית כך:

• משתמש רוצה לגשת לשרת הווב שלנו, המנוהל כ Cluster מאחורי ה ELB.
• ראשית המשתמש פונה ל DNS (של אמזון, או אחר) על מנת לקבל את כתובת ה IP של האתר שלנו: our-site.com.
• התשובה של ה DNS תהיה alias נוסף שמפנה ל ELB שלנו. משהו בנוסח:  blabla123...elb.amazonaws.com
• על המחשב של המשתמש לפנות שוב ולקבל כתובת IP מ Route53 - ואז הוא יקבל כתובת IP אליה יוכל לשלוח את הבקשות.
• באמזון בעצם יש Load Balancing דו-שלבי: ראשית Route53 מנתב בין ה regions ול ELB הנכון, ואז ה ELB הנכון מנתב ל instance הנכון ב AZ הנכון.
• אסור לנסות ולשמור את כתובת ה IP שחזרה לנו מה DNS alias של ה ELB. ה ELB הוא בעצם מערכת מבוזרת, ולא Appliance יחיד:
• מכונות נופלות וקמות - ואז ה IP משתנה.
• כנראה ומאחורי תמונת "ה ELB היחיד" שלנו, בעצם יש כמה מכונות שמשרתות אותנו - ואנו לא רוצים לפנות רק למכונה אחת (ולהעמיס עליה, או להיות תלויים בה במצב של כשל).
• בשלב הבא ה ELB מפנה את הבקשה לאחד ה instances שרשומים אצלו. איזון העומס ב ELB עובד באחד משני האופנים הבאים:
• Round Robin - או ליתר דיוק, איזון המבוסס על ספירת ה tcp connections הפתוחים לכל instance בכל רגע (מקור)
• אם מחברים את ELB ל Cloudwatch, ניתן להתבסס באיזון על מדדים יותר איכותיים ממספר ה connections - כמו CPU Utilization או צריכת זכרון.
• אם יש לנו instances שאינם באותו הגודל (לא מומלץ), או שה instances מטפלים במשימות בסדרי-גודל שונים לחלוטין של עבודה (לפעמים x, לפעמים 100x) - כדאי, ואפילו חשוב לבצע את החיבור הזה.

זהו, ה flow הבסיסי הסתיים ואנו מעבירים בקשות לשלושת ה instances מהמשתמשים שלנו. hoowhoo!

High Availability

כמובן שהדבר הכי בסיסי שניתן לעשות עבור HA הוא לעבוד cross-AZ. אם AZ (שהוא Data Center פיסי) כושל - ה AZ האחרים ימשיכו לספק את השירות:

• ELB מתואר כשירות ברמת ה Region. שום כשל של AZ לא יפיל אותו.
• מה שקורה בפועל הוא שיש מכונות של ה ELB בכל ה AZ, הרי ה ELB הוא מערכת מבוזרת.
• אם לא היה ברור: מכונות מ AZs שונים מתחברות לאותו ELB, כך שהוא מאזן cross-AZ.
• ה ELB יכול (מומלץ מאוד) לבצע Health Check ל instances לדעת אם הם במצב תקין.
• גם אם ה VM לא קרס (זה משהו ש ELB יידע ממנו לבד) - יכול להיות ש instance ספציפי שהתוכנה "נתקעה" בו, process חשוב נפל, וכו'.
• אנו יכולים לספק URL בתוכנה שלנו שיספק אינדיקציה לבריאות המכונה. זה יכול להיות דף ה login (מדד חלש) או endpoint מיוחד שבודק גם קישוריות ל DB ו flags פנימיים (מדד חזק יותר). כל עוד ה URL שסיפקנו מחזיר קוד 200 - ה ELB מבין שה instance במצב תקין.
• אם ה instance אינו תקין, יש מנגנון הדומה מעט ל Circuit Breaker שבודק זאת שוב ואם instance נראה לא תקין - ה ELB יחדול לשלוח לו traffic עד שהוא נראה שוב במצב תקין. 

הגדרות ה HealthCheck במסך יצירת ה ELB ב AWS Console.

• ה ELB ידגום כל instance כל 5 שניות (הערך יכול להיות בין 5 ל 300 שניות). אם התוצאה לא הייתה HTTP 200, או שעבר response timeout של יותר ממה שהוגדר (ברירת מחדל: 5 שניות) - זו בדיקה שנכשלה.
• אם יש 2 בדיקות ברצף שהן לא טובות - ה ELB ידליק "סטטוס אדום" ל instance ויפסיק לשלוח לו traffic.
• שימו לב שהגדרות ברירת המחדל מכתיבות מצב בו instance שלא עונה יתפקד ויקבל traffic עד כ 15 שניות עד שינותק (5 שניות מאז דגימה אחרונה, ו 2 * 5 שניות timeout). זה אולי default סביר לאתר אינטרנט, אבל עבור מערכות realtime / קריטיות - ייתכן ותרצו להדק את התנאים.
• יש הגדרה שנקראת connection draining שתאפשר לבקשות שכבר בטיפול לנסות ולהסתיים לפני שה ELB מנתק את ה instance הבעייתי. יש timeout (ברירת מחדל: 5 דקות) לאחריו ינתקו את ה connection ויודיעו ללקוח המרוחק שלא לנסות ולהמתין עוד לתשובה מה instance הבעייתי.
• גם כאשר ה instance מנותק, ה ELB ימשיך לשלוח בדיקות health check - ולאחר רצף של 10 הצלחות - יחזיר אותו לפעול ("מצב ירוק") וישלח לו traffic.
• אם אתם משתמשים ב Auto Scaling חשוב שתחברו אותו ל ELB כל ש instances חדשים ה Auto Scaling מרים - יירשמו ל ELB בצורה אוטומטית (וגם להיפך: יוסרו אוטומטית).
• אפשר לכוון את Auto Scaling להגיב גם למה ש ELB חווה מהשרתים מבחינת זמני-תגובה, ולא רק למדדים סינתטיים (כמו CPU או זיכרון).
• Route 53 מבצע Health Checks ל ELB, ואמור לזהות כשל של AZ תוך 150 שניות - ואז להפסיק לו את ה Traffic עד שהוא חוזר לתפקד.

יש אנשים שמנסים "לשפר את ה Availability" של המערכת ע"י הגדרת ELB נוסף שהוא redundant (ורישום שלו כ alias נוסף ב DNS). הדבר הזה אפשרי, אך לרוב הוא כמעט חסר משמעות:

• ELB היא תשתית מבוזרת ו multi-tenant. ה ELB הנוסף לא ירוץ על חומרה אחרת / vector אחר של המערכת - אלא על אותה התשתית בדיוק.
• אם אתם כבר רוצים, התקינו Load Balancer מסוג אחר (למשל HAProxy) כ Load Balancer משני. לזה יש משמעות.
• גישה אחרת היא לעבור ל clinet-side load balancing, ולהפסיק להתבסס על ELB. מכיוון שכל שרת מחזיק cache של כתובת השרתים שהוא זקוק להם - אין "נקודת כשל יחידה" במערכת.

חיבור ל VPC

אם אתם לא מכירים / מבינים VPCs - כתבתי לאחרונה פוסט בנושא.

מאז הצגת ה VPC אמזון מאפשרת לבחור בין 2 "הצבות" שונות של ה ELB: 

• ELB ציבורי - החשוף לאינטרנט.
• internal ELB - שיהיה חשוף רק בתוך subnets של ה VPC.

הצורך ב internal ELB הוא כאשר אנו רוצים ששרת הווב שלנו (לדוגמה) יתקשר מול שירות פנימי שלא נגיש מהאינטרנט (לצורכי אבטחה) - ואת השירות אנו רוצים לנהל כ cluster.

ה ELB היא תשתית מבוזרת של אמזון, ובפועל משייכים את tenant (? - לא כ"כ ידוע כיצד ה ELB ממומש מתחת לקלעים) הספציפי ל subnets שהגדרנו. שימו לב שבניגוד ל ELB ציבורי, אם נגדיר ELB רק ב subnet בודד הוא בהכרח ירוץ רק על מכונות באותו AZ - וכך יהיה לו Availability נמוך יותר מאשר ELB רגיל - שרץ על מכונות בכל ה AZs.

את ה resolving מ alias לכתובת IP עובר internal ELB עדיין עושים דרך Route53 - מה שלא מצוין בתרשים. הגישה ל IP (או בעצם IPs) של ה ELB עצמו כמובן תאכף ע"י ה VPC.
מהרגע שמסירים IP מ ELB אחד (נניח שמשרת את חברת קוקה-קולה) ועד שמשתמשים בו ל ELB instance אחר (למשל: שלנו) יש שבוע של צינון בו ה IP לא בשימוש, מה שמפחית מאוד את החשש שנקבל traffic שלא יועד לנו.

יש הגדרה על ה ELB בשם "cross-zone load balancing".

• כאשר היא enabled (זוהי ברירת המחדל), כל מופע של ה ELB בכל AZ ישלח traffic בצורה אקראית לכל AZ אחר. גישה זו משפרת את ה Availability ואיזון העומס בין השרתים.
• כאשר היא disabled, כל מופע של ה ELB ינתב את ה traffic רק ל instances ב AZ שלו. גישה זו משפרת את ה latency (כי גישה בין AZ מוסיפה עוד כ 1-3 מילישניות). מומלץ להימנע מגישה זו אם יש לכם מספר קטן של instances (למשל: 1-2 בכל Availability zone).

איזון עומס בין 3 AZs בלי ועם cross-zone load balanging. מקור: אמזון

כפי שכבר ציינתי קודם לכן, load balancing בין regions אפשר לבצע בעזרת Rotue53 (או DNS אחר). יכול להיות גם VPC בסיפור - אך לא רציתי לסבך יתר על המידה את התרשים:

Route 53 יודע לבצע latency based routing, וכך לשלוח כל לקוח ל Region שיתן לו latency טוב יותר.

פרטים והשלמות על ה ELB

יש עוד סדרה של עובדות חשובות שלא כיסיתי לגבי ה ELB. אביא אותן כאן בתפזורת:

• ה ELB תומך בפרוטוקולים הבאים בלבד: HTTP/HTTPS, ו TCP.
• ב EC2-Classic יש מגבלה על מספרי ה ports שה ELB יטפל בהם בטווח 1-1000.
• ה ELB מספק SSL Termination and processing - וחוסך CPU למכונות ה EC2 בעזרת חומרה ייעודית למשימה. CPU רגיל נחשב מאוד לא יעיל למשימות הללו.
• לא ניתן להצמיד ל ELB כתובת IP קבועה, אפילו לא בעזרת Elastic IP.
• זה עלול להיות קושי אם יש לכם מערכת On-Premises שנגשת אליו, ואתם רוצים לבצע white-listing לכתובת ה IP (משיקולי אבטחה).
• ניתן להטמיע רק SSL Certificate יחיד על ELB. כלומר: אם יש לכם כמה Domains (למשל: גם gett.com וגם gettaxi.com) - תזדקקו ל 2 ELBs שונים אם אתם רוצים להציב בהם SSL Certificate.
• עם זאת, ה SSL certificate יכול להיות wildcard certificate, כלומר: gett.com.*, המאמת את הזהות גם של drivers.gettt.com וגם riders.gett.com.
• ל ELB יש העדפות מסוימות ב SSL chiper negotiation, למשל:
• יעדיף AES על פני 3DES על פני RC4.
• ייתכן והתמיכה ב RC4 בכלל הוסרה לאחרונה. לא וידאתי.
• יעדיף GCM על פני  CBC + HMAC.
• בד"כ לא תהיה בכך בעיה, אך עבור client ישנים או עבור תאימות לתקנים כמו PCI או SOX - ייתכן ותצטרכו לשנות את ההגדרות הללו.
• עוד בנושא אבטחה, אפשר לציין ש ELB מקבל עדכוני אבטחה בצורה תדירה. לכמה ההתקפות המפורסמות: POODLE (הבעיה ב ssl 3.0), או HeatBleed - היו ל ELB כבר פתרון ראשוני תוך יממה מרגע שהבעיה התגלתה.

ל ELB יש מנגנון בשם Listeners שמכתיב את הרגישות של ה ELB לפרוטוקולים שונים: HTTP ו TCP. לעתים נשמע בשיחה כאילו יש "HTTP Load Balancer" ו "TCP Load Balancer" באמזון - אך בסופו של דבר זהו אותו ELB כאשר מקונפגים לו Listeners שונים. הנה תצורות העבודה השונות שלהם:

מקור: אמזון

• ה HTTP Listener יחזיק כמה tcp connections לכל instance, גם כשאין traffic - על מנת לחסוך latency. את קריאות ה HTTP הוא יעביר על גבי ה connections הללו - ברגע שיגיעו.
• אם התעבורה שלכם היא HTTP 1.0/1.1 לא סטנדרטי (response codes או headers שונים שדורשים התנהגות מסוימת) - ייתכן ותאלצו לעבור עם ה TCP Listener - כי ה HTTP listener לא יידע לספק את ההתנהגות הרצויה.
• ה HTTP Listner מאפשר יכולת של Cookie-Based sticky session - משתמש יחזור ל instance שטופל בו. ב tcp פשוט אין צורך שכזה.
• ה cookie יכול להיווצר ולהיות מנוהל ע"י ה ELB (מה שנקרא ELB Generated Cookie Stickiness) או ע"י האפליקציה (מה שנקרא Application Generated Cookie Stickiness).
• ה Cookie Stickiness עולה המקרה של instance שכשל ואיבד את ה states הרלוונטיים.
• ההמלצה היא לא להשתמש ב Cookie Stickiness אלא לאחסן את ה states במקום מרכזי (Redis או ElasticCache, המבוסס על Memcached) ואז לפזר את ה traffic בין ה nodes ע"פ היכולת שלהם לטפל בתעבורה. כלומר: central state - מה שגורם ל instances להיות "כאילו-stateless".
• אם לכל instance יש caches מקומיים משמעותיים, שלא ניתן לשתף - זו אולי סיבה שיכולה להצדיק שימוש ב Cookie Stickiness, בכל זאת.
• על אף שלא מצוין בטבלה, ELB יוסיף גם headers של X-Forwarded-Proto ו X-Forwarded-Port (מקור).

הנה התצורות השונות של ה TCP listener:

• זוהי תצורת ה Load Balancing הבסיסית יותר, שתתאים אם ה traffic שלכם אינו HTTP (יכול להיות פרוטוקולים שונים העובדים על גבי TCP), או כ Fallback במידה ויש לכם בעיות תאימות עם ה HTTP Listener - אבל אז גם לא תקבלו את הערך המוסף שהוא נותן.
• ה TCP Listner כן תומך ב Proxy Protocol גרסה 1 (פרטים) - שמאפשר סוג של מקבילה ל X-Forwarded-For ברמת ה TCP. 

בעיות שונות שעלולות לצוץ בעבודה עם ELB

כאשר EBS כושל - גם ELB כושל.

נראה שיש תלות בין השירותים, כך שכל פעם שהיו בעיות ב EBS (בדרך כלל ב AZ יחיד) - גם ELB הפסיק לתפקד בצורה טובה באותו AZ. כנ"ל אגב גם לגבי RDS, Elastic Beanstalk, ואחרים.

לקח: אם יש בעיות ב EBS - אל תנסו לשבור את הראש להבין מה קרה ל ELB שלכם...

Timeout לא-צפוי מהשרתים שלכם

לעתים יש קריאות ארוכות למדי (למשל: יצירת דו"ח ארוך במיוחד שאורך כמה דקות) - אך הוא לא מסתיים ואתם "חוטפים" timeout.
אתם בודקים את ה timeouts של ה Application Servers ושל ה Web Server, למשל Nginx או Apache - אך זה לא הם.

זה עלול להיות ה ELB, שיש לו timeout ברירת מחדל של 60 שניות ל connection. אם עלולות להיות לכם קריאות ארוכות מזה - יהיה עליכם לשנות גם את ה connection timeout שלו - מה שנקרא "Idle Timeout" בהגדרות של ה ELB. ניתן לקבוע את הערך ל 1 עד 3600 שניות.



התמודדות עם Traffic Spike

אחד החולשות של AWS שאנשי מכירות של Google Compute Engine אוהבים להזכיר הוא "ההתחממות" ההדרגתית של ה ELB והקושי שלו להתמודד עם spikes.
ELB מקצה משאבים ל Tenant שלכם (הכוונה: ל "ELB Instance" שלכם) ע"פ שילוב של הידיעה כמה EC2 instances חוברו לו, וע"פ כמות ה traffic הנכנס. הוספת משאבים הוא לא תהליך מאוד מהיר ויכול לארוך כמה דקות.

אם מגיע Traffic רב יותר ממה שהמשאבים שהוקצו ל Tenant שלכם יכולים לטפל בהם, ELB יסגור חלק מהבקשות ל Connection ויחזיר HTTP 503.

מה ניתן לעשות?

אם אתם יודעים על ה Spike הצפוי, למשל אתם מכינים לעצמכם התקפת Self-Denial of Service (כלומר: קמפיין פרסומי שעלול לגרור הרבה Traffic) עליכם לפנות לאמזון ולבקש הגדלת משאבים (נקרא "Pre-Warming").

אלטרנטיבה אחרת היא להשתמש בכלי Load (בד"כ כלי בדיקות) על מנת לגרום ל ELB להגדיל משאבים גם ללא פניה לשירות של אמזון. למשל: !Bees with Machine Guns (שזו לא התכלית המקורית שלו).

תשובות 400 (Bad_Request) או 405 (Method_Not_Allowed) חוזרות מה ELB

ה HTTP-Listner של ה ELB בודק כמה סימנים חיוניים של בקשות כמו Content Length (יכול להחזיר 400), או שם מתודה לא מוכרת / ארוכה מ 127 תווים עשוה להחזיר 405. כנראה שיש עוד מקרים דומים.

הפתרון הוא לרוב לתקן את התקשורת כך שתעמוד בתקני HTTP 1.0/1.1 או להוריד את ה HTTP-Listener.



פיזור עומס לא מידתי על השרתים (אין Load Balancing טוב)

זה קורה. אל תצפו ל Balancing מושלם, במיוחד לא כאשר כמות ה instances שלכם היא קטנה יחסית (פחות מ 5-6 instances). יכולות להיות לכך כמה סיבות:

• יש שונות גדולה בין זמני הטיפול בבקשות השונות.
• חיברתם לאותו ELB instance מכונות בגדלים שונים או קונפיגורציות עבודה שונות.
• ה Clients שלכם לא מכבדים את ה TTL של ה DNS (שאמור להיות קצר מאוד כאשר מדובר ב Alias של ה ELB) - וזה גורם ל Balancing של Route53 לא לעבוד בצורה טובה.

מלבד המקרה האחרון, חיבור ל CloudWatch וביצוע Load Balancing ע"פ מדדים של CPU ו/או זיכרון - כנראה ישפרו את המצב.

סיכום

זהו, עברו על הסט העיקרי של היכולות של ה ELB - ובשאיפה עתה ניתן להבין טוב יותר כיצד הוא עובד ומשפיע על המערכת שלנו.


שיהיה בהצלחה!



---

קישורים רלוונטיים

(Understanding the new ELB metrics in CloudWatch (2013

Amazon Virtual Private Cloud

VPC (קיצור של Virtual Private Cloud) היא רשת מבודדת לוגית ב Data Center של AWS. היא באה לדמות Data Center פרטי של ארגון (כלומר: ב On-Premises), בו תעבורת הרשת, והגישה לשרתים מוגבלת למי שנמצא בתוך ה Data Center.

• מבחינה טכנית, ניתן לחשוב עליה כתת-רשת (subnet) בתוך אמזון שמוקצה רק לכם.
• מבחינת אבטחה, ניתן לחשוב עליה כ VLAN [א] - רשת משותפת שהתשתית יודעת להפריד בין packets של תתי-רשתות נפרדות - הפרדה מוחלטת.

VPC הוא לא שירות פרימיום. הוא כמעט חינם, ואם אתם פועלים ב AWS ולא משתמשים בו - כדאי להכיר.

בניגוד לניהול רשת "קלאסי" בו צריך להכיר את הראטורים השונים ולתכנת אותם, העבודה ב VPC היא ברמת התוכנה ובממשק אחיד של אמזון - סוג של Software Defined Networking (קונספט שגם תופס תאוצה ברשתות On-Premises).

למרות שה VPC מבודד אותנו משאר העולם, ניתן לבצע קשרים מאובטחים עם רשתות אחרות:

• VPN שיחבר בין רשת אחרת של הארגון (למשל - המשרד) ל VPC בו נמצאים השרתים.
• VPC Peering - חיבור (שניתן להגדיר את מידת החופש שלו) בין שני VPCs, למשל: VPC של ספק שירות או לקוח, או אולי VPC אחר של הארגון שלכם (כי לעתים נכון ליצור בענן כמה VPCs לאותו הארגון).

אם אתם רוצים אבטחה אפילו גבוהה יותר, אז VPC תומך במצב של הפרדה מוגברת - מה שנקרא "dedicated tenant".
כל ה EC2 instances שנוצרים בתוך VPC שהוא dedicated tenant הם dedicated instances (כלומר: השרת הפיסי רק משרת אתכם - אין לכם "שכנים"), וגם חלק מתשתיות הרשת יהיו מופרדות בצורה טובה יותר - עבורכם.
השירות הזה, באופן טבעי - מגדיל את העלויות בצורה משמעותית.

מה החשיבות של VPC, ומדוע לא כדאי לעבוד באמזון בלעדיו?

השימוש העיקרי של VPC הוא סביב אבטחה, וקצת סביב יציבות המערכת.
אם לא אכפת לכם שכל השרתים שלכם יהיו נגישים מהאינטרנט ללא-הגבלה - אז VPC לא אמור לעניין אתכם.

אמנם גם ללא VPC ניתן להגן בעזרת "Firewall" על השרתים שלכם: ניתן לאגד שרתים דומים בקבוצה הנקראת "קבוצת אבטחה" (Security Group), ואז להגדיר:

• תקשורת נכנסת - כתובות IP, פורטים, ופרוטוקולים (tcp, HTTP, וכו') ספציפיים שיכולים לגשת למשאבים בקבוצת האבטחה.
• תקשורת יוצאת - כתובות IP, פורטים, ופרוטוקולים אליהם יכולים המשאבים בקבוצת האבטחה לפנות.

הגישה הזו היא מוגבלת:

• ניתן להגדיר רק הרשאות (whitelist) ולא חסימות (blacklist).
• אם אתם רוצים לבודד בין קבוצות שרתים שלכם ("ניתן לגשת לבסיסי הנתונים רק מתוך ה Application Servers") היא הגדרה כמעט בלתי אפשרית ללא VPC: כתובות ה IP משתנות כל הזמן, ויהיה עליכם לעקוב אחר השינוי ולעדכן את ה Security Groups. נתקן: אפשרי - אך לא סימפטי לתחזוקה.

VPC מאפשר הרבה מאוד גמישות להגביל את התעבורה בין כל קבוצת משאבים שלכם - לכל קבוצה אחרת, ובצורה שניתנת לניהול.

עוד צורך חשוב ש VPC פותר הוא בידוד הרמטי יותר בין חלקים במערכת, למשל: משאבים המשרתים מחלקות שונות, בין dev ל production, וכו'. הפתרון שהיה מקובל קודם ל VPC הוא לנהל חשבונות (account) שונים ב Amazon - מה שהקשה מאוד על כמה פעולות אחרות (למשל: העברת נתונים בצורה מאובטחת בין החשבונות).

עוד כמה שימושים ל VPC:

• Compliance - אם יש תקן שמחייב אתכם להגביל ו/או לעשות Audit לכל מי שניגש לקבוצה מסוימת של משאבים - VPC יהפוך את המלאכה לקלה יותר.
• הפרדה בין dev/test ל production - לצורך הגנה בפני טעויות אנוש.
• הפרדה דומה בין יחידות שונות בארגון, למשל: ארגון ה BI רוצה אחריות משלו על החשבון, והפרדה מכל מה שמתרחש ב R&D.

"The "Default VPC

החל מ 2014 [ב] כל חשבון חדש שנוצר באמזון, נוצר ב Default VPC - שזו בעצם תשתית התקשורת המשופרת של אמזון שמאפשרת הגדרה של VPCs. אם אתם נמצאים "ב Default VPC" - אין הכוונה שבאמת אתם משתמשים ב VPC, אלא שאתם נמצאים על התשתית החדישה יותר של אמזון, ברשת משותפת… ביחד עם עוד כמה אלפי ארגונים.

תשתית הרשת הישנה יותר של AWS נקראת "EC2 Classic". היא מוגבלת יותר:

• לא מאפשרת יצירה של VPC.
• פחות גמישות ב Security Groups: לא ניתן להגביל outbound traffic, לא ניתן להחליף באופן דינאמי Security Group למשאב).
• פחות גמישות בהגדרות רשת בסיסיות: לא ניתן לתת למשאב יותר מכתובת IP אחת, קשה יותר לשלוט בהגדרות ה DHCP, DNS, ו NTS של המשאבים.
• לא ניתן להשתמש ב Enhanced Networking (משלמים יותר, מקבלים רשת יותר "יציבה" ומהירה).
• וכו'.

אם אתם נמצאים על EC2-Classic - אז כדאי לעבור "Default VPC" גם אם אתם לא מתכננים לנהל VPC משלכם. יבוא היום ואמזון תכריח אתכם לעבור. בכל מקרה, מעבר שכזה הוא תהליך מורכב - אם אתם לא מוכנים לספוג downtime. כלי שיכול להקל בכזה מעבר הוא AWS ClassicLink.

ב Default VPC, כל מכונה חדשה שתוסיפו תקבל אוטומטית כתובת IP ציבורית באינטרנט - בכדי לתאום לאחור להתנהגות של EC2 Classic. זה לא יקרה ב VPC שהוגדר על ידכם.

כמו כן, ב Default VPC כל שרת שלכם יוכל לגשת לאינטרנט - כי הוגדר לו Internet Gateway כברירת מחדל.
ב VPC משלכם, ברירת המחדל היא ששרתים לא יכולים לגשת לאינטרנט - אלא אם חיברתם אותם בעצמכם ל Internet Gateway.
מדוע זה חשוב? כי אם יש לכם שרת שלא אמור מתוקף תפקידו לגשת לאינטרנט (למשל Database Server) - גישה לרשת יכולה לרמז על תוכנה עוינת שרצה על המחשב ושולחת מידע לתוקף. תוכלו למנוע זאת ע"י בקרה ושליטה בתקשורת היוצאת מהרשת שלכם.

יוצאים לדרך!

יצירה של VPC היא פעולה דיי פשוטה, והיא נראית כך:

1. אנו יוצרים את ה VPC ומגדירים לו טווח כתובות (cidr-block) של בטווח הכתובות השמורות לרשתיות פרטיות, בכדי לא להתנגש עם כתובות באינטרנט.

--

CIDR (קיצור של Classless Inter-Domain Routing) היא שיטה להגדרת תתי-רשתות (subnets) שיכולה לנצל את טווח הכתובת של IPv4 בצורה יעילה יותר, ואולי מעט יותר קלה להגדרה מהשיטה של subnet-masks.

התחביר של CIDR נראה כך:

<Base IP address> / <suffix>

כאשר כתובת ה IP הבסיסית היא כתובת בת 4 מספרים בני 8 ביט (0-255) - סה"כ 32 ביט, וה Suffix הוא מספר בין 0 ל 32 - המתאר כמה ביטים בכתובת הבסיס הם "קבועים" ומתארים בעצם את טווח תת-הרשת.

למשל:
127.0.0.0/24 - היא צורה לתאר תת-רשת עם טווח הכתובות 127.0.0.0 עד 127.0.0.255.
24 ביט הם שלשה מספרים, ולכן 127.0.0 הוא החלק ה"קבוע" בטווח הכתובת.

עוד דוגמה:
30.0.0.0/8 היא צורה לתאר תת-רשת שטווח הכתובת שלה הוא 30.0.0.0 עד 30.255.255.255.
8 ביט הם מספר אחד, ולכן רק 30 הוא החלק ה"קבוע" בטווח הכתובות.


ניתן להשתמש ב CIDR בכתיבה מקוצרת, ולהשמיט מכתובת הבסיס אפסים שאינם קבועים. למשל הדוגמה הראשונה יכולה להיכתב כ 127.0.0/24 והדוגמה השניה יכולה להיכתב כ 30/8. ניתן למצוא עוד מגוון דוגמאות בערך בוויקיפדיה.

--

בדוגמה שלנו הגדרנו את 10.0.0/16 - הטווח בין 10.0.0.0 ל 10.0.255.255 - טווח אפשרי של 65K כתובות (המקסימום של VPC מאפשר). אנו כמובן משתמשים באחד הטווחים של פרוטוקול ה IP לרשתות פרטיות - לא נרצה התנגשות עם כתובות של שירותים ברחבי האינטרנט. התוצאה של הפעולה מחזירה לנו id של ה VPC שרק נוצר, במקרה שלנו: vpc-a01106c2.


2. בתוך ה VPC עלינו להגדיר subnet לכל Availability Zone. ה VPC, כקונספט לוגי שמכיל הגדרות, יכול להתפרס על גבי Region של אמזון, אבל ה subnet הספציפי יכול לחיות רק ב Availability Zone - שהרי זהו Data Center פיסי.

ה Subnet יהיה בטווח קטן יותר של כתובות IP - כ 256 כתובות, בכדי לא "לשתות" את כל הכתובות של ה VPC, ואנו נייצר אותו ב AZ בסימון a של אירלנד (eu-west1).

3. הנה אנו מגדירים subnet נוסף ב AZ בסימון b, ובאופן דומה. שימו לב שמרחב הכתובות של ה subnet הזה הוא שונה.


התוצאה היא המבנה הבא:

לכל subnet יהיה id, למשל "subnet-d38d91dd" וברגע שנבקש להקים EC2 instance - יהיה עלינו לציין באיזה subnet ליצור אותם.

ה Instances שנוצרו, מנותקים מהעולם: לא ניתן לגשת אליהם, והם לא יכולים לגשת לעולם.
הנה הדרך לחבר אותם לעולם:

1. אנו יוצרים Internet Gateway, רכיב של AWS שמאפשר גישה לאינטרנט. בהפעלת הפעולה - נקבל id (למשל "igw-c0a643a9")

2. אנו מוסיפים route ל "router הווירטואלי שלנו", שאומר שכל כתובת בעולם (0.0.0.0/0), אם לא נמצאה בתוך ה subnet - הולכת ל internet gateway שלנו.

ה VPC מחזיק טבלת ניתוב (routing table) לכל ה subnets, אך ניתן להגדיר טבלאות ניתוב שונות - ולקשר כל subnet לטבלת ניתוב שונה.


"למה שארצה להגדיר טבלאות ניתוב, פחחחח?" - יכול מישהו לשאול.
ברור שזו התעסקות נוספת, קצת יותר low level מרוב העבודה עם אמזון. הדרך לאבטחה טובה, היא לתכנן ולשלוט בניתובי הרשת.

לשמחתנו ניתן לבצע את כל הפעולות עם ה aws console - ממשק אחיד לו ניתן לכתוב סקריפטים (ניתן גם דרך ה UI של אמזון - למי שמעדיף). לא צריך להתחבר ל router החומרה ולעשות את זה מולו ישירות - כמו פעם.


החיבור של העולם פנימה לתוך ה VPC הוא קצת יותר מורכב: יהיו שם כנראה ELB, Route53, NAT, ואולי גם WAF. לא אכנס לפרטים כיצד להגדיר חיבור שכזה.

אז איך מתכננים VPC?

"VPC ניתן להגדיר ב-2 אופנים: VPC יחיד, או ריבוי VPCs - אך יש אלפי תצורות שונות בהן ניתן להגדיר את שני האופנים" -- יועץ AWS זקן וחכם.

בתור התחלה, בואו נחלק את המשאבים שלנו באמזון לכמה מחלקות ארגוניות שונות:

• VPCs בניהול ה R&D:
• Production
• Dev/Test - ההפרדה נעשתה כדי למצמצם טעויות אנוש שישפיעו על production.
  יש גם ארגונים שלא מאפשרים למפתחים בכלל לגשת ל production - וזו דרך פשוטה לנהל זאת.
• VPC עבור ה IT:
• מערכות ה Active Directory, מערכת ניהול הכספים, נוכחות משתמשים ומערכת ה HR - לא צריכות להשפיע על production, ואף מפתח לא זקוק לגישה אליהן. לכולם יותר נוח שרק לאנשי ה-IT תהיה גישה לרשת זו.
• VPC עבור ה Data Science
• צוות ה Data Science זקוק להרשאות Admin ל AWS כי הם מרימים ומורידים מכונות (למשל EMR) בכמויות סיטונאיות, וחס וחלילה לא נרצה שיפגעו בפרודקשיין. "אופס סגרתי לכם 100 מכונות בפרודקשיין, לא שמתי לב בגלל המספר הקטן" - הוא לא מה שאתם רוצים לשמוע...

החלוקה לתתי-ארגונים היא כמובן שיקול ארגוני: לפעמים היא במקום, ולפעמים לא.

כמו כן, ברוב הפעמים המערכת שלנו תהיה מפוזרת בכמה Regions של אמזון. לצורך הפוסט אני מפשט את התמונה ומניח שאנו פעילים רק ב Region יחיד - ה Region (העתידי) של IL-Center-1 ;-) .


כעת נצלול לתמונה המתארת כיצד בערך עשוי להראות VPC שכזה בעולם האמיתי. נבחר ב VPC של הפרודקשיין:

לחצו להגדלה!

1. בתוך ה VPC, יש לנו 2 (בד"כ 3 או 4 - לא היה לי כח לצייר) AZs זהים. בגלל שכל AZ הוא Data Center מבודד פיסית (ואנו רוצים את היתירות הזו) - יהיה עלינו להרכיב subnets סימטרים ב AZs השונים, שיבדלו ע"י טווח כתובות שונה (כלומר: ה CIDR שלהם). כמובן שעדיף לעשות זאת בעזרת כלים אוטומטיים (למשל: Cloud Formation) ולא בצורה ידנית.
   לצורך פשוט התרשים, פירטתי רק את המבנה של AZ סימן a - אנא הניחו ש AZ סימן b הוא סימטרי לחלוטין, גם בתוכן וגם בחיבוריות פנימה והחוצה.
2. ה Traffic שמגיע מבחוץ (משתמשים באינרטנט, למשל) עובר דרך ה DNS של אמזון (קרי: route 53). ה DNS מספק Load Balancing ראשוני בין ה AZs השונים. משם ה Traffic עובר ל Router של אמזון שמנתב אותו כל פעם ל AZ שנבחר.
3. הכניסה הראשונית היא ל subnet "ציבורי" אליו ניתן לגשת מכל מקום באינטרנט, ושם אנו מבצעים את הסינון הראשוני של התעבורה. אמזון מספקת לנו שירות, המגיע כ AMI שעלינו להתקין, שנקרא VPN NAT Gateway - שהוא בעצם Reverse Proxy. רוב הסיכויים שנרצה סינון קצת יותר רציני של Traffic, למשל - WAF (קיצור של Web Application Firewall). לאמזון יש גם שירות שכזה - אך הוא עדיין מאוד בסיסי.
1. אם הרעיון של ה public subnet מזכיר לכם DMZ ברשתות On-Premises זה לא במקרה - זה בדיוק אותו התפקיד, ואותו הרעיון של Layered Security.
4. ה Subnets הפנימיים (נקראים "פרטיים" כי אנו מגבילים את הגישה אליהם) מכילים את חלקי המערכת שלנו. למשל, ה Subnet הראשון אליו מגיעים מכיל את ה Web Server ואנו יוצרים כלל שמאפשר רק לתקשורת שמקורה ב public subnet - להגיע ל subnet הזה.
1. באופן דומה, שירות X יסכים לקבל תקשורת רק מה Web Server או כל Subnet שנגדיר לו.
2. הגדרת הכללים היא קלה: אנו יודעים מה ה CIDR (טווח הכתובות הקבוע) של כל subnet, כך שב Security Group של שירות X אנו נאפשר את ה Subnets (אחד לכל AZs) של ה Web Servers.
   אם מתווספים שרתי ווב חדשים - הם עדיין יהיו בטווח הכתובות של ה subnets, ולכן הכללים שהגדרנו - עדיין יהיו תקפים.
3. אנו יודעים איזה חלק של המערכת אמור לתקשר עם איזה חלק אחר - וכך אנו חוצצים את השירותים שלנו למספר subnets, ע"פ פרופיל התקשורת שלהם: הנכנסת והיוצאת.
   יש ארגונים שיחלקו את הרשת שלהם ל 3-4 פרופילים שכאלו, ויש כאלו שיחלקו ל 50. הכל תלוי במידת האבטחה שאתם רוצים להשיג ועד כמה אתה מוכנים לטרוח בכדי להשיג אותה.
5. כפי שציינתי, גם התקשורת היוצאת היא פרופיל שכדאי לשלוט בו. יהיו מעט התקפות יעילות על הרשת שלכם - שלא יידרשו סוג של קשר עם המתקיף.
1. באופן דומה, נהוג גם את התקשורת היוצאת לסנן בעזרת IDS, WAF, או לפחות NAT פשוט. לאחר הסינון התקשורת תגיע ל Internet Gateway שזה שירות של אמזון (highly available, fully elastic) - שמאפשר את תקשורת הנתונים החוצה.
6. סביר שתרצו לאפשר גם לעובדים במשרד לגשת לחלקים מהמערכת, ולכך יש שירותי VPN. אם אתם רוצים לאפשר גישה מה VPN ל Web Server, יהיה עליכם להגדיר כלל נוסף שמאפשר ל subnet של ה Web Server לקבל תקשורת מה VPC Gateway.
7. הזכרנו שהמוטיבציה העיקרית ל VPC היא אבטחה. עוד שירות חשוב של אמזון הוא ה VPC Flow Logs.
   זהו שירות המאפשר לקבל לוגים על כל התעבורה אל ומחוץ ל VPC.
   ישנם שירותי צד-שלישי (כמו Observe Networks, Dome9, SumoLogic, ועוד) שישמחו לאסוף עבורכם את הלוגים הללו, לנתח אותם, להציג ב Dashboard יפה - ואף לנסות ולאתר אנומליות.

עוד כמה פרטים אחרונים

VPN

ניתן לאפשר ערוץ תעבורה בין המשרד, או כל רשת אחרת ל VPC שלכם על גבי VPN. הרכיב באמזון שמאפשר זאת הוא ה VPN Gateway (בקיצור: VGW, נקרא גם Virtual Private Gateway) היודע לעבוד עם פרוטוקול IPSec VPN.

כל חיבור VPN כולל 2 IPSec Tunnels (ערוצים מוצפנים), כך שאם ערוץ אחד כשל, פרוטוקול ה BGP (קיצור של Border Gateway Protocol) ינתב את התעבורה דרך הערוץ השני. ניתן כמובן להגדיר יותר מ VPN Gateway  - וכך לאפשר יתירות של ארבעה Tunnels ויותר.


AWS Direct Connect

AWS Direct Connect הוא שירות של אמזון לחיבור רשת משופר (קווים שאמזון שוכרת לצורך זה, ככל הנראה) בין VPCs ב Regions שונים לרשת של הארגון שלכם. אם יש יש לכם תעבורה משמעותית בין הרשתות - השירות הזה עשוי להפחית עלויות, לשפר latency ולשפר את האבטחה.

התקשורת ב AWS Direct Connect מבודדת ע"י פרוטוקול VLAN - כך שהיא לא תערבב עם תקשורת של VPCs אחרים.

גם בשימוש ב Direct Connect, ניתן להגדיר Tunnels של VPN כ fallback, במידה וה Direct Connect כושל (בעזרת פרוטוקול BGP).

VPC Peering

זוהי היכולת המאפשרת לחבר בין שני VPCs, בהסכמה הדדית, ובצורה קלה ויעילה. את התעבורה שמגיעה מ VPC אחר ניתן עדיין להעביר דרך Firewall או WAF - במידת הצורך.
ניתן בפועל להשתמש גם ב VPN על מנת לתקשר בין 2 VPCs, אם כי VPC Peering עושה זאת בצורה פשוטה הרבה יותר - ובטוחה באותה המידה.


VPC Endpoint

מאפשר להגדיר ערוץ תקשורת פרטי בין ה VPC לשירות של אמזון (ולא דרך הרשת הכללית של ה Data Center).
כרגע השירות היחידי שתומך ביכולת זו הוא S3 - אך עוד שירותים יתווספו בעתיד.

בכדי להשלים את התמונה, ב S3 Bucket ניתן להגדיר (בעזרת Policy) שיסכים לקבל קריאות רק מתוך VPC endpoint מסוים (ע"פ id) - וכך גם לוודא שלא בטעות פניתם ל Bucket שלא דרך הערוץ המאובטח.

סיכום

Virtual Private Cloud היא במידה מסוימת יכולת "לא סקסית" של AWS - אך חשובה מאוד.
לפני כמה שנים דובר כמה ארגונים חוששים, משיקולי אבטחה, לעבור לענן. ראיתי תצורות רשת של כמה חברות גדולות. רובן היו פרימיטיביות יותר ממה שניתן להשיג בעזרת VPC במאמץ סביר. למשל: לחלק כל שירות ל subnet ולהגביל את סוג התקשורת הנכנסת + היוצאת? מבחינת אבטחה - זה נהדר!  בד"כ ארגונים מספקים רמת שליטה שכזו רק על כל ה Data Center או רק בסיסי הנתונים (כולם, כמקשה אחת).

VPC הוא עוד צעד בבגרות של הענן, וכיום מהווה חלק יסודי מה offering של אמזון. כדאי להכיר.


שיהיה בהצלחה!



---

קישורים רלוונטיים

AWS re:Invent 2015 | (ARC403) From One to Many: Evolving VPC Design

SDD422) Amazon VPC Deep Dive)

25 טיפים להגדרת VPC


---



[א] מהו VLAN - אפשר לקרוא הסבר קצר בפוסט שפירסמתי על OpenStack.

[ב] 4 בדצמבר 2013, לדקדקנים שביננו.