נבדק לאחרונה: מאי 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן DEA-C01 בודק. קראו מלמעלה למטה, או דלגו לסעיף.
בחר שירות Kinesis להזרמת נתונים.
עיבוד בשליטת צרכן בתת-שנייה → Kinesis Data Streams. אספקה מנוהלת במלואה ל-S3/Redshift/OpenSearch עם המרת פורמט אופציונלית → Kinesis Data Firehose.
למה: KDS שומר רשומות (24 שעות-365 ימים) ותומך בצרכנים מרובים. ל-Firehose אין יכולת שידור חוזר; הוא מחליף שידור חוזר באספקה ללא פעולות תפעוליות.
זרם נתונים חווה שגיאות ProvisionedThroughputExceeded בשיא העומס.
Reshard. כל shard תומך בקלט של 1 MB/s או 1,000 רשומות/שנייה, ופלט של 2 MB/s. השתמש במפתחות חלוקה אחידים; הפעל Enhanced Fan-Out עבור >2 MB/s לצרכן.
למה: מפתחות חלוקה חמים מרכזים תנועה ב-shard אחד. מפתחות אקראיים או מבוססי hash מפזרים את העומס.
עומס העבודה בזרימה נצפה כקופצני ובלתי צפוי; resharding ידני מהווה כאב תפעולי.
Kinesis Data Streams במצב קיבולת לפי דרישה. מתאים את קנה המידה אוטומטית עד 200 MB/s כברירת מחדל; תשלום לפי נפח נתונים.
מספר צרכנים הקוראים מאותו זרם חווים את מגבלת הקריאה של 2 MB/s/shard.
Enhanced Fan-Out. כל צרכן מקבל 2 MB/s/shard ייעודיים באמצעות SubscribeToShard מבוסס push ב-HTTP/2.
מקסם את תפוקת הקלט מצד היישום המפיק.
Kinesis Producer Library (KPL) עם אגרגציה + איסוף. מקבץ רשומות משתמש מרובות לרשומת Kinesis אחת עד 1 MB; מפחית עלויות PUT.
למה: PutRecord של רשומה יחידה מוגבל בקצב ויקר ב-50 אלף אירועים/שנייה. KPL מבצע אגרגציה בצד הלקוח.
הנחת JSON clickstream ל-S3 כקובץ Parquet, מחולק לפי זמן אירוע.
Firehose עם המרת פורמט רשומה (JSON → Parquet) באמצעות Glue Data Catalog table + חלוקה דינמית לפי חותמת זמן אירוע.
למה: Parquet + חלוקה מפחיתים באופן דרמטי את עלויות סריקת Athena. חלוקה דינמית מונעת שלב ETL נפרד.
חלק מהרשומות נכשלות בטרנספורמציה או באספקה של Firehose; יש צורך ללכוד אותן לצורך שידור חוזר.
הגדר גיבוי S3 עם `AllData` או `FailedDataOnly`. רשומות שנכשלו נוחתות בקידומת המוגדרת עם מטא נתונים של שגיאות.
ודא שאין אובדן נתונים ב-MSK אם AZ של ברוקר כושל.
גורם שכפול ≥ 3 על פני 3 AZs ו-`min.insync.replicas=2` עם `acks=all` של המפיק. הפעל Multi-AZ דרך KRaft ללא ZooKeeper או מיקום ברוקרים ב-3 AZs.
הזרם מ-MSK ל-S3, OpenSearch או RDS מבלי לנהל אשכול Kafka Connect.
MSK Connect עם מחבר מנוהל (Confluent S3 Sink, Debezium עבור CDC). מתאים אוטומטית את קנה המידה של ה-workers לפי WCU.
נושא מאחסן את הגרסה האחרונה של רשומה לכל מפתח; ניתן לזרוק גרסאות ישנות.
הגדר את מדיניות הניקוי של הנושא (`cleanup.policy=compact`). Kafka שומר את הערך העדכני ביותר לכל מפתח; רשומות ישנות יותר עם אותו מפתח מתאימות לדחיסה.
העברה שבועית חוזרת של 10 TB מ-NFS מקומי ל-S3 על גבי Direct Connect.
AWS DataSync עם סוכן מקומי + משימה מתוזמנת. מאמת את שלמות הנתונים, תומך בהעברות מצטברות ומקביליות.
למה: DataSync מהיר יותר מ-aws-cli sync ומטפל באופן מובנה בהגבלת רוחב פס, ניסיונות חוזרים ואימות.
משיכת נתונים מ-SaaS APIs (Salesforce, ServiceNow, Zendesk) ל-S3 בלוח זמנים.
AWS AppFlow. מחברים מנוהלים, OAuth מטופל, מתוזמן או מופעל על ידי אירועים, כותב Parquet ל-S3.
שכפול שינויים מתמשכים מ-SQL Server מקומי ל-Aurora MySQL עם זמן השבתה מינימלי.
AWS DMS עם משימת full-load + CDC. השתמש ב-Schema Conversion Tool (SCT) להמרת סכימה/קוד הטרוגניים לפני DMS.
מופע שכפול של DMS כושל - השכפול מופסק.
הפעל Multi-AZ במופע השכפול. מופע המתנה סינכרוני ב-AZ אחר; כשל אוטומטי.
צורך באנליטיקה כמעט בזמן אמת על נתוני Aurora OLTP ללא צינור ETL.
אינטגרציית Aurora zero-ETL ל-Redshift. שכפול רציף של נתוני Aurora ל-Redshift; שאילתות רואות נתונים חדשים תוך שניות.
למה: מבטל צינורות DMS / Glue / CDC מותאמים אישית עבור מקרה השימוש OLTP-to-warehouse.
העברת 100 TB של ארכיון היסטורי משרת מקומי ל-S3; רוחב הפס מוגבל.
AWS Snowball Edge Storage Optimized. התקן פיזי נשלח לאתר; העתקת נתונים; החזרה במשלוח.
JSON המקור מכיל מערכים מקוננים; ניתוח יחסי בהמשך דורש שורות שטוחות.
טרנספורמציית Glue PySpark `Relationalize` (או `explode()` ב-DataFrame) משטחת מערכים מקוננים לשורות/טבלאות נפרדות.
Glue Crawler מסיק טיפוסים דו-משמעיים (`choice<int,string>`) מנתוני CSV מבולגנים.
הפעל טרנספורמציית `ResolveChoice` - המר לטיפוס ספציפי או הטל ל-struct. או תקן במקור על ידי אכיפת סכימה.
משימת Glue ETL רצה לפי שעה על נתוני S3 הולכים וגדלים; יש צורך לעבד רק קבצים חדשים.
הפעל Glue job bookmarks. Glue עוקב אחר קבצים/חלוקות מעובדות ומדלג עליהם בהפעלות חוזרות.
למה: מונע עיבוד מחדש של כל הנתונים. נדרש עבור צינורות ETL מצטברים.
משימת Glue Spark נכשלת עם OutOfMemoryError על הדרייבר במהלך אגרגציות גדולות.
עבור ל-G.2X או G.4X workers (יותר זיכרון דרייבר) או הפעל `--enable-glue-datacatalog` push-down predicates כדי להפחית נתונים מעורבבים.
הפעל Spark Structured Streaming רציף מול מקור Kinesis עם תשתית מנוהלת.
משימת Glue streaming ETL. Spark Structured Streaming מתחת למכסה המנוע; שמירת נקודות בדיקה ל-S3.
אנליסט עסקי צריך לנקות ולבצע טרנספורמציה לנתונים ללא כתיבת קוד.
AWS Glue DataBrew. טרנספורמציות מבוססות מתכונים ויזואליים (250+), פרופילים, lineage. פלט ל-S3, Redshift, RDS.
הפעל משימת Glue ETL רק לאחר ש-Crawler מעדכן בהצלחה את Glue Data Catalog.
Glue Workflow עם טריגרים מותנים. הצלחת Crawler ← הפעל משימת ETL. כשלון ← דלג / התרעה.
Crawler מסיק את כל עמודות ה-CSV כ-`string` - יש צורך בטיפוסי תאריך ומספר.
הוסף מסווג Glue מותאם אישית (תבנית Grok או רמז עמודה) לפני הסריקה. לחלופין, כתוב מראש שורת כותרת עם טיפוסים מפורשים.
מפיקים/צרכנים מרובים ב-Kafka זקוקים לאבולוציית סכימה מבלי לשבור אחד את השני.
AWS Glue Schema Registry עם כללי תאימות (BACKWARD/FORWARD/FULL). מפיקים רושמים סכימה; צרכנים מאחזרים + מאמתים.
בחר בין EMR ל-Glue עבור Spark ETL.
Spark מותאם אישית רץ לאורך זמן עם כוונון עמוק, מספר framework-ים (Hive, Presto, Flink) ← EMR. ETL ללא שרת בתשלום לפי משימה עם אינטגרציה ל-Glue Data Catalog ← Glue. Spark קופצני/בלתי צפוי ← EMR Serverless.
משימות Spark/Hive לסירוגין; רוצה אפס פעולות אשכול וללא מחשוב סרק.
EMR Serverless. מאגרי קיבולת מאותחלים מראש להפעלות עם לטנסי נמוכה; מותאם קנה מידה לכל משימה; תשלום לפי vCPU-hour.
ערבב on-demand core + spot task nodes עבור EMR ממוטב עלויות.
Instance Fleets עם קיבולת יעד לכל סוג. Core fleet ב-on-demand ליציבות HDFS; task fleet ב-Spot עם סוגי מופעים מגוונים.
תקנן על Kubernetes; רוצה שמשימות EMR Spark ישתפו אשכול עם עומסי עבודה אחרים.
EMR on EKS. Spark רץ כ-pods על אשכול EKS קיים; שיתוף תשתית ותפקידי IAM דרך IRSA.
סטרימינג stateful עם אגרגציות מבוססות חלונות וסמנטיקה של "בדיוק פעם אחת".
Kinesis Data Analytics for Apache Flink. סביבת ריצה מנוהלת של Flink; נקודות בדיקה ל-S3; מותאם קנה מידה אוטומטית.
טרנספורמציה קלה לכל רשומה בזרם Kinesis (<1 ms לכל אחת).
Lambda עם Event Source Mapping על KDS. כוונן `BatchSize`, `MaximumBatchingWindowInSeconds`, ו-`ParallelizationFactor`.
למה: Lambda זול יותר מ-KCL/Glue Streaming עבור עבודה קטנה לכל רשומה.
שלב Step Functions נכשל לעיתים עקב throttling חולף; נסה שוב ולאחר מכן התרעה.
הוסף בלוק `Retry` עם `ErrorEquals: ["Lambda.ThrottlingException", "States.TaskFailed"]`, `IntervalSeconds`, `MaxAttempts`, `BackoffRate=2`. בנוסף `Catch` למצב התרעה.
עבד 500,000 קבצי JSON במקביל דרך טרנספורמציית Lambda.
Step Functions distributed Map state עם `MaxConcurrency` ו-ItemReader מ-S3. פיזור על פני אלפי הפעלות Lambda מקבילות.
DAG מורכב עם תלויות בין שירותים (Glue + Redshift COPY + Lambda + דוא"ל) ודרישות lineage.
Amazon MWAA (Managed Workflows for Apache Airflow). אופרטורים מקוריים של Airflow לשירותי AWS; סנכרון DAG מונחה Git.
צורך ב-rollback של שינויים ב-DAG אם פריסה גורמת לכשלים.
אחסן DAGs בדלי S3 עם גרסאות + סנכרון באמצעות S3 versioning. או שמור repo של DAG ב-Git עם סביבה לכל branch + סנכרון S3 דרך CI.
נתונים גולמיים חמים למשך 30 יום, גישה מדי פעם ב-90 הימים הבאים, ארכיון ל-7 שנים.
מחזור חיים של S3: 0-30 ימים Standard, מעבר ב-30 יום ל-Standard-IA, מעבר ב-120 יום ל-Glacier Flexible Retrieval, פקיעה לאחר 7 שנים.
תבניות גישה בלתי צפויות; מדיניות מחזור חיים ידנית היא בחירה שגויה.
S3 Intelligent-Tiering. מעביר אוטומטית אובייקטים בין Frequent / Infrequent / Archive Instant Access / Archive / Deep Archive בהתבסס על תבנית הגישה. עמלת ניטור לכל אובייקט; ללא עמלות אחזור ב-Frequent/IA.
שאילתות Athena על אגם נתונים איטיות; מחיצה מכילה אלפי קבצי JSON בגודל 1-5 KB.
דחוס קבצים קטנים באמצעות משימת Glue/EMR לקבצי Parquet בגודל של כ-256 MB. השתמש ב-Iceberg `OPTIMIZE` או Hudi compaction עבור פורמטים מנוהלים של טבלאות.
למה: התקורה לכל קובץ ב-Athena/Spark שולטת בקבצים זעירים. המצב האופטימלי הוא קבצי Parquet בגודל של כ-128-512 MB.
דלי אחד; צוותים מרובים זקוקים לתבניות גישה שונות בהיקף קידומת.
S3 Access Points - נקודת קצה בעלת שם לכל צוות עם מדיניות משלה הקשורה לקידומת. פשוט יותר ממדיניות דלי ענקית אחת.
צרכנים שונים זקוקים לתצוגות שונות של אותו אובייקט S3 (PII מצונזר, מסוכם).
S3 Object Lambda Access Point. בקשת GET מפעילה Lambda שמבצעת טרנספורמציה לאובייקט תוך כדי תנועה; הצרכן רואה את התצוגה שעברה טרנספורמציה.
צורך בטרנזקציות ACID, אבולוציית סכימה, ו-time-travel על אגם נתונים ב-S3.
טבלאות Apache Iceberg (Glue Catalog + אחסון S3). Commit-ים אטומיים, MERGE/UPDATE/DELETE, בידוד Snapshot, אבולוציית חלוקות.
למה: S3 בסגנון Hive, append-only, אינו תומך בעדכוני שורה. Iceberg/Hudi/Delta פותרים זאת.
כותבים וקוראים מרובים על טבלת אגם נתונים; צורך בעקביות טרנזקציונלית ובבקרת גישה ברמת השורה.
Lake Formation governed tables (מגובים ב-Iceberg) עם LF-Tags להרשאות.
Athena, Redshift Spectrum, EMR ו-Glue ETL כולם זקוקים למאגר מטא נתונים משותף.
AWS Glue Data Catalog. Metastore יחיד תואם Hive הנצרך על ידי כל שירותי האנליטיקה.
אשכול Redshift צריך להגדיל את האחסון באופן בלתי תלוי במחשוב.
צמתי RA3 עם אחסון מנוהל (RMS). אחסון מגובה על ידי S3; המחשוב גדל בנפרד. נדרש עבור AQUA, Concurrency Scaling, Federated Queries.
שאילתת Redshift מסננת לעיתים קרובות לפי `created_at`; סריקות טבלה מלאות איטיות.
הגדר מפתח מיון על `created_at` (או מפתח מיון מורכב הכולל `created_at`). Redshift משתמש במפות אזורים כדי לדלג על בלוקים במהלך הסריקה.
חיבורים תכופים בין `orders` ו-`order_items`; ערבוב שאילתות גורם לאיטיות.
השתמש באותו DISTKEY (`order_id`) בשתי הטבלאות. שורות הממוקמות יחד מונעות ערבוב רשתי במהלך החיבור.
למה: הפצת KEY ממקמת שורות מחוברות על אותו צומת מחשוב.
טעינת 32 קבצי gzip CSV (כ-1 GB כל אחד) לאשכול Redshift בעל 4 צמתים איטית.
COPY במקביל ממניפסט יחיד. כוון למספר קבצים = כפולה של מספר ה-slices (slices = צמתים × vCPU). 4 צמתים ra3.xlplus = 8 slices ← 32 קבצים = 4 לכל slice.
חיבור נתוני Parquet קרים בנפח 5 TB ב-S3 עם טבלאות Redshift fact חמות; לא רוצה לטעון אותם.
Redshift Spectrum. טבלאות חיצוניות ב-Glue Catalog; שאילתות קוראות ישירות מ-S3 עם מחשוב Redshift.
שאילתות צוות הדיווח בזמן שיא מאיטות את עומסי העבודה של ETL; שניהם רצים על אותו אשכול.
הפעל Concurrency Scaling בתור WLM הרלוונטי. Redshift מנתב שקיפות שאילתות עודפות לאשכולות שהוגדלו.
שאילתת Dashboard מצרפת שוב ושוב 3 טבלאות גדולות ומבצעת אגרגציה; הלטנסי גבוהה.
Materialized view עם רענון אוטומטי. Redshift שומר תוצאה מחושבת מראש; שאילתה קוראת מנתונים ממומשים.
עומס עבודה אנליטי לסירוגין; אשכול מוקצה יושב ללא שימוש.
Amazon Redshift Serverless. מקצה ומרחיב אוטומטית RPUs לפי עומס העבודה; תשלום לפי RPU-hour. אפס פעולות תפעוליות.
צורך בחיבור נתוני Redshift עם נתוני Aurora MySQL חיים ללא ETL.
Redshift Federated Queries. CREATE EXTERNAL SCHEMA המצביע על Aurora; שאילתות דוחפות predicates על חיבור ה-RDS החי.
Dashboard מצרף הזמנות + לקוחות + מוצרים בכל רינדור; סכמת כוכב איטית מדי.
Denormalize לטבלת fact רחבה או materialized view. עומסי עבודה של BI מעדיפים חיבורים בזמן קריאה הנפתרים בזמן כתיבה.
S3 מחלק למחיצות לפי `year/month/day/hour`; `MSCK REPAIR TABLE` לוקח מעל 30 דקות.
הפעל Athena partition projection (ללא רשומות מחיצה ב-Glue Catalog). הגדר סוגי מפתח מחיצה + טווחים במאפייני הטבלה.
למה: Athena מחשב את מיקומי המחיצות בזמן שאילתה מכללי ההטלה - ללא MSCK, ללא throttling של Glue API.
המרת תוצאות שאילתת Athena ל-Parquet, מחולקות, בפעולה אחת.
CREATE TABLE AS SELECT (CTAS) עם `format=PARQUET`, `partitioned_by=ARRAY['region']`, `external_location` מוגדר לקידומת S3 היעד.
אותה תבנית שאילתה רצה עם ערכי פרמטרים שונים לאורך היום.
הצהרות מוכנות של Athena: `PREPARE`, `EXECUTE` עם ערכי פרמטרים. מונע ניתוח חוזר ומספק פרמטריזציה נקייה.
קריאות מכשירי IoT; צורך ב-(1) כל הקריאות למכשיר בחלון זמן, (2) הקריאה האחרונה לכל מכשיר.
PK = `device_id`, SK = `timestamp`. GSI עם PK = `device_id`, SK = `timestamp` הפוך (או השתמש ב-Query עם `ScanIndexForward=false LIMIT 1`).
טבלת הפעלות גדלה ללא גבול; הפעלות ישנות ניתנות למחיקה לאחר 7 ימים.
הפעל DynamoDB TTL על תכונה `expires_at` מסוג epoch. DynamoDB מסיר פריטים שפגו תוקפם ללא עלות (תוך כ-48 שעות).
נתוני חיישני IoT: שאילתות חמות על 7 הימים האחרונים, שאילתות מדי פעם על שנתיים.
Amazon Timestream. אחסון בזיכרון לנתונים עדכניים (שאילתות מהירות); שכבות אוטומטיות לאחסון מגנטי עבור היסטוריה.
אחסון תואם Cassandra עבור time-series עם כתיבה גבוהה ושמירה של 90 יום.
Amazon Keyspaces עם TTL על שורות. תואם ל-Cassandra CQL; קיבולת serverless, ללא ניהול אשכולות.
עלות אחסון OpenSearch גדלה; אינדקסים ישנים נשאולים לעיתים רחוקות.
מדיניות ISM של OpenSearch מדורגת נתונים: חם → UltraWarm (מגובה ב-S3) → Cold. שכבת Cold מנותקת אך ניתנת לחיפוש לפי דרישה.
אמת שפלט ה-ETL מכיל ≥1,000 שורות ושיעור NULL בעמודות <2% לפני צריכה בהמשך.
כללי AWS Glue Data Quality (DQDL): `RowCount >= 1000`, `Completeness "col" > 0.98`. Pipeline נעצר בכשל כלל.
framework איכות נתונים מבוסס Spark מותאם אישית ב-EMR; צורך בבדיקות סטטיסטיות ברמת העמודה.
ספריית AWS Deequ ב-Spark. הגדר אילוצים (`isComplete`, `hasMin`, `isContainedIn`); Deequ רץ כמשימת Spark ופולט מדדים.
אנליסטים צריכים לגלות, לבקש גישה ל, ולהבין את ה-lineage של מוצרי נתונים על פני חשבונות.
Amazon DataZone. קטלוג נתונים עם מילון מונחים עסקי, תהליכי עבודה לגישה, lineage; משתרע על Lake Formation, Redshift, RDS.
Lambda פולט מדדי עיבוד לכל רשומה; עלויות CloudWatch PutMetricData גבוהות.
CloudWatch Embedded Metric Format (EMF). רשום JSON בסכימת EMF; CloudWatch מחלץ מדדים מיומנים ללא עלות לכל PutMetricData.
מצא את כל משימות Glue שמשך פעילותן עלה על שעה ב-7 הימים האחרונים.
שאילתת CloudWatch Logs Insights: `fields @timestamp, @message | filter @message like /JobRunDuration/ | parse @message "duration=*" as d | filter d > 3600`.
משימת Glue איטית; צורך לדעת אם היא בתת-משאבים או שיש לה skewed shuffle.
הפעל מדדי משימות Glue + יכולת תצפית. CloudWatch מציג ניצול DPU מקסימלי, ניצול executor, קריאה/כתיבה של shuffle לכל שלב.
גדלי משימות Glue Spark משתנים פי 10 בין הפעלות; הקצאת יתר עבור תשומות קטנות.
הפעל Glue auto scaling (Glue 3.0+). Workers מתווספים/מוסרים במהלך הביצוע בהתבסס על מקביליות השלב.
Athena סורק 5 TB כדי לענות על שאילתות הנוגעות ליום נתונים אחד; העלות גבוהה מדי.
חלק למחיצות לפי תאריך וודא שסעיף WHERE משתמש במפתחות מחיצה. אמת עם `EXPLAIN` המציג partition pruning.
שאילתות Athena על אגם נתונים בפורמט JSON איטיות ויקרות.
המר ל-Parquet (עמודתי) או ORC. קורא רק את העמודות הנדרשות; דחיסה מובנית מפחיתה גם את עלות וגם את זמן הסריקה.
אופטימיזציית עלויות של אשכול EMR ללא סיכון לאובדן נתונים.
צמתי Core ב-On-Demand (מארחים HDFS / shuffle). צמתי Task ב-Spot דרך Instance Fleets עם סוגי מופעים מגוונים.
אשכול Redshift רץ 24/7; תמחור on-demand יקר.
Redshift Reserved Nodes (שנה או 3 שנים, כל/חלקי/ללא תשלום מראש). עד כ-75% הנחה לעומת on-demand עבור עומסי עבודה יציבים.
בחר בין Athena, Redshift, ו-EMR עבור 500 GB ביום / 50 שאילתות.
Ad-hoc, לא תכוף ← Athena (לפי TB נסרק). BI dashboards צפויים ← Redshift (RA3 + Reserved). Spark מותאם אישית כבד ← EMR.
למה: Athena מחייב לפי נתונים נסרקים; Redshift מחייב לפי שעת אשכול; EMR לפי שעת מופע. התאם את החיוב לתבנית הגישה.
משימת Glue מופעלת מספר פעמים במקביל; רוצה להגביל להפעלה אחת בכל פעם.
הגדר `MaxConcurrentRuns=1` למשימת Glue. טריגרים עוקבים ימתינו; מבטל שחיתות מצב מקבילי.
ניסיונות חוזרים של Glue ETL מייצרים שורות פלט כפולות ביעד S3.
אידמפוטנטיות: כתוב לקידומת זמנית לכל הפעלה, ולאחר מכן שינוי שם אטומי באמצעות S3 multipart `CompleteMultipartUpload` או השתמש ב-Iceberg/Hudi MERGE עבור upserts.
הפעלת ETL כושלת כתבה שורות פגומות ל-Aurora MySQL; שחזר לנקודה בזמן לפני מספר דקות.
Aurora Backtrack (תואם MySQL בלבד). מחזיר את האשכול לזמן יעד ללא שחזור מ-snapshot.
Pipeline דרס אובייקטי S3 נכונים עם נתונים מושחתים.
S3 bucket versioning + שחזר גרסה קודמת. שלב עם MFA Delete כדי למנוע פקיעת גרסה מקרית.
אוטומציה של יצירת, שמירת ו-cross-region copy של תמונות מצב של EBS לצורך שחזור מאסון.
Amazon Data Lifecycle Manager (DLM) עם מדיניות לכל תג: לוח זמנים, שמירה, cross-region copy.
צרכני MSK מפגרים אחרי מפיקים; צורך לזהות ולהתריע.
מדד CloudWatch `MaxOffsetLag` לכל קבוצת צרכנים. התרעה כאשר > סף; הגדל את מספר הצרכנים או את מקביליות המחיצות.
צרכן Kinesis מפגר; צורך לזהות.
מדד CloudWatch `GetRecords.IteratorAgeMilliseconds`. התרעה > 60 שניות בדרך כלל מצביעה על תת-הקצאה של צרכנים.
זהה את שאילתות Redshift האיטיות ביותר מהשעה האחרונה לצורך כוונון.
שאילתת `SVL_QLOG` / `STL_QUERY` / `SYS_QUERY_HISTORY` עבור רשומות זמן שחלף העליונות; השתמש ב-`SVL_QUERY_REPORT` לפירוט לפי שלבים.
צוותי מכירות צריכים לראות רק שורות עבור האזורים שהוקצו להם באגם הנתונים המשותף.
אבטחת שורה ב-Lake Formation באמצעות מסנן נתונים: `region IN ('NA', 'EU')` לכל IAM principal. טבלה יחידה; תצוגה מסוננת לכל principal.
טבלת בריאות - אנליסטים אסור שיראו עמודות SSN ואבחון.
הרשאות ברמת העמודה של Lake Formation: GRANT SELECT על טבלה EXCEPT (`ssn`, `diagnosis_code`).
צוותים רבים + טבלאות רבות; הרשאות לכל טבלה אינן ניתנות לתחזוקה.
Lake Formation LF-Tags. תיוג טבלאות/עמודות; הענקת הרשאות מבוססות תג ל-principals. הוספת טבלה חדשה רק דורשת את התג הנכון.
חשבון A מחזיק באגם הנתונים; אנליסטים של חשבון B זקוקים לגישת קריאה לטבלאות ספציפיות.
שיתוף cross-account של Lake Formation באמצעות RAM. חשבון A מעניק הרשאות ל-IAM principal/חשבון של B; חשבון B ניגש דרך Athena/Redshift Spectrum.
אבטחת שורה בתוך Redshift (לא Lake Formation).
מדיניות RLS מקורית של Redshift: `CREATE RLS POLICY` עם predicate המפנה להקשר ההפעלה (`current_user`, `session_role`). צרף מדיניות לטבלה.
דרישת ציות מחייבת מפתח מנוהל לקוח עם מסלול ביקורת להצפנת Redshift.
אשכול Redshift מוצפן עם מפתח KMS מנוהל לקוח. סיבוב מפתחות מופעל; CloudTrail לוכד כל פעולת Decrypt מול ה-CMK.
הצפן קלטי/פלטי משימות Glue ETL באמצעות מפתח מנוהל חברה.
Glue Security Configuration עם CMK עבור S3 + CloudWatch Logs + Job bookmarks. לתפקיד Glue הוענקה הרשאת `kms:Decrypt`/`Encrypt` על המפתח.
גלה וסווג PII (שמות, SSN, מיילים) הנמצא באגם נתונים ב-S3.
Amazon Macie. גילוי נתונים רגישים מונחה ML ב-S3; מפיק ממצאים עם מיקום האובייקט וסוג ה-PII.
בקר כל S3 GetObject / PutObject בדלי אגם הנתונים.
CloudTrail data events עבור הדלי. CloudTrail כברירת מחדל רושם רק אירועי ניהול; יש להפעיל אירועי נתונים במפורש.
למה: אירועי נתונים מחויבים לפי אירוע; הגבל לדלי הרגיש בלבד כדי לשלוט בעלות.
צורך במי/מתי/IP לכל גישת S3; CloudTrail data events יקרים מדי.
S3 server access logging. חינם; יומנים נמסרים לדלי יומנים נפרד; פחות פירוט מ-CloudTrail אך מכסה מבקש + IP + נתיב.
מנע מכל דלי בחשבון להיעשות ציבורי בטעות, גם אם מדיניות דלי אומרת זאת.
S3 Block Public Access ברמת החשבון. עוקף כל מדיניות ברמת הדלי; נאכף כ-"guardrail".
Redshift ב-VPC חייב לקרוא מ-S3 מבלי לעבור דרך האינטרנט הציבורי.
S3 Gateway Endpoint בטבלת הניתוב של subnet ה-Redshift. התעבורה מנותבת דרך תשתית AWS; ללא NAT, ללא IGW.
משימת Glue ETL צריכה לגשת ל-RDS ב-subnet פרטי וגם לקרוא ל-Glue Data Catalog APIs.
חיבור Glue ב-VPC של RDS + Interface VPC Endpoints עבור `glue.amazonaws.com` + S3 Gateway Endpoint.
Glue ETL זקוק לגישת קריאה ל-S3, כתיבה ל-Redshift, קריאה ל-Secrets Manager.
תפקיד ביצוע Glue יחיד עם מדיניות הרשאה מינימלית: `s3:GetObject` על קידומת מקור, `redshift-data:ExecuteStatement`, `secretsmanager:GetSecretValue` על ה-ARN הספציפי של הסוד.
זיהוי תבניות גישת נתונים חריגות - הורדה גדולה על ידי משתמש IAM ללא גישה קודמת לאגם נתונים.
GuardDuty S3 Protection. קווי בסיס התנהגותיים לכל IAM principal; ממצאים על נפחי/תבניות גישה חריגים.
דרישת ציות מחייבת שמירה ב-WORM (write once, read many) על נתונים פיננסיים למשך 7 שנים.
S3 Object Lock עם מצב Compliance + תקופת שמירה של 7 שנים. גם root אינו יכול למחוק; עומד בדרישות SEC 17a-4 / FINRA.
איסוף ראיות ציות רציף לביקורות HIPAA / SOC 2.
AWS Audit Manager עם framework-ים מובנים מראש. אוסף אוטומטית ראיות מ-CloudTrail, Config, Security Hub; מפיק דוחות מוכנים לביקורת.