AWS Lake Formationでのデータレイク登録からデータアクセスまで - NTT Communications Engineers' Blog
AWS Lake Formationでのデータレイク登録からデータアクセスまで この記事は NTTコミュニケーションズ Advent Calendar 2021 の16日目の記事です。 はじめに はじめまして！BS本部SS部の荒井です。データマネジメントに関するプリセールスを担当しています。 今回はアドベントカレンダー企画ということで、AWS Lake Formationに関する記事を投稿をさせていただきます。 データレイクとAWS Lake Formation 近年データ分析の盛り上がりなどから、散逸している様々な形式のデータを一元管理できるレポジトリ、いわゆるデータレイクを導入するケースが増えてきています（参考：データレイクとは）。 例えばシステムごとに保存されていた「会員データ」「購入履歴」「問合せ履歴」などのデータをデータレイクに集約することでシステム横断の顧客分析を手軽に行うこと
複数のAvailability ZoneにプロビジョニングしたELB(ALB) / AutoScaling Groupから特定Availability Zone上のリソースをパージする | DevelopersIO
中山（順）です 先日に東京リージョンで比較的規模の大きな障害が発生いたしました。 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 障害の影響は特定のAZに限られていたことは上記の公式メッセージで説明されているとおりです。 また、障害発生の早い段階で単一のAvailability Zoneで問題が発生していることがService Health Dashboardでアナウンスされていました。 しかし、Design for Failureの原則に基づいてリソースを複数のAvailability Zoneで冗長化してるケースでも何らかの影響を受けたというケースもあったようです。（以下、その一例です） 8月23日のAWSの大規模障害でMultiAZでも突然ALB（ELB）が特定条件で500エラーを返しはじめたという話 これは、
8月23日のAWSの大規模障害でMultiAZでもALB（ELB）が特定条件で500エラーを返すことがあったという話 - Make組ブログ
このブログ記事で 「MultiAZ」にしていたら何事も全て大丈夫という認識を変えられると嬉しいです （当該の時点で障害起こした人はちゃんとMultiAZにしてなかったんでしょ？という人の認識も変えられると嬉しいです）。 MultiAZにしておくことは基本 です。 その上でも、 安心しきらずに監視は必要 という話をしています。 MultiAZ構成にしておきましょう そのうえで監視、検知、トレーサビリティを大切にしましょう MultiAZ要らないという見当外れの解釈はしないでください （一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います）。 前提 2019-08-23、AWSで大規模な障害が起こりました。 障害の一般的な内容は以下のとおりです。 まとめのブログ https://piyolog.hatenadiary.jp/entry/2019/08/23/174801 AW
Amazon EC2のサーバからメール送信をするまでにやるべきこと (スパムメール扱いを回避する！) - 元RX-7乗りの適当な日々
先日のデブサミ2010でも話した(デブサミ2010の資料"クラウドサービスAmazon EC2を活用した「SKIPaaS」構築事例"を公開します＋α)のですが、Amazon EC2のサーバからメールを送信すると、一部分の宛先(メールサーバ)では、迷惑メール(SPAM)扱いされ、突き返されちゃう事があります。 それをどう解決したかという話。 Twitterを見ていて、まだきちんとした情報がまとまっていない気がしたので、経験談をまとめてみます。 課題 Amazon EC2のサーバがスパムメール送信に利用されるケースが増えているようで、Amazon EC2で利用されているIPアドレスのレンジ(ネットワーク)が、スパムメールのブラックリストにまるっと載ってしまっているため、メールサーバによっては、門前払いによる受信拒否となるケースがあります。 参考： Amazon EC2を悪用したセキュリティ攻撃
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
