כיצד לייעל את עלויות ה- S3 של אמזון?

שירותי האינטרנט של אמזון (AWS) ובמיוחד שירות האחסון הפשוט (S3) נמצאים בשימוש נרחב על ידי אנשים רבים וחברות לניהול הנתונים, האתרים והתומכים שלהם. אלה נעים בין אנשים בודדים וסטארטאפים קטנים לחברות הערכת שווי של מיליארדי דולרים כמו פינטרסט ו (לשעבר) דרופבוקס. דף זה אינו מיועד כמדריך להעלאת S3; תוכלו למצוא מדריכים רבים אחרים כאלה ברשת. במקום זאת, הוא מיועד לאנשים פרטיים וחברות שעלויות ה- S3 הצפויות שלהן נעות בין 7,50 € לחודש ל- 7460 € לחודש. רשימות עצות דומות אחרות זמינות באופן מקוון.

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

חלק 1 מתוך 6: קבלת הבנה רחבה של s3

1
הבן את מקרה השימוש שלך ב- s3. S3 יכול לשמש למטרות רבות.
- כמקום לאחסון קבצים להצגה חיה באתרים, כולל קבצי תמונה או אתר סטטי שלם (בדרך כלל מאחורי CDN כמו אמזון CloudFront או CloudFlare).
- כ"אגם נתונים ", מקום לנתונים שאתה צורך מהם או מייצר ביישומים שלך: בעיקרו של דבר, S3 הופך לאחסון לטווח הארוך של הנתונים שלך, כאשר הנתונים הראשונים שנוצרו שלך נרשמים ל- S3, ויישומים שונים שקוראים מ- S3, הפיכת הנתונים וכתיבה חזרה ל- S3.
- כ"מחסן נתונים ", מקום לאחסון גיבויים ארוכי טווח של נתונים מובנים ולא מובנים שאינם מיועדים לצריכה פעילה נוספת.
- כמקום לאחסון קבצי הפעלה, סקריפטים ותצורות הדרושים להפעלת מופעי EC2 חדשים עם היישומים שלך (או עדכון היישומים שלך במופעים קיימים).
2
הבן את הדרך העיקרית בה s3 משפיעה על עלויות. המספרים שלהלן מיועדים לאחסון רגיל, אזהרות הקשורות לצורות אחסון אחרות נידונות בהמשך. כל העלויות מוחלות ומדווחות בנפרד עבור כל דלי ולכל שעה; במילים אחרות, אם אתה מוריד את דוח החיוב המפורט שלך, תראה פריט שורה כל אחד עבור כל שילוב של דלי, שעה וסוג עלות.
- עלויות אחסון: העלות נמדדת בשטח האחסון כפול הזמן. אינך משלם מראש עבור כמות שטח אחסון שהוקצתה. במקום זאת, בכל פעם שאתה משתמש באחסון רב יותר, אתה משלם תוספת עבור אותו אחסון נוסף למשך הזמן שאתה משתמש בו. לכן העלויות יכולות להשתנות עם הזמן עם שינוי בכמות הנתונים ששמרת. עלויות האחסון מדווחות בנפרד עבור כל דלי בכל שעה. התמחור משתנה לפי אזור אך הוא קבוע בכל אזור. החל ממרץ 2020 העלות נעה בין 2,3 סנט לחודש ג'יגה בייט בתקן ארה"ב (צפון וירג'יניה) ל -4,05 סנט לחודש ג'יגה-ביי בסאו פאולו.
- תמחור בקשה: עבור אחסון סטנדרטי, העלות לבקשות PUT, COPY, POST או LIST נעה בין 0 € ל 1000 בקשות באזורי ארה"ב ל 0 € לכל 1000 בקשות בסאו פאולו. העלות עבור GET וכל שאר הבקשות היא בסדר גודל קטן יותר, ונע בין 0 € ל 10000 בקשות בכל אזורי ארה"ב ל 0 € לכל 10000 בקשות בסאו פאולו. שים לב, עם זאת, שרוב העלויות הקשורות לבקשת GET נלכדות בעלויות העברת הנתונים (אם הבקשה נעשית מחוץ לאזור). שים לב גם שעבור נתונים המאוחסנים באחסון מסוגים אחרים, תמחור הבקשה מעט גבוה יותר. סוג אחר של בקשות שהופכות רלוונטיות בעת דיון במדיניות מחזור החיים היא בקשת מעבר מחזור החיים (למשל, מעבר של משהו מאחסון רגיל ל- IA או Glacier).
- עלויות העברת נתונים: העלויות הן אפס באותו אזור AWS (שניהם S3 -> S3 ו- S3 -> EC2), בערך 2 סנט ל- GB להעברת נתונים על פני אזורים, וכ- 9 סנט ל- GB עבור העברת נתונים ל- AWS מחוץ.
- תמחור אחזור: זה לא חל על אחסון רגיל, אלא חל על שניים משיעורי האחסון האחרים, כלומר IA ו- Glacier. תמחור זה מוחל על כל GB עבור הנתונים שנאספו.
3
הבן את התפקיד המרכזי שממלאים דליים בארגון קבצי ה- s3 שלך, והשימוש ב"אובייקט "עבור קבצי s3.
- אתה יכול ליצור דליים תחת חשבונך. דלי מזוהה על ידי מחרוזת (שם הדלי). יכולה להיות רק דלי אחד עם שם דלי נתון בכל S3, בין לקוחות; לכן ייתכן שלא תוכל להשתמש בשם דלי אם מישהו אחר כבר משתמש בו.
- כל דלי משויך לאזור AWS ומשוכפל על פני אזורי זמינות מרובים באזור זה. המידע הזמינות באזור אינו זמין למשתמש הקצה, אבל הוא פרט יישום פנימי כי עוזר S3 לשמור עמידות גבוהה וזמינות של נתונים.
- בתוך כל דלי, אתה יכול לאחסן את הקבצים שלך ישירות מתחת לדלי או בתיקיות. אין צורך ליצור או למחוק תיקיות. אם אתה שומר קובץ הוא יביא באופן אוטומטי "תיקיות" לנתיב הקובץ כדי להיות הגיוני, אם הם עדיין לא קיימים. ברגע שאין קבצים מתחתיה, התיקיה מפסיקה להתקיים באופן אוטומטי.
- האופן שבו S3 שומר את המידע הוא כחנות ערך מפתח: עבור כל קידומת שאינה שם קובץ, היא שומרת את קבוצת הקבצים והתיקיות עם קידומת זו. עבור כל שם קובץ, הוא ממפה את זה לקובץ בפועל. בפרט, קבצים שונים בדלי עשויים להיות מאוחסנים בחלקים שונים מאוד של מרכז הנתונים.
- S3 מכנה את הקבצים שלה כ"אובייקטים ", ואתה עלול להיתקל במונח זה כשאתה קורא על S3 במקום אחר.
4
הבן את הדרכים השונות בהן אתה יכול לקיים אינטראקציה עם קבצי s3.
- באפשרותך להעלות ולהוריד קבצים באופן מקוון על ידי כניסה באמצעות דפדפן.
- כלי שורת פקודה המבוססים על Python כוללים את ממשק שורת הפקודה AWS, s3cmd מיושן ו- s4cmd מיושן יותר.
- אם אתה משתמש ב- Java או בשפה אחרת המבוססת על JVM (כגון Scala) תוכל לגשת לאובייקטים S3 באמצעות AWS Java SDK.
- כלי פריסה כגון Ansible ו- Chef מציעים מודולים לניהול משאבי S3.
5
הבן את היתרונות והחסרונות של התמודדות עם s3 ואת ההבדלים בינה לבין מערכת קבצים מסורתית.
- עם S3, זה דורש קצת יותר התעמלות (וזמן ריצה) כדי לקבל תמונה עולמית של כמות הנתונים המשמשת בדלי או בתיקיות משנה של אותו דלי. הסיבה לכך היא שנתונים אלה אינם מתועדים ישירות בשום מקום אלא יש לחשב אותם באמצעות בדיקות רקורטיביות של ערך מפתח.
- מציאת כל הקבצים התואמים ל- regex יכולה להיות פעולה יקרה מאוד, במיוחד כאשר regex זה כולל כרטיסי בר באמצע הביטוי ולא בסוף.
- לא ניתן לבצע פעולות כמו הוספת נתונים לקובץ: עליכם להשיג את הקובץ, לשנות אותו ואז לשים את כל הקובץ שהשתנה מחדש (ראו את הנקודה בהמשך על יכולות הסינכרון).
- העברה או שינוי שם של קבצים כרוך למעשה במחיקת אובייקטים ויצירת חדשים. העברת תיקיה כוללת מחיקה ויצירה מחדש של כל האובייקטים שמתחתיה. כל העברת קבצים כוללת שיחת GET ושיחת PUT, מה שמוביל לתמחור מוגדל של בקשות. יתר על כן, עצמים נעים יכולים להיות יקרים אם האובייקטים מאוחסנים בכיתות אחסון (Standard-IA ו- Glacier) שם האחזור עולה כסף.
- S3 יכול לתמוך בגדלי קבצים של עד 5 TB, אך העברת נתונים בין אזורים עשויה להתחיל להתבלבל בגדלי קבצים של יותר מכמה מאות מגה. ה- CLI משתמש בהעלאה מרובת חלקים עבור קבצים גדולים. וודא שאם התוכניות שלך עוסקות בקבצים גדולים, הן פועלות באמצעות העלאה מרובת חלקים, או פיצול הפלט לקבצים קטנים יותר.
- S3 אינו מספק תמיכה מלאה ב- rsync. עם זאת, יש פקודת סינכרון (aws s3 sync ב- AWS CLI ו- s3cmd sync ב- s3cmd) המסנכרנת את כל התוכן בין תיקיה מקומית לתיקיית S3, או בין שתי תיקיות S3. עבור קבצים שקיימים במקור ובתיקיית היעד, הוא יכול לזהות קבצים זהים ולהימנע מהעברת נתונים אם הקבצים זהים; עם זאת, היא אינה יעילה כמו rsync בכך שהיא עשויה להזדקק להעברה מלאה אם הקבצים נבדלים מעט, ואילו rsync שולח רק הבדל קטן עבור קבצים דומים מאוד. ההבדל הנוסף ל- rsync הוא שהוא חל על תיקיה שלמה, ולא ניתן לשנות את שמות הקבצים.

אם אתה משכפל את הדלי במזרח ארה"ב, אתה משלם פעם אחת בלבד עבור עלויות העברת הנתונים.

חלק 2 מתוך 6: מיקוד / דחיסת נתונים

1
ודא שאתה דוחס נתונים כאשר הדרישות של היישום שלך מותרות לפני שתתחיל.
- בדקו אילו צורות של רוכסן ודחיסה תואמות לתהליכים בהם אתם משתמשים ליצירת נתונים, ואל התהליכים בהם אתם משתמשים לקריאה ולעיבוד נתונים.
- וודא שאתה משתמש ברוכס ודחיסה עבור השלכות הנתונים הגדולות ביותר שלך, במידה וזה לא מפריע ליישום שלך. בפרט, יומני משתמשים גולמיים ונתונים מובנים המבוססים על פעילות המשתמשים הם המועמדים העיקריים לדחיסה.
- ככלל, דחיסה תחסוך לא רק בעלויות האחסון אלא גם בעלויות ההעברה (בעת קריאת / כתיבת הנתונים) ואולי אף תהפוך את היישום למהיר יותר אם זמן ההעלאה / ההורדה הוא צוואר בקבוק גדול יותר מזמן הדחיסה / דחיסה המקומי.. זה לעתים קרובות המקרה.
- אם ניקח דוגמא להמרת קבצי נתונים מובנים גדולים לפורמט BZ2 יכול לגרום למרחב האחסון לרדת בגורם המשתנה בין 3 ל -10; עם זאת, BZ2 הוא עתיר מחשבים לצורך מיקוד ופתיחה של רוכסן. אלגוריתמי דחיסה אחרים שיש לקחת בחשבון הם gzip, lz4 ו- zstd.
- דרכים אפשריות אחרות לצמצום השטח כוללות שימוש באחסון מבוסס עמוד ולא באחסון מבוסס שורה, ושימוש בפורמטים בינאריים (כגון AVRO) במקום בפורמטים הניתנים לקריאה אנושית (כגון JSON) לשמירת נתונים לטווח ארוך.
2

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

חלק 3 מתוך 6: מיטוב עלויות האחסון

1
הבן את ההבדלים בין ארבעת סוגי אחסון ה- s3.
- אחסון סטנדרטי הוא היקר ביותר לאחסון, אך הוא הזול והמהיר ביותר לביצוע שינויים בנתונים. הוא מיועד לעמידות של 99,999999999% (מעל לשנה, כלומר זהו החלק הצפוי של אובייקטים S3 שישרדו במשך שנה) וזמינות של 99,99% (זמינות המתייחסת להסתברות שאובייקט S3 נתון נגיש בזמן נתון). שים לב שבפועל, נדיר מאוד לאבד נתונים ב- S3, ויש גורמי סיכון גדולים יותר לאובדן נתונים מאשר נתונים שנעלמים ממש מ- S3 (גורמים גדולים אלה כוללים מחיקת נתונים בשוגג ומישהו שנפרץ בזדון לחשבונך כדי למחוק תוכן, או אפילו אמזון נאלצת למחוק את הנתונים שלך בגלל לחץ מצד ממשלות).
- אחסון יתירות מופחת (RRS) היה זול יותר ב -20% מאחסון רגיל ומציע מעט פחות יתירות. ייתכן שתרצה להשתמש בו עבור הרבה נתונים שלך שאינם קריטיים במיוחד (כגון יומני משתמש מלאים). זה מיועד לעמידות של 99,99% וזמינות של 99,99%. עם זאת, נכון לדצמבר 2016, הפחתות מחירים שנערכו באחסון רגיל לא לוו בהוזלות מחירים תואמות ל- RRS, כך ש- RRS כרגע שווה או יקר יותר.
- אחסון סטנדרטי - גישה נדירה (הנקראת S3 - IA) היא אפשרות שהציגה אמזון בספטמבר 2015, המשלבת את העמידות הגבוהה של S3 עם זמינות נמוכה של 99% בלבד. זוהי אפשרות לאחסון ארכיונים ארוכי טווח שאין צורך לגשת אליהם לעיתים קרובות, אך כאשר יש לגשת אליהם, יש לגשת אליהם במהירות. S3 - IA מחויב מינימום של 30 יום (גם אם אובייקטים נמחקים לפני כן) וגודל אובייקט מינימלי של 128 KB. זה יקר בערך מחצית מ- S3, אם כי ההנחה המדויקת משתנה לפי אזור.
- קרחון הוא צורת האחסון הזולה ביותר. עם זאת, קרחון עולה כסף כדי לבטל את הארכיון ולהעמיד אותו לרשות הקריאה והכתיבה, כאשר הסכום שעליכם לשלם תלוי במספר בקשות האחזור, המהירות בה אתם רוצים לאחזר את הנתונים וגודל הנתונים שיאוחזרו. כמו כן, לקבצי הקרחון יש תקופת אחסון של 90 יום לכל הפחות: קבצים שנמחקו לפני כן יחויבו בשארית 90 הימים לאחר המחיקה.
2
קבל תחושה איך העלויות שלך גדלות.
- במקרה שימוש שבו יש לך קבוצה קבועה של קבצים שאתה מעדכן מעת לעת (מסיר למעשה גרסאות ישנות יותר) עלויות האחסון החודשיות שלך קבועות בערך, עם גבול עליון הדוק למדי. הוצאות האחסון המצטברות שלך גדלות באופן ליניארי. זהו תרחיש אופייני לקבוצת הפעלות וסקריפטים.
- במקרה שימוש בו אתה מייצר ללא הרף נתונים חדשים בקצב קבוע, עלויות האחסון החודשיות שלך גדלות באופן ליניארי. עלות האחסון המצטברת שלך גדלה באופן ריבועי.
- במקרה שימוש בו קצב ייצור הנתונים עצמו גדל באופן ליניארי, עלויות האחסון החודשיות שלך גדלות באופן ריבוע, ועלות האחסון המצטברת שלך גדלה בהתמדה.
- במקרה שימוש בו קצב ייצור הנתונים גדל באופן אקספוננציאלי, גם עלות אחסון הנתונים החודשית שלך וגם עלות אחסון הנתונים המצטברת שלך גדלות באופן אקספוננציאלי.
3
בדוק האם גרסאות אובייקטים הגיוניות למטרותיך.
- גרסאות אובייקטים מאפשרות לכם לשמור גרסאות ישנות יותר של קובץ. יתרון אחד הוא שאתה יכול לבקר מחדש בגרסה ישנה יותר.
- בעת שימוש בגירסאות אובייקטים, ניתן לשלב אותו עם מדיניות מחזור חיים כדי לפרוש גרסאות ישנות מגיל מסוים (אם לא הגרסה הנוכחית).
- אם אתה משתמש בגירסאות אובייקטים, זכור שרק רישום קבצים (באמצעות aws s3 ls או בממשק המקוון) יגרום לך להמעיט בערך האחסון הכולל בשימוש, מכיוון שאתה מחויב בגין גרסאות ישנות יותר שאינן כלולות ברשימה.
4
חקור את מדיניות מחזור החיים עבור הנתונים שלך.
- ניתן להגדיר מדיניות למחיקה אוטומטית של נתונים בדליים מסוימים, או אפילו עם קידומות מסוימות בתוך דליים, זה יותר ממספר מסוים של ימים. זה יכול לעזור לך לשלוט טוב יותר בעלויות S3 שלך וגם לעזור לך לעמוד במדיניות פרטיות ונתונים שונים. שים לב כי כמה חוקים ומדיניות שמירת נתונים עשויים לדרוש ממך לשמור על נתונים לזמן מינימלי; אלה מציבים גבול תחתון בזמן שאחריו תוכל למחוק נתונים במדיניות מחזור החיים שלך. מדיניות או חוקים אחרים עשויים לדרוש ממך למחוק נתונים בתוך פרק זמן מסוים; אלה מציבים גבול עליון על הזמן שאחריו צריך למחוק נתונים במדיניות מחזור החיים שלך.
- עם מדיניות מחזור חיים למחיקה, האופן שבו העלויות שלך גדלות משתנה מאוד. כעת, עם זרם קבוע של נתונים נכנסים, עלויות האחסון החודשיות שלך נשארות קבועות ולא גדלות באופן ליניארי, מכיוון שאתה שומר רק חלון נתונים זז ולא כל הנתונים עד כה. גם אם גודל הנתונים הנכנסים גדל באופן ליניארי, עלויות האחסון החודשיות שלך רק גדלות באופן ליניארי ולא באופן ריבועי. זה יכול לעזור לך לקשור את עלויות התשתית למודל ההכנסות שלך: אם ההכנסה החודשית שלך פרופורציונלית בערך לקצב שבו אתה מקבל נתונים, מודל האחסון שלך ניתן להרחבה.
- מגבלה טכנית: אינך יכול להגדיר שתי מדיניות עם אותו דלי כאשר קידומת אחת היא קבוצת משנה של השנייה. זכור זאת כשאתה חושב כיצד לאחסן את נתוני S3 שלך.
- בנוסף למדיניות מחזור החיים למחיקה, תוכל גם להגדיר מדיניות לארכיון הנתונים (כלומר להמיר אותם מאחסון רגיל לקרחון), ולהפחית את עלויות האחסון. עם זאת, לקרחון תקופת שמירה מינימלית של 90 יום: אתה מחויב בגין אחסון של 90 יום בקרחון, גם אם תבחר למחוק אותו לפני כן. לכן, אם אתה מתכוון למחוק בקרוב, כנראה שזה לא רעיון טוב לעבור לקרחון.
- תוכל גם לקיים מדיניות מחזור חיים להמרת נתונים ב- S3 (אחסון רגיל) ל- S3 - IA. מדיניות זו אידיאלית עבור נתונים שאתה מצפה לגשת אליהם לעתים קרובות מייד לאחר יצירתם, אך לעתים רחוקות לאחר מכן. לקבצים ב- IA יש גודל אובייקט מינימלי (אתה מחויב בגודל של קובץ 128 KB עבור קבצים קטנים יותר מזה) ותקופת שמירה של 30 יום מינימלית.
- שים לב כי מעברי מחזור החיים עצמם עולים כסף, ולעתים קרובות עדיף ליצור אובייקטים ישירות במחלקת האחסון הרצויה במקום להעביר אותם. יהיה עליך לבצע את החישובים למקרה השימוש שלך כדי לדעת האם ומתי יש אפשרות להעביר את מחזור החיים.
5
השתמש ביוריסטיות הבאות לקביעת מחלקת האחסון הטובה ביותר בהתבסס על מקרה השימוש שלך. בזמן שאנחנו מדברים כאילו עסקינן בקובץ יחיד, אנחנו באמת חושבים על תוכנית שבה זה קורה בנפרד ובאופן עצמאי למספר רב של קבצים.
- השלב הראשון לקביעת מחלקת האחסון הנכונה הוא לקבל אומדן לגודל הקובץ, לתקופת השמירה, למספר הגישות הצפוי (כמו גם לשינוי מספר זה לאורך זמן בהתאם לגיל) ולפרק הזמן המרבי שתוכל לחכות. כשאתה כן צריך לגשת למשהו. אתה יכול להשתמש בכל אלה כפרמטרים לנוסחה המחשבת את העלות הצפויה לשימוש בכל מחלקת אחסון. הנוסחה מסתבכת למדי.
- לידיעתך, הספים המדויקים עבור אלה יכולים להשתנות בהתאם למחירים הנוכחיים באזור שלך. המחירים משתנים לפי אזור וממשיכים להשתנות לאורך זמן. בפרט העניין הבא: תמחור אחסון לכל מחלקת אחסון, תמחור בקשה לכל מחלקת אחסון, תמחור אחזור לכל מחלקת אחסון, ודרישות מינימום לגודל ולמינימום תקופת שמירה. עם אזהרות אלה, היוריסטיקה למטה.
- אם בכוונתך לשמור נתונים למשך שבועיים או פחות, אחסון רגיל עדיף על פני IA ועל אחסון של קרחונים. הסיבה היא שתקופות השמירה המינימליות (30 יום עבור IA, 90 יום עבור קרחון) מבטלות את יתרונות העלות (לכל היותר כפולים עבור IA, בערך שש פעמים עבור הקרחון) בשבועיים או פחות.
- אם גודל הקובץ שלך הוא 64 קילו-בייט או פחות, אחסון רגיל תמיד מכה את אחסון ה- IA. הסיבה לכך היא שדרישת הגודל המינימלי של IA (128 KB) מבטלת את יתרון העלות (לכל היותר כפול).
- אם אתה מתכוון לגשת לכל קובץ פעם בחודש או בתדירות גבוהה יותר, אז האחסון הסטנדרטי זוכה ביחס ל- IA וגם ל- Glacier. הסיבה לכך היא העלות הנוספת של אפילו אחזור נתונים אחד הורסת את חיסכון האחסון החודשי.
- נניח שיש לך נתונים שאתה צריך לשמור בתחילה באחסון רגיל למשך חודש, ולאחר מכן אתה בסדר עם העברתם ל- IA למשך חודש ויותר, מכיוון שאתה מצפה שלא תצטרך לגשת אליו בכלל לאחר מכן. הגיוני להעביר אותו ל- IA רק אם המספר הכולל של מגה-בייט במצב IA לכל קובץ הוא לפחות 1. הסיבה לכך היא שחיסכון בעלויות צריך להתגבר על עלות מעבר מחזור החיים של מעבר ל- IA. למשל, אם ברצונך לשמור את הנתונים למשך חודש נוסף, גודל הקובץ צריך להיות לפחות 1 מגהבייט כדי שזו תהיה הוצאה משתלמת. שים לב שהתקופה המינימלית של 30 יום הופכת מעברים לזמנים קצרים אפילו פחות כדאיים.
- באופן דומה, עבור המעבר לקרחון, ההפסקה היא בערך 2,5 מגה-בייט-חודשים לכל קובץ. שים לב, עם זאת, תקופת השמירה המינימלית של 90 יום בקרחון מסבכת את העניינים; אם בכוונתך להפיק תועלת מהעברת נתונים אל קרחון למשך חודש, גודל הקובץ צריך להיות 7,5 מגה או יותר.
- אם אתה מצפה שלא תצטרך לגשת לתוכן לאחר כתיבתו ל- S3, האסטרטגיה האופטימלית היא בדרך כלל רגילה או קרחון, כאשר המסחר תלוי בתקופת השמירה. עם זאת, יש נקודה מתוקה ש- IA היא האפשרות הטובה ביותר (למשל, אחסון של 128 KB למשך חודש אחד). כדי להמחיש זאת, להלן תמונה למקרה הפשוט שבו אתה צריך לשמור קובץ יחיד של קבוע. גודל למשך זמן קבוע, עם אפס גישה צפויה לאחר שמירתו. הזמן בחודשים הוא על הציר האופקי וגודל הקובץ ב- GB הוא על ציר ה- y. נקודה היא בצבע כחול, אדום או צהוב, תלוי אם מחלקת האחסון האופטימלית מבחינת עלות היא סטנדרטית, IA או קרחון. אנו משתמשים בעלויות כמו באזור התקן האמריקני בדצמבר 2016.
- ככל שאתה מגדיל את מספר הגישות הצפוי של הנתונים, הסטנדרט הופך להיות אופטימלי עבור יותר ויותר מקרי שימוש (כלומר, עבור גדלי נתונים גדולים יותר ולתקופות שמירה ארוכות יותר). IA מתחיל להיות אופטימלי גם במקרים בהם בעבר היה קרחון אופטימלי. במילים אחרות, תקן משתלט על ידי IA ו- IA משתלט על קרחון.
6
השתמש במדדי ההיגיון הבריא הבאים על סמך מקרה השימוש שלך באחסון. זה יעזור לך להבין כמה צפוי בעלויות האחסון.
- אם אתה משרת אתר או תמונות סטטיים בשידור חי: סביר להניח שעלויות האחסון יהיו כמה סנטים, עם פרטים בהתאם לגודל האתר שלך. העלויות העיקריות של שירות אתר חי הן עלויות תמחור הבקשה והעברה.
- אם אתה מאחסן אגם נתונים שהזרם הראשי שנוצר על ידי המשתמש הוא פעילות באינטרנט או באפליקציה (כלומר יומני בקשות אינטרנט): שורת יומן רישום של בקשת אינטרנט יכולה להשתנות בגודל מרבי מ -1 KB (אם תשמור על כל הכותרות הרגילות ו שדות) עד 10 KB (אם אתה כולל גם מידע היקפי על המשתמש וההקשר). אם אתה מקבל מיליון בקשות אינטרנט בחודש ושומר יומני בקשות אינטרנט ישנים למשך חודש, זה מתבטא במקום כלשהו בין 1 ג'יגה-בייט לאחסון אחסון, שעלותם היא אחסון חודשי בין 2,3 סנט ל -40,5 סנט. העלות מתרחבת באופן ליניארי הן עם התנועה שלך והן עם ההחלטה שלך כמה זמן לאחסן. לדוגמא, עם מיליארד בקשות אינטרנט בחודש ואחסון נתונים למשך שנה, העלות החודשית לאחסון הנתונים שלך עולה עד איפשהו בין 210 € ל 3630 € שימוש בפורמטים בינאריים ורוכסן / דחיסה יכול להוזיל את העלויות.
- אם אתה שומר ארכיונים של תמונות וצילומי וידיאו: למשל, אם אתה רשת טלוויזיה שמצלמת צילומים באופן קבוע ורוצה לשמור על ארכיונים של תמונות ישנות למקרה שזה יהיה רלוונטי מאוחר יותר. זהו מקרה שימוש בו שטח האחסון הכולל יכול להיות משמעותי למדי. לדוגמה, עם 10 שעות של צילומי וידיאו יומיים, אתה יכול להוסיף משהו בטווח של 100 ג'יגה-בתים (לא דחוס) מדי יום. אם אתה מציב את הסרט הזה באחסון רגיל בשנה הראשונה ואז מעביר בארכיון ל- Glacier עוד תשע שנים, הנתונים הכוללים שלך יגיעו ל 365 TB (36,5 TB באחסון רגיל) ועלויות האחסון החודשיות שלך ב- S3. (לפני דחיסה) יעמוד על כ- 1640 € (שני שלישים עבור קרחון, ושליש עבור אחסון רגיל). דחיסה מסוגים שונים יכולה להפחית את עלויות האחסון בגורם המשתנה בין 2 ל -10.
- זה מאלף לבחון את החשבונות של כמה משתמשי S3 חשמליים כדי להבין עד כמה החיוב יכול להשתנות.
  - ל- Dropbox דווח כי יש 500 פטא-בייטים של נתונים ב- S3 לפני שהועבר לשרתים שלה במחירים הנוכחיים שצוטטו באופן מקוון, זה יעלה כ- 7,80 מיליון אירו לחודש. אף על פי שדרופבוקס ככל הנראה קיבלה הנחה משמעותית והשיגה יתרונות מכיסוי נתונים ודחיסתם, סביר להניח שהחשבון שלה עדיין היה לפחות מאות אלפי דולרים בחודש.
  - דוגמא קיצונית נוספת למשתמש גדול היא DigitalGlobe, שמעבירה 100 PB של תמונות לוויין ברזולוציה גבוהה ל- S3.
  - Pinterest דיווחה כי היא מוסיפה 20 טרה-בייט של נתונים ביום, אשר באחסון רגיל פירושם שהחשבון החודשי שלהם יעלה ב -450 € לחודש בכל יום. אם קצב תוספת נתונים זה יימשך עשר שנים, יהיה להם אחסון כולל של כ- 75 PB וחשבון חודשי בסדר גודל של מאות אלפי דולרים.
  - מעבר למקרי שימוש קיצוניים אלה, אפילו לחברות הגדולות בעולם יש חשבונות S3 נמוכים למדי. למשל, בסוף 2013 דיווחה Airbnb שיש לה 50 TB של תמונות תמונה ביתיות ברזולוציה גבוהה, סכום שיעלה כ- 860 € לחודש במחירים של היום.

הבן את התפקיד המרכזי שממלאים דליים בארגון קבצי ה- s3 שלך, והשימוש ב"אובייקט "עבור קבצי s3.

חלק 4 מתוך 6: מיטוב עלויות העברת נתונים

1
אם אתה משתמש ב- s3 לתוכן המגיש בשידור חי, שים אותו מאחורי CDN כגון Amazon Cloudfront, Cloudflare או Maxcdn.
- ל- CDN מספר רב של מיקומי קצה באזורים שונים בעולם, בדרך כלל נע בין עשרות למאות.
- בקשת המשתמש לדף מנותבת למיקום הקצה הקרוב ביותר של CDN. מיקום קצה זה בודק אם יש לו עותק מעודכן של המשאב. אם לא, זה מביא אותו מ- S3. אחרת הוא משרת את העותק שיש לו.
- התוצאה: משתמשי הקצה רואים זמינות גבוהה יותר וחביון נמוך יותר (מכיוון שהמשאבים מוגשים ממיקום קרוב פיזית אליהם) ומספר הבקשות וכמות העברת הנתונים מ- S3 נשמר נמוך. באופן מפורש, מספר הבקשות מוגבל על ידי (מספר מיקומי קצה) X (מספר קבצים) אם לעולם לא תעדכן קבצים; אם אתה מעדכן קבצים עליך להכפיל גם במספר עדכוני הקבצים.
2
הבן את היתרון המרכזי במיקום משותף של ec2 / s3. אם השימוש העיקרי שלך ב- S3 הוא קריאה וכתיבה של נתונים למופעי EC2 (כלומר, כל אחד ממקרי השימוש שאינם מופע ההגשה החי), אז יתרון זה ייקצר בצורה הטובה ביותר אם דלי ה- S3 שלך ממוקם באותו AWS אזור כמו מקרים של EC2 שקוראים או כותבים אליו. יהיו לכך מספר יתרונות:
- השהיה נמוכה (פחות משנייה)
- רוחב פס גבוה (העולה על 100 מגה ביט / שנייה): שים לב שרוחב הפס הוא למעשה די טוב בין האזורים השונים בארה"ב, כך שזה לא נושא משמעותי אם כל האזורים שלך נמצאים בארה"ב, אבל זה יכול להיות משמעותי בין ארה"ב לבין האיחוד האירופי, האיחוד האירופי ואסיה-פסיפיק, או ארה"ב ואסיה-פסיפיק.
- אין עלויות העברת נתונים (עם זאת, אתה עדיין משלם את תמחור הבקשה)
3
קבע את המיקום (אזור AWS) של דלי s3 שלך.
- אם אתה מפעיל מופעי EC2 שקוראים או כותבים לדלשי S3: כפי שצוין בשלב 1, מיקום S3 ו- EC2, במידה האפשרית, עוזר בעלויות רוחב הפס, השהיה והעברת נתונים. לכן, שיקול חשוב באיתור דלי ה- S3 שלך הוא: היכן אתה מצפה שיהיו מקרי EC2 אשר יתקשרו עם דלי S3 זה? אם מופעי EC2 הם בעיקר מופעי backend, עליך לשקול את העלויות של מופעים אלה. אם הם מקרים חזיתיים, שקול מאיזורים אתה מצפה לקבל את מרבית התנועה שלך. בגדול, עליכם לצפות ששיקולי מופעי EC2 יהיו חשובים יותר משיקולי S3 בקביעת האזור. אז בדרך כלל הגיוני להחליט תחילה היכן אתה מצפה שיכולת המופע שלך ב- EC2 תהיה, ואז יהיה שם את דלי ה- S3 שלך. בכללי,עלויות S3 נמוכות יותר באותם אזורים שבהם מופעי EC2 הם, כך שלמרבה המזל זה לא יוצר סכסוך.
- אם ישנם שירותי AWS אחרים שאתה חייב להחזיק, אך אינם זמינים בכל האזורים, הדבר עשוי גם להגביל את בחירתך באזור.
- אם אתה מעלה לעיתים קרובות קבצים מהמחשב הביתי שלך ל- S3, תוכל לשקול להשיג דלי באזור קרוב יותר לביתך, כדי לשפר את זמן ההשהיה. עם זאת, זה צריך להיות שיקול מינורי ביחס לאחרים.
- אם אתה מצפה להשתמש ב- S3 לתמונות סטטיות בהגשה בשידור חי, בחר את המיקום על סמך המקום שאתה מצפה לקבל ממנו את התנועה.
- במקרים מסוימים, המדיניות שאתה מחויב לנהוג על פי חוק או חוזה מגבילה את בחירתך באזור לאחסון נתונים S3. זכור גם כי המיקום הפיזי של דלי ה- S3 שלך יכול להשפיע על מה שממשלות מסוגלות לחייב את אמזון באופן חוקי לפרסם את הנתונים שלך (אם כי אירועים כאלה הם נדירים למדי).
4
בדוק אם שכפול בין אזורים הגיוני לדלי שלך. שכפול בין אזורים בין דליים באזורים שונים מסנכרן אוטומטית עדכונים לנתונים בדלי אחד עם נתונים בדליים אחרים. ייתכן שהשינוי לא יקרה באופן מיידי, ושינויים בקבצים גדולים במיוחד מוגבלים על ידי מגבלות רוחב הפס בין האזורים. זכור את היתרונות והחסרונות הבאים של שכפול בין אזורים.
- אתה משלם יותר בעלויות אחסון S3, מכיוון שאותם נתונים מראים על פני אזורים מרובים.
- אתה משלם ב- S3 <-> עלויות העברת נתונים S3. עם זאת, אם הנתונים נקראים או נכתבים על ידי מופעי EC2 באזורים מרובים, יתכן שזה יקוזז על ידי חיסכון בעלויות העברת הנתונים S3 -> EC2. הדרך העיקרית שבה זה יכול לעזור היא אם אתה טוען את אותם נתוני S3 למופעי EC2 באזורים רבים ושונים. לדוגמה, נניח שיש לך 100 מופעים בכל מזרח ארה"ב ומערב ארה"ב שבהם עליך לטעון את אותם נתונים מדלי S3 במערב ארה"ב. אם אינך משכפל דלי זה במזרח ארה"ב, אתה משלם עבור עלות ההעברה של 100 העברות הנתונים מהדלי S3 למכונות מזרח ארה"ב. אם אתה משכפל את הדלי במזרח ארה"ב, אתה משלם פעם אחת בלבד עבור עלויות העברת הנתונים.
- שכפול חוצה-אזורים הגיוני מאוד עבור הפעלות, סקריפטים ונתונים סטטיים יחסית, שבהם אתה מעריך יתירות חוצה-אזורים, כאשר עדכונים לנתונים אינם שכיחים, וכאשר רוב העברת הנתונים היא ב- S3 -> EC2 כיוון. יתרון נוסף הוא שאם נתונים אלה משוכפלים על ידי אזורים, זה הרבה יותר מהר לסובב מקרים חדשים, מה שמאפשר ארכיטקטורות גמישות יותר של מופעי EC2.
- ליישומי רישום (כאשר הנתונים נקראים על ידי מקרים רבים של frontend ויש צורך לרשום אותם במיקום מרכזי ב- S3) עדיף להשתמש בשירות כגון Kinesis לאיסוף זרמי נתונים על פני אזורים במקום להשתמש בדליים S3 משוכפלים בין אזורים..
- אם אתה משתמש ב- S3 לצורך הגשה חיה של תמונות סטטיות באתר, שכפול בין אזורים עשוי להיות הגיוני אם תעבורת האתר שלך היא גלובלית וטעינה מהירה של תמונות חשובה.
5
אם אתה מסנכרן עדכונים שוטפים לקבצים קיימים, בחר במבנה תיקיות המאפשר שימוש בתכונת הסינכרון של AWS cli.
- הפקודה "aws s3 sync" מתנהגת כמו rsync, אך ניתן להריצה רק ברמה של תיקיה. לכן שמור על מבנה התיקיות שלך כך שתוכל להשתמש בפקודה זו.
6
זכור את היוריסטיקה הבאה לאמידת עלויות ההעברה.
- עבור אתר סטטי חי המשרת, העברת נתונים חודשית, ללא CDN, שווה לגודל זמני התנועה הכולל של כל עמוד שביקר (כולל תמונות ומשאבים אחרים הנטענים בדף). לדוגמה, עבור מיליון צפיות בדף וגודל עמוד ממוצע של 100 KB, הנתונים הכוללים הם 100 GB, ועלותם 6,70 € לחודש.
- עבור אתר סטטי המשרת בשידור חי מאחורי CDN, ה- CDN מטיל גבול עליון על העברת הנתונים הכוללת החוצה. באופן ספציפי, אם אינך מעדכן את הנתונים כלל, כך שה- CDN יגיש מטמון משלו, העברת הנתונים הכוללת החוצה מוגבלת על ידי המוצר בגודל הכולל של אתר האינטרנט שלך ומספר מיקומי הקצה של ה- CDN, ללא קשר לתנועה. כרך. לדוגמה, אם האתר שלך כולל סך של 1000 עמודים בני 100 KB כל אחד, הגודל הכולל הוא 100 מגהבייט. אם ישנם 100 מיקומי קצה, זה נותן מגבלת העברת נתונים כוללת של 10 GB לחודש, או מגבלת עלות של 90 סנט לחודש. עם זאת, אם אתה מעדכן חלק מהקבצים, עליך לספור כל קובץ שוב לאחר כל עדכון.
- המידה בה נשמרים CDN ביחס לחוסר CDN תלויה במגוון הגישה לתוכן שלך וגם בפיזור הגישה הגיאוגרפי. אם ניתן לגשת לתוכן שלך באזור גיאוגרפי אחד, תחסוך יותר. אם אנשים ניגשים למספר קטן של עמודים באתר שלך, תחסוך יותר. אם, בתוך כל אזור, אנשים ניגשים למספר קטן של עמודים באתר שלך (גם אם הדפים שונים לפי אזור), תחסוך יותר. חיסכון ב- CDN יכול לנוע בין 50% ל -99%.

קרא גם: איך למכור משחקים באמזון?

חלק 5 מתוך 6: אופטימיזציה של עלות עקב תמחור בקשה

1

אם תמחור בקשה הוא עניין משמעותי, שמור את הנתונים שלך באחסון רגיל. ראה חלק 3, שלב 5 למידע נוסף.
2

אם משרת בשידור חי אתר סטטי או תמונות סטטיות או וידאו דרך s3, שים אותו מאחורי CDN. זאת מאותן סיבות לאלו שנדונו בחלק 4, שלב 1.
3
אם אתה משתמש ב- s3 כחנות נתונים לחיפוש ערך מפתח, עליך להחליף תמחור של בקשת PUT מול תמחור העברת נתונים בעת קביעת גודל הקבצים שאתה צריך לנתק את הנתונים שלך.
- אם אתה מחלק את הנתונים למספר גדול של קבצים קטנים, עליך להוסיף מספר רב של PUTs כדי להוסיף את הנתונים, אך כל בדיקה מהירה יותר ומשתמשת בהעברת נתונים פחות מכיוון שאתה צריך לקרוא קובץ קטן יותר מ- S3.
- מצד שני, אם אתה מחלק את הנתונים למספר קטן של קבצים גדולים, אז אתה צריך מספר קטן של PUTs, אבל כל גישה עולה הרבה בעלות העברת נתונים (כמו שאתה צריך לקרוא קובץ גדול).
- הפשרה בדרך כלל מתרחשת איפשהו באמצע. מתמטית, מספר הקבצים שבהם עליך להשתמש הוא השורש הריבועי של היחס בין מונח עלות העברת נתונים לטווח עלות PUT.
4

באופן כללי, שימוש במספר קטן יותר של קבצים בינוניים עדיף לאגם נתונים.
5
אם אתם מחלקים נתונים בין קבצים, השתמשו במספר קטן של קבצים בינוניים (איפשהו בין 1 מגה-בייט ל -100 מגה-בייט) כדי למזער תמחור בקשות ועומס יתר.
- מספר קטן יותר של קבצים גדולים מצמצם את מספר הבקשות הדרושות לאחזור והטעינה של הנתונים, כמו גם לכתיבת הנתונים.
- מכיוון שיש חביון קטן המשויך לכל קריאת קובץ, תהליכי מחשוב מבוזרים (כגון תהליכים מבוססי Hadoop או Apache Spark) שקוראים קבצים בדרך כלל יתנהלו מהר יותר עם מספר קטן של קבצים בינוניים מאשר עם גדול מספר קבצים קטנים.
- ככל שמספר הקבצים הכולל שלך פחות, כך פחות יקר להריץ שאילתות שמנסות להתאים לביטויים רגולריים שרירותיים.
- אזהרה חשובה היא שבמקרים רבים, סוג הפלט הטבעי הוא מספר רב של קבצים קטנים. זה נכון לגבי הפלטים של עומסי מחשוב מבוזרים, כאשר כל צומת באשכול מחשב ומפיק קובץ קטן. זה נכון גם אם הנתונים נכתבים בזמן אמת ואנחנו רוצים לכתוב את הנתונים תוך פרק זמן קצר. אם אתה מצפה לקרוא ולעבד נתונים אלה שוב ושוב, שקול לכנס את הנתונים לקבצים גדולים יותר. כמו כן, עבור נתונים המגיעים בזמן אמת, שקול להשתמש בשירותי הזרמה כגון Kinesis לאיסוף נתונים לפני כתיבתם ל- S3.
6

אם אתה רואה עלויות בקשות בלתי צפויות גדולות, חפש תהליכים נוכלים שעושים התאמת regex. ודא שכל התאמת regex משתמשת בתווים כלליים קרוב ככל האפשר לסוף הקובץ.
7
זכור את היוריסטיקה הבאה לעלויות בקשה.
- עלויות הבקשה צריכות להיות בין 0% ל -20% מעלויות האחסון. אם הם גבוהים יותר, שקול אם אתה משתמש בכיתת האחסון הנכונה, מחלק את הנתונים בגדלים הנכונים או מבצע פעולות מיותרות או לא יעילות. בדוק גם אם יש מעברי סגנון חיים מיותרים, כמו גם תהליכי התאמת regex נוכלים.
- עלויות הבקשות צריכות להיות פחות מעלויות ההעברה אם הנתונים שלך נשלחים בעיקר אל מחוץ ל- AWS (אם הנתונים שלך נשלחים באותו אזור AWS, לא אמורות להיות עלויות העברת נתונים, כך שזה לא חל, שכן עלויות הבקשה יהיו חיובי בעוד שעלויות ההעברה יהיו אפסות).

ברמה הגבוהה, ייתכן שתרצה לדווח על פירוט העלויות שלך בין אחסון, העברה ותמחור בקשה.

חלק 6 מתוך 6: ניטור וניקוי באגים

1
הגדר פיקוח על עלויות ה- s3 שלך.
- לחשבון AWS שלך יש גישה לנתוני החיוב המספקים את פירוט העלויות המלא. הגדר התראת חיוב כך שהנתונים יתחילו להישלח ל- Amazon CloudWatch. לאחר מכן תוכל להגדיר התראות נוספות באמצעות CloudWatch. נתוני CloudWatch נכנסים כנקודות נתונים אחת לכמה שעות, אך אינם כוללים פירוט מפורט לאורך כל ממדי העניין.
- בכל עת תוכל להוריד פירוט מפורט לפי שעות וסוג שירות מחשבון הבסיס שלך. נתונים אלה מאחרים בדרך כלל 24-48 שעות, כלומר לא תראה מידע במשך 24-48 השעות האחרונות. עבור S3, אתה יכול להוריד בגיליון אלקטרוני או בפורמט CSV את הנתונים עם פירוט לפי שעה, דלי, אזור וסוג פעולה (GET, POST, LIST, PUT, DELETE, HEADOBJECT, או מה הפעולות שלך).
2
כתוב סקריפטים כדי לתת דיווחים יומיים קלים לקריאה על העלויות שלך המפורטים בדרכים שונות.
- ברמה הגבוהה, ייתכן שתרצה לדווח על פירוט העלויות שלך בין אחסון, העברה ותמחור בקשה.
- בכל אחד מאלה, ייתכן שתרצה לפרק את העלויות בהתבסס על מחלקת האחסון (רגיל, RRS, IA וקרחון).
- במסגרת תמחור הבקשה, ייתכן שתרצה לפרק עלויות לפי סוג הפעולה (GET, POST, LIST, PUT, DELETE, HEADOBJECT, או מה הפעולות שלך).
- אתה יכול גם לספק פירוט לפי דלי.
- ככלל, עליכם להחליט על מספר הממדים שתקדחו על ידי קלטת הבנה מהירה כנגד פירוט מספק. פיתרון טוב בדרך כלל הוא לכלול תרגילים לפי מימד אחד בכל פעם (למשל, פירוט אחד לפי דלי, פירוט אחד לפי אחסון לעומת תמחור העברה לעומת תמחור בקשה, פירוט אחד לפי סוג אחסון) בדוח היומי שלך, ולהתמקד עוד יותר אם משהו נראה חריג.
3
בנה מודל עלות צפוי והשתמש בסקריפט שלך כדי לזהות פערים בין העלויות בפועל לבין המודל שלך.
- ללא מודל של מה העלויות צריכות להיות, קשה לבחון את העלויות ולדעת אם הן טועות.
- תהליך בניית מודל עלות הוא תרגיל טוב לניסוח ברור של האדריכלות שלך ולחשיבה פוטנציאלית על שיפורים גם מבלי להסתכל על דפוס העלויות בפועל.
4
ניפוי באגים בעלויות גבוהות.
- אם האשם הוא עלויות האחסון, ראה חלק 3.
- אם האשם הוא בעלויות העברת נתונים עצומות, ראה חלק 4.
- אם האשם הוא תמחור בקשה, ראה חלק 5.

העלויות העיקריות של שירות אתר חי הן עלויות תמחור הבקשה והעברה.

טיפים

עקוב אחר עלויות אמזון S3 שלך. אתה לא יכול לייעל את מה שאתה לא מודד. אחד היתרונות הגדולים ביותר של S3 הוא שאתה לא צריך לחשוב יותר מדי על אחסון קבצים: יש לך למעשה אחסון קבצים ללא הגבלה שאינו קשור למופע מסוים. זה מציע גמישות רבה, אך מצד שני זה גם אומר שאתה עלול לאבד את כמות הנתונים שאתה משתמש וכמה זה עולה לך. עליך לבדוק מעת לעת את עלויות ה- S3 שלך, ולהגדיר התראות חיוב AWS ב- CloudWatch של אמזון כדי להתריע בפניך כאשר עלויות S3 לחודש מסוים עולות על סף.
אל תשתמש ב- Amazon S3 עבור פעולות הדורשות השהיות של פחות משנייה. אתה יכול להשתמש ב- S3 כדי להפעיל מופעים שמפעילים פעולות כאלה, או לצורך רענון תקופתי של הנתונים והתצורות במופעים אלה, אך אל תסמוך על GETs של קבצי S3 לפעולות שבהן אתה צריך להגיב תוך אלפיות השנייה. אם אתה משתמש ב- S3 לצורך רישום, חיץ את הפעילויות באופן מקומי במופע הקצה שלך (או כתוב אותן לזרם כגון Kinesis) ואז רשום אותן מעת לעת ל- S3.
אל תשתמש ב- S3 ליישומים הכוללים קריאה וכתיבה תכופה של נתונים. אמזון S3 מתאים יותר לרישום נתונים לטווח בינוני וארוך טווח מאשר כמקום לאחסון ולעדכן במהירות ולחפש נתונים. שקול להשתמש במאגרי מידע (ובמאגרי נתונים אחרים) לצורך עדכון מהיר של נתונים. דבר חשוב שכדאי לזכור עם S3 הוא שלא ניתן להבטיח עקביות קריאה / כתיבה מיידית: עשויים לחלוף מספר שניות לאחר הכתיבה עד שהקריאה תביא את הקובץ שנכתב לאחרונה. יתר על כן, תראה גם חשבון ענק אם תנסה להשתמש בו בדרך זו, מכיוון שתמחור בקשה נהיה די גבוה אם אתה משתמש S3 בדרך זו.