Author: AWS Japan

こんにちは、ソリューションアーキテクトの篠原英治です。 Amazon AthenaおよびAmazon EMRのGeneral ManagerであるRahul Pathakの来日に伴い、AWSをご利用いただいているスタートアップおよびアドテクのエンジニアの皆さまをAWSジャパンのオフィスにお招きしてAmazon Athenaに関する勉強会を開催しました。   – Amazon Athenaのご紹介 お客様からいただいたフィードバックからAthenaを開発するに至ったという背景や、フィロソフィー、そして特徴などについて、AWSのBigData関連サービスを担当している事業開発マネージャーの一柳による逐次通訳とともに、ご紹介させていただきました。   Amazon QuickSightとの連携や、JDBCコネクタを使った実装、Apache ParquetやApache ORCといったカラムナフォーマット利用の推奨、Apache Spark on EMRで既存ファイルをカラムナフォーマットに変換する方法から、実際にご利用いただいているお客様のユースケースのご紹介にいたるまで、多岐にわたる内容となりました。     – Q&Aセッション Q&A形式で活発なディスカッションが行われました。   非常に実践的で詳細なご質問や大変貴重なフィードバックを数多くいただきました。またRafulからもスキャンデータの圧縮によるコスト効率の改善などのTIPSも共有させていただきました。こちらに関しましては、先日データサイエンス領域をメインに担当させていただいているSAの志村が翻訳した『 Amazon Athena のパフォーマンスチューニング Tips トップ 10 | Amazon Web Services ブログ 』も併せてご覧ください。   Rahulおよび一柳は『 お客様からAthenaに対する期待やフィードバックを直接いただくことができ、今後の改善のアイデア得ることができました。このMeetupを開催できて本当に良かったです。お忙しい中ご参加くださった皆様ありがとうございました！ 』と申しておりました。     — Amazon Athenaに関しまして、フィードバック等ございましたら、お近くのAWSジャパンの人間にお声がけいただければと思いますので、今後ともよろしくお願い致します。 また、日本語でAmazon Athenaの概要を知るには [PDF] AWS Black Belt Online Seminar […]

コンプライアンスやデータセキュリティの要件が厳しいお客様は、AWSクラウド内での保存中や転送中など、常にデータを暗号化する必要があります。この記事では、保存中や転送中もレコードを暗号化しながら、Kinesisを使用してリアルタイムのストリーミングアプリケーションを構築する方法を示します。 Amazon Kinesisの概要 Amazon Kinesisプラットフォームを使用すると、要求に特化したストリーミングデータを分析または処理するカスタムアプリケーションを構築できます。 Amazon Kinesisは、ウェブサイトクリックストリーム、金融取引、ソーシャルメディアフィード、ITログ、トランザクショントラッキングイベントなど、何十万ものソースから1時間につき数テラバイトのデータを連続的にキャプチャして保存できます。 Amazon Kinesis Streamsは、HTTPSを使用してクライアント間でデータを暗号化し、転送されているレコードの盗聴を防止します。ただし、HTTPSで暗号化されたレコードは、データがサービスに入ると解読されます。このデータは24時間保管され（最大168時間まで延長可能）、アプリケーションの処理、再処理、処理遅延の際の巻き取りに対して十分なゆとりが確保されています。 ウォークスルー Amazon Kinesis Producer Library（KPL）、Kinesis Consumer Library（KCL）、AWS KMS、aws-encryption-sdkを使用してサンプルKinesisプロデューサおよびコンシューマアプリケーションへの暗号化と復号を行います。この記事で使用されているKinesisレコードの暗号化と復号に使用される方法とテクニックは、あなたのアーキテクチャに簡単に再現できます。いくつか制約があります： AWSは、暗号化と復号のためのKMS APIリクエストの使用料金を請求します。詳しくは、「AWS KMSの料金」を参照してください。 Amazon Kinesis Analyticsを使用して、このサンプルアプリケーションのクライアントによって暗号化されたレコードのAmazon Kinesis Streamにクエリすることはできません。 アプリケーションでレイテンシの低い処理が必要な場合は、レイテンシに多少の上乗せがあることに注意してください。 次の図は、ソリューションのアーキテクチャを示しています。

“信頼するが、確認する” – ロナルド・レーガン米国大統領、1987 このコメントで、レーガン大統領は、核軍縮条約の哲学について、ロシアの諺を引用しました。DevOpsにも同じ考え方が当てはまります！   Amazon ElastiCache for Redisは、自動化されたフェイルオーバとリカバリを備え、高可用性を提供しています。ElastiCacheクラスタを作成したければ、 Redis Cluster モードを使用し、クラスタ内のシャード数を設定します。各シャードには、1つのプライマリノード（読み取りと書き込み用）と0〜5つのレプリカノード（読み取りとフェールオーバー保護用）があります。1つのクラスタは、レプリカがゼロ（1ノード）のシャードと同じくらい小さくても、5つのシャード（5つのレプリカ（合計90ノード））を持つことができます。   AWSでは障害が頻繁に発生することはありませんが、いずれのマシンでも障害は発生します。レプリカノードに障害が発生すると、障害が検出され、数分でノードが置き換えられます。   Redis Cluster では、プライマリノードに問題が起きた時に、Redis Cluster は障害を検知しレプリカノードを新しいシャードのプライマリとして昇格させます。このプロセスは大体30秒程で実施されます。問題の起きたノードは入れ替えられ、クラスタのレプリカノードとして復帰します。Redis ClusterとElstiCacheを、エンジンとして Redis 3.2.4 と Cluster モードを有効にすることによって使うことができます。   これを信じてください…しかし検証するべきです。   ElastiCacheのテストフェイルオーバのおかげで検証は簡単です。マネジメントコンソールかAWS CLIを使用し、ElasiCache クラスタのいずれかのノード障害をシミュレートする事ができます、そして、どのようなプロセスで貴方のアプリケーションが動くのかも見ることができます。マルチシャード、もしくはシングルシャードの環境でもテストは可能です。さらに古いRedis 2.8の環境でもテストは可能です。 コンソールまたはAWS CLIを使用して、ElastiCacheクラスタ内の任意のノードの障害をシミュレートし、自分のアプリケーションでフェールオーバープロセスがどのように機能するかを確認できます。マルチシャード環境とシングルシャード環境、さらに古いRedis 2.8ブランチ環境でもフェールオーバーをテストできます。コンソールでこれを行うには、クラスタとシャードを選択してノードビューを表示し、次にフェールオーバープライマリを選択します。マネジメントコンソールでテストを行う際には、クラスタとシャードを選択してNode Viewを確認し、次にFailover primaryを選択します。   使用には注意してください。どのようなクラスタでも同じように動きます。なぜならどのクラスタも開発環境、テスト、本番かをAWSが知るすべが無いためです。その本番のクラスタで実行しても良い事が確信していない限りは本番ノードでは障害を発生させないでください。   自動フェイルオーバのテストを試してみてください！   翻訳は桑野が担当しました。原文はこちら。

Anurag GuptaはAmazon Auroraを含む彼がデザインに参加した、いくつかのAWSデータベースサービスに携わっています。 Under the Hoodシリーズでは、Auroraを支える技術や設計について説明します。 Amazon Auroraはオープンソースデータベースのシンプルさとコスト効率とハイエンドなコマーシャルデータベースの可用性と性能を兼ね備えたMySQL互換のデータベースです。この投稿では、Amazon Auroraが一般的な、完了までMySQLでは数時間かかるようなDDL文をほぼ即座に実行出来る仕組みを見ていこうと思います。   Fast DDLとは？なぜ考慮するのか アプリケーションを変更すると、それに付随するデータベースのスキーマを変更する必要があるケースがあります。クエリのワークロードが変わると、インデックスの追加や削除を行う必要があります。データのフォーマットが変更になると、既存のカラムのデータタイプを変更する必要があります。そして、このような変更は頻繁に起こりえます。Ruby on Railsアプリケーションをサポートする一部のDBAは、週に数十回スキーマを変更すると話しています。 多くのMySQLのDBAはご存知のように、このようなスキーマの変更はプロダクションシステムの中断が発生する可能性があります。変更に時間がかかるからです。場合によっては、完了まで数時間から数日かかることもあります。システムのリソースも奪われるため、アプリケーションのスループットも低下します。また、長時間のオペレーションは長時間のクラッシュリカバリが発生する可能性があります。DDL操作の一部は書き込みロックが必要なため、アプリケーションの一部が使用できなくなります。加えて一時的なスペースを多く必要とする可能性があり、小規模のインスタンスではディスクが不足する可能性もあります。 私たちはこのような点を取り除けるように改善を行っており、良く見る一般的なDDL操作(nullableカラムをテーブルの最後に追加)から改善を始めました。   なぜ既存の方法では問題が起こるのか？ MySQLがどの様にnullableカラムをテーブルの最後に追加する実装になっているか見ていきましょう。 MySQLは以下のような処理を行っています: データベースはトランザクションのprepareフェーズでオリジナルテーブルに対して排他ロックを取得します 変更後のスキーマで新しい空のテーブルを作成します 1行ずつコピーを行ない、インデックスをその後作成する。同時に実行されたデータ操作(DML)文は、一時ファイルに記録されます 再度、排他ロックを取得し一時ファイルから新しく作成したテーブルへDML文を適用します。適用すべき操作が多くある場合、この処理に時間を要します オリジナルテーブルをdropし、テーブルをリネームします これらの処理には多くのロックが必要になり、データのコピーやインデックスの作成にオーバヘッドが必要になります。そして、I/Oが多く発生し、一時領域も消費します。   もっと良い方法はないのでしょうか？ これについてはないと思うかもしれません。各行のデータ形式は変更する必要があります。しかし、この変更をテーブル上で実行されている他のDML(および関連するI/O)操作の上にのせることで、多くのことが実行できます。 完全なアプローチは、ブログポストではやや複雑すぎるので、ここでは簡単に説明します。 Auroraでは、DDLをユーザが実行すると データベースがINFORMATION_SCHEMAのシステムテーブルを新しいスキーマで更新します。加えて、各操作に対してタイムスタンプを付与し変更をリードレプリカに伝搬します。古いスキーマ情報は新しいシステムテーブル(Schema Version Table)内に格納されます 同期的に行う操作はこれだけで完了です。 そして、その後のDML文は、影響のうけるデータページがスキーマの変更を待っている状態か監視します。この操作は、各ページのlog sequence number (LSN)タイムスタンプとスキーマ変更のLSNタイムスタンプを比べるだけで簡単に行なえます。必要に応じて、DML文を適用する前に新しいスキーマにページを更新します。この操作は、redo-undoレコードページの更新と同じ更新プロセスで実行されます。そして、I/Oはユーザの実行するクエリと同様に扱います。 DML操作では、ページ分割が発生する可能性があるため、ページの変更に注意する必要があります。変更はAuroraのレプリカノードでも同様に扱う必要があります。そして、リードレプリカではどのデータへの変更も許可されていません。SELECT文のために、MySQLに戻されるメモリ上のバッファ内のイメージ変更します。この方法では、ストレージ内で新旧のスキーマが混在していたとしても常に最新のスキーマを参照出来ます。 もし、皆さんがAuroraがどのようにストレージからの読み込みとログの適用を行っているかご存知の場合、このアプローチが似ていると感じると思います。しかし、このアプローチではredo logのセグメントではなく、変更を記録するためにテーブルを使用します。 パフォーマンス比較は以下のようになっています。Auroraは Schema Version Tableを変更するために一定の時間で処理が完了しているのがおわかりになると思います。しかし、MySQLではテーブルサイズにほぼ比例して線形に処理時間が増加しています。 明らかに私達が改善すべき多くのDDL文があります。しかし、殆どの物は同様のアプローチで対処可能と考えています。 このことは重要です。たとえデータベースが通常の可用性で稼働していても、これらの長い操作ではアプリケーションへ影響が発生します。それらを並列、バックグラウンド、非同期処理に移すことで違いが出てきます。 質問やフィードバックはありますか？aurora-pm@amazon.comへ是非お寄せ下さい。皆さんの考えや提案を私たちは非常に大切にしています。 注: こちらの機能は2017年4月6日現在Lab modeにてご提供しております。 翻訳は星野が担当しました。原文はこちら。

これはAhmed Omranのゲストポストです。 AhmedはAWSのMigration Solutions Architectです。 大規模構成におけるオンプレミスサーバーの移行は、自動化、スケジューリング、少ない帯域幅の消費や移行時間の短縮を調整することなしに行うことはできません。 この記事では、AWS Server Migration Service（AWS SMS）を使用して、オンプレミスのワークロードをAWSに効率的に移行する方法を段階的に説明します。 AWS Server Migration Serviceとは何ですか？ 2016年10月、エンドツーエンドのサーバー移行プロセスを簡素化する目的でAWS SMS を紹介しました。 AWS SMS は現在、仮想アプライアンスを使用したエージェントレスサービスとしてのオンプレミス仮想マシン（VMs）の移行をサポートしています。 AWS SMSには、次の主要な利点があります： ライブサーバーボリュームのAWSへのレプリケーションを順次自動化することにより、カットオーバー時のサーバーダウンタイムを削減します。 費用対効果の高い方法で大規模サーバーの移行を行います。 広く使用されている多くのオペレーティングシステムをサポートします。 使いやすいUIを使用して、サーバー移行の進捗状況を管理および追跡します。 AWS SMSは、VMware 環境からAWSへの大規模マイグレーションを計画している場合に重要な考慮事項となる、ダウンタイム、エージェントレスツール、順次レプリケーション、およびカットオーバー前のアプリケーションテストなどに対する理想的なソリューションです。 AWS SMSは、サーバーの移行に使用する無料のサービスです。 Amazon EBS スナップショットやAmazon S3など、移行プロセス中に使用されたストレージリソースにのみ支払います。 現在、米国東部（米国バージニア州）、米国西部（オレゴン州）、米国東部（オハイオ州）、EU（アイルランド）、アジア太平洋（シドニー）、アジア太平洋（東京）、アジア太平洋（ソウル） 、アジア太平洋地域（ムンバイ）でサービスが利用可能です。 どのように機能するのですか？ AWS SMS を使用してワークロードを移行する手順を説明する前に、移行プロセス自体とAWS SMS がどのように処理するかについて詳しく説明します。 移行プロセスは、次の図に示すように、4つの段階に分かれています。 AWS SMS 移行プロセスの概要 AWS SMS の最終出力はAmazon Machine Image（AMI）です。移行プロセスは、ジョブが終了されるまで（あなたが消去するか、または90日後に自動的に終了するまで）、各レプリケーションの実行ごとにAMIを生成します。 移行段階は、調整された複製頻度で反復されます。各レプリケーションの実行間隔の最短時間は12時間で、最大時間は24時間です。この反復サイクルの有効期間は90日です。その後、レプリケーションジョブは終了します。 移行するVMのグループを選択できます。 […]

今回は、Amazon Redshift シニアプロダクトマネージャーの Maor Kleider からのゲスト投稿です。 -Ana Amazon Redshift は、ペタバイト規模の高速なフルマネージド型データウェアハウスサービスであり、すべてのデータをシンプルにコスト効率よく分析できます。多くのお客様 (Scholastic、King.com、Electronic Arts、TripAdvisor、Yelp など) は、Amazon Redshift に移行して機敏性を実現し、洞察が得られるまでにかかる時間を短縮して、同時にコストも大幅に削減しています。 列指向の圧縮は、Amazon Redshift の重要なテクノロジーです。このテクノロジーにより、ノードの効果的なストレージ容量を増やしてコストを削減し、SQL リクエストの処理に必要な I/O を削減してパフォーマンスを向上させることができます。I/O の効率を高めることは、データウェアハウスに非常に重要です。昨年、I/O の向上に伴ってクエリスループットは倍増しました。この度、Amazon Redshift に新しい圧縮の強化機能が追加されました。以下に、いくつかをご紹介します。 まず、Zstandard 圧縮アルゴリズムのサポートが追加されました。このアルゴリズムは、ビルド 1.0.1172 での高い圧縮率とスピードを適切なバランスに維持します。標準の TPC-DS、3 TB ベンチマークで raw データに適用した場合、Zstandard はディスク容量の 65% を節減します。Zstandard は幅広く適用できます。SMALLINT、INTEGER、BIGINT、DECIMAL、REAL、DOUBLE PRECISION、BOOLEAN、CHAR、VARCHAR、DATE、TIMESTAMP、および TIMESTAMPTZ のいずれのデータ型にも使用できます。 2 番目として、CREATE TABLE AS、CREATE TABLE、ALTER TABLE ADD COLUMN の各コマンドで作成されたテーブルに対する圧縮の自動化が強化されました。Amazon Redshift のビルド 1.0.1161 以降では、これらのコマンドで作成された列のデフォルト圧縮が自動的に選択されます。パフォーマンスを低下させずにディスク容量を節減できるような場合は、自動圧縮が行われます。ディスク容量は、最大 […]

昨年、新しい AWS Application Load Balancer (Elastic Load Balancing の重要な一部) をご紹介し、リクエストの URL のパス要素に基づいて受信 HTTP および HTTPS トラフィックをルーティングするための設定方法について説明しました。このパスベースのルーティングにより、たとえば /api へのリクエストをサーバーのセット (ターゲットグループとも呼ばれます) にルーティングし、/mobile へのリクエストを別のセットにルーティングすることができます。このようにトラフィックをセグメント化することで、リクエストのカテゴリ別に処理環境を制御できます。たとえば、最適な処理環境として、/api リクエストにはコンピューティング最適化インスタンスを指定し、/mobile リクエストにはメモリ最適化インスタンスを指定できます。 ホストベースのルーティングと追加のルール この度、別のルーティングオプションが利用可能になりました。Host ヘッダーに指定したドメイン名に基づいて受信トラフィックをルーティングする Application Load Balancer ルールを作成できるようになりました。api.example.com へのリクエストは 1 つのターゲットグループに送信し、mobile.example.com へのリクエストは別のターゲットグループに送信して、他のすべてのリクエストは (デフォルトルールで) 3 番目のターゲットグループに送信することができます。ホストベースのルーティングとパスベースのルーティングを組み合わせたルールを作成することもできます。これにより、api.example.com/production へのリクエストと api.example.com/sandbox へのリクエストを別々のターゲットグループにルーティングできます。これまでは、一部のお客様はプロキシサーバー群を設定して実行し、ホストベースのルーティングに使用していました。今回のリリースにより、ルーティングは Application Load Balancer によって行われるため、プロキシサーバー群は必要なくなりました。この処理レイヤーの省略により、アーキテクチャが簡素化され、運用のオーバーヘッドが削減されます。Application Load Balancer は、ポートマッピング、ヘルスチェック、サービス検出などのコンテナベースのアプリケーションをサポートする複数の機能を既に提供しています。ホストとパスの両方でルーティングできるようになると、複数のマイクロサービスをそれぞれ異なる Amazon EC2 Container Service コンテナで実行するアプリケーションを構築し、効率的にスケールすることができます。ホストベースのルーティングを使用すると、サービス名とコンテナ名を合致させることで、これまで以上にサービス検出機構を簡素化できます。今回のリリースでは、Application Load Balancer あたりの最大ルール数が […]

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。 企業のファイアウォール内に存在する必要があるSAPランドスケープの設計は比較的簡単ですが、内部からも外部からも接続する必要があるSAPアプリケーションの場合はそうではありません。これらのシナリオでは、必要なコンポーネントとその配置場所について悩むことがよくあります。 この一連のブログ記事では、SAPアプリケーションにおけるAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンを紹介し、例を用いてその使用方法を説明します。セキュリティグループ、ルートテーブルおよびネットワークアクセスコントロールリスト(ACL)の構成と合わせて、よくあるお客様シナリオに基づいた詳細な図で補足しながら、接続経路ごとにいくつかのアーキテクチャ設計パターンを説明します。 アプリケーションを配置するサブネットを正しく見極めるには、アプリケーションへの接続方法を理解することが必要です。SAPアプリケーションに接続する方法をいくつか見てみましょう。 内部専用接続: これらのアプリケーションは内部的にのみ接続します。SAPサポートチームを除き、外部からの接続は許可されていません。この場合、ユーザーまたはアプリケーションは、専用線または仮想プライベートネットワーク(VPN)を介して接続された企業ネットワーク内に存在する必要があります。SAP Enterprise Resource Planning(ERP)、SAP S/4HANA、SAP Business Warehouse(BW)およびSAP BW/4HANAはほとんどの組織で内部専用接続が必要なアプリケーションです。 内部および管理された外部接続: これらのアプリケーションは内部的に接続しますが、既知の外部の関係者に限定した接続も提供します。例えば、内部プロセスからSAP PI(Process Integration)やSAP PO(Process Process Orchestration)を使用することができますし、既知の外部の関係者もホワイトリストに登録されたIPアドレスからソフトウェアのインターフェースに接続することができます。さらに、SAP SuccessFactors、SAP Cloud Platform、SAP AribaなどのSaaS(Software as a Service)ソリューションとの統合は、AWS上で実行されるSAPソリューションに機能を追加する場合にも望まれます。 内部および管理されていない外部接続: SAP hybrisや社外に公開するSAP Enterprise Portalなどのアプリケーションがこのカテゴリーに分類されます。これらのアプリケーションには一般に外部接続が可能ですが、管理、構成および他の内部アプリケーションとの統合のためのコンポーネントなど、内部接続用のコンポーネントがあります。 外部専用接続: ほとんどのコンポーネントが外部から接続可能であっても、アプリケーションにはバックアップ、接続制御、インターフェースなどの基本的な管理タスクのために内部から接続できる必要があるため、稀なシナリオです。このシナリオは滅多にないため、この一連のブログ記事では説明しません。 このブログ記事では、最初のカテゴリーのアプリケーション(内部でのみ接続可能なアプリケーション)で取り得るアーキテクチャパターンについて説明します。今後の記事で、残りの2つのシナリオについて説明します。3つすべてのシナリオにおいて、パッチ、更新プログラムの適用およびその他の関連するシナリオに対処するために、ネットワークアドレス変換(NAT)デバイス(IPv4の場合)、Egress-Onlyインターネットゲートウェイ(IPv6の場合)を使用して、AWSリソースからインターネットに接続すると仮定します。さらに、この接続は、インバウンド(インターネットからAWSクラウドへの)接続要求を制限または排除する方法で管理します。 内部専用接続におけるアーキテクチャ設計パターン このカテゴリーのSAPアプリケーションについて、データベースとアプリケーションサーバーを同じプライベートサブネットまたは分離したプライベートサブネットに配置する2つの設計パターンを見ていきます。 単一のプライベートサブネットにあるデータベースとアプリケーションサーバー この構成には3つのサブネットがあります。 パブリックサブネット: SAProuterとNATゲートウェイまたはNATインスタンスをこのサブネットに配置します。SAPから指定されたパブリックIPアドレスのみがSAProuterに接続できます。詳細は、SAPノート28976 – リモート接続データシートを参照してください。(SAPノートの閲覧にはSAPサポートポータルへの接続が必要です)。 管理用のプライベートサブネット: Microsoft System Center […]

こんにちは、ソリューションアーキテクトの千葉です。 本日はAWS Organizationsを利用したAWSアカウントの作成・管理の自動化方法についてご紹介します。 AWS Organizationsは、組織内のAWSアカウントを統合管理し、セキュリティを高めることができるサービスです。サービスコントロールポリシー (SCP)を利用することで、組織内のAWSアカウントに実行を許可するサービスとアクションを一元的に管理することができます。 AWS Organizationsのもう一つの特徴は、APIを通じて組織配下に新しいAWSアカウントを作成することができることです。これまでは、AWSアカウントを新たに作るにあたって、AWSアカウント作成、連絡先情報入力、お支払情報入力、(必要に応じて)一括請求設定といった手順をマニュアルで実施する必要がありましたが、AWS Organizationsを利用すればこれらの操作はCreateAccountというたった一つのAPIに置換えられます。 AWS Organizationsで作成されたメンバーアカウントには、マスターアカウントのユーザーからアクセス可能なIAMロールが自動作成されます。AWS Security Token Service (STS)を利用してこのIAMロールにアクセスする一時的なセキュリティ認証情報を取得し、AWS Command Line Interface (CLI)やAWS SDKsを使って作成したメンバーアカウントに対して共通設定を施したり、定期的な環境チェックを実行したりすることができます。 それでは、アカウント作成およびSTSを利用したアカウント環境設定の手順を説明していきます。   メンバーアカウントの作成 まずは組織配下にメンバーアカウントを作成します。操作を実行するIAMユーザーまたはIAMロールには、以下のようにOrganizationsを操作する権限を与えておきます。 { “Version”: “2012-10-17”, “Statement”: [ { “Effect”: “Allow”, “Action”: [ “organizations:*” ], “Resource”: [ “*” ] } ] } CreateAccountのパラメーターには、アカウント名およびEmailアドレスを指定する必要があります。IamUserAccessToBillingパラメーターはメンバーアカウントのIAMユーザーにBilling情報へのアクセスを許可するかどうかの設定で、デフォルトでALLOWになっています。RoleNameパラメーターはメンバーアカウントに作成されるIAMロールの名前で、何も指定しなければOrganizationAccountAccessRoleという名前が割り当てられます。 import boto3 orgs = boto3.client(‘organizations’,region_name=’us-east-1′) createAccountRequest = orgs.create_account( “AccountName”: “string”, “Email”: […]

AWSリソースを安全に保護するためのアプローチとして、予防のための仕組み、検知のため仕組みといったそれぞれのレイヤーでのアプローチを検討頂くことを推奨しています。たとえば、Amazon EC2インスタンスにホストベースのコントロールを組み込むことで、アクセスを制限し、システムの動作やアクセスパターンに伴う適切なレベルの可視性を準備できます。これらのコントロールには、ホスト上のネットワークトラフィック、ログファイル、およびファイルアクセスを監視・分析するホストベースの侵入検知システム（HIDS）を含むことが一般的です。 HIDSは、通常、警告、自動修復ソリューションと統合され、攻撃、許可されていない活動、疑わしい活動、環境内の一般的なエラーを検出し対処します。 このブログ記事では、Amazon CloudWatch Logsを使用してオープンソースセキュリティ（OSSEC）HIDSからのアラートを収集、集約する方法を示します。 また、CloudWatch Logs サブスクリプションを組み合わせることで、Amazon Elasticsearch Service（Amazon ES）に分析データと可視化のアラートを配信し、一般的なオープンソースであるKibanaを使用し可視化まで行います。また皆さんが、すぐに試せるようにCloudFormationテンプレートを用意しましたので、ほとんどのデプロイメント作業を自動化させています。このソリューションを使用して、EC2 全体の可視性と洞察を向上させ、セキュリティ修復活動を促進することができます。たとえば、特定ホストがEC2インスタンスのスキャンを検知したらOSSECアラートをトリガーし、VPCネットワークACL（Access Control List）またはAWS WAFルールを実装して、送信元IPアドレスまたはCIDRをブロックすることができます。 ソリューションの概要 次の図は、この記事のソリューションの概要を示しています。 ソリューションの仕組みは次のとおりです。 1. ターゲットEC2インスタンスでは、OSSEC HIDSは、CloudWatch Logs エージェントがキャプチャするログに基づきアラートを生成します。 HIDSは、ログ分析、整合性チェック、Windowsレジストリ監視、ルートキット検出、リアルタイムアラート、およびアクティブな応答を実行します。詳細については、「OSSEC入門」を参照してください。 2. CloudWatch Logs グループはにアラートがイベントとして送信されます。 3. AWS Lambdaを介してイベントをAmazon ESに転送するために、CloudWatch Logs サブスクリプションがターゲットロググループに適用されます。 4. Amazon ESにはログに記録されたアラートデータがロードされます。 5. Kibanaはアラートをほぼリアルタイムで視覚化します。 Amazon ESはすべてのAmazon ESドメインにKibanaを標準でインストールした形で提供されます。 デプロイ時の考慮事項 この記事では、主なOSSEC HIDSのデプロイは、Linuxベースのインストールで構成されています。インストールでは、アラートが各システム内でローカルに生成されます。このソリューションは、デプロイの対象リージョンはAmazon ESとLambdaに依存します。 AWSサービスの可用性に関する最新情報は、Regionテーブルで確認できます。また、EC2インスタンスが必要なコンポーネントを適切にプロビジョニングするために、インターネットアクセスとDNS解決を持つAmazon VPC（Virtual Private Cloud）サブネットを識別する必要があります。 デプロイのプロセスを簡素化するために、テスト環境向けにAWS CloudFormationテンプレートを作成しました。このテンプレートを使用して、テスト環境スタックを既存のAmazon VPCサブネットに自動的にプロビジョニングできます。 CloudFormationを使用してこのソリューションのコアコンポーネントをプロビジョニングし、警告分析用にKibanaを設定します。このソリューションのソースコードはGitHubで入手できます。 Cloud […]