Amazon Web Services ブログ

Category: *Post Types

AWS Backup を使用して AWS Organizations で大規模なバックアップを管理する

お客様は、AWS Backup と AWS Organizations を使用して、大規模なバックアップを管理する標準化された方法を使用できるようにしたいと考えています。AWS Backup は、AWS Storage Gateway を使用してクラウド内およびオンプレミスの AWS サービス全体でデータをバックアップするための集中管理サービスを提供します。AWS Backup は、次のようなさまざまな AWS リソースのバックアップ、復元、およびポリシーベースを保持する単一のダッシュボードとして機能します。 Amazon EBS ボリューム Amazon EC2 インスタンス Amazon RDS データベース Amazon Aurora クラスター Amazon DynamoDB テーブル Amazon EFS ファイルシステム AWS Storage Gateway ボリューム 数千には及ばないまでも数百の AWS アカウントで AWS ワークロードをスケールアップする顧客がいるため、顧客はバックアップを一元管理および監視における必要性を表明しています。AWS Backup は AWS Organizations と提携して、お客様が組織のマスターアカウントから直接 AWS アカウント全体のバックアップを集中管理および監視できる、新しいクロスアカウント管理機能を立ち上げました。以前は何千ものアカウント間でバックアップ構成を手動で複製する必要があった管理者が、単一のマスターアカウントから単一のプロセスを通じてバックアップを管理および監視できるようになりました。 お客様は、組織全体のバックアッププランをデプロイして、AWS Organizations で選択したすべてのアカウント全体にわたりコンプライアンスを確保できます。これにより、お客様はバックアップポリシーの実装方法を標準化し、エラーのリスクを最小限に抑え、手動オーバーヘッドを削減できます。AWS Organizations […]

Read More

AWS Transfer Family と AWS Storage Gateway を使用したデータアクセスの集中管理

厳密さを増し、かつ絶えず変化し続ける、コンプライアンスを要する規制は、金融機関にさまざまな課題をもたらしてきました。法令順守は、しばしば具体的な業務要件を満たすことと解釈されます。金融機関では、そうした業務要件の 1 つとして、情報を正確かつタイムリーに外部組織に提供することが必須とされています。報告以外では、報告後のデータ保持に関するガイドラインの順守も必要です。データへの一元的なアクセスを維持したまま、長期間、コスト効率よくデータを保持し続けることは、コンプライアンス要件に直面している組織に共通のニーズです。コンプライアンス要件に備え、すばやくこれに対応できる機関は、金融サービス市場において競争上きわめて有利な立場にあります。 金融機関で報告書の作成が必須とされ、その報告書を組織外の受取人に安全に共有しなければならないシナリオを、いくつか見ていきましょう。 信用調査機関の報告: 信用調査機関は、銀行、信用組合、消費者向けクレジットカード会社などの貸主から、Metro2 というフォーマットで情報を受け取ります。これらの報告書には、負債を期日までに支払っているか、支払いに漏れがないか、破産申請が行われていないか、口座に共同所有者がいるかなど、借主に関する情報が記載されています。これらの各情報が、各個人の信用スコアに影響します。借主は、自分の信用報告書の情報が間違っていることを発見したら、信用調査機関または間違った情報を提供した貸主に対して、異議を申し立てることができます。金融機関は、このデータを 7 年間保持することを義務付けられています。 米国財務省外国資産管理局 (OFAC) への報告: OFAC の制裁プログラムに従うために、企業や組織は特定の取引を OFAC に報告する必要があります。そして、特定の取引を報告するだけでなく、要請があれば調査のためにいつでも提出できるよう、取引日から少なくとも 5 年間はこれらの取引の記録を保持しておかねばなりません。 規制報告: 投資家の保護、効率的な資本市場の促進、金融システムや経済情勢に「システミックリスク」をもたらす問題への対処を目的に、数多くの規制が設けられています。市場参加者は、これらに従い、規制当局にその報告を行う必要があります。組織はまた、売買および取引に関するデータを 5 年以上保持することも義務付けられています。 このブログ記事では、オンプレミス環境でアプリケーションが作成した財務報告書を、ファイル向け AWS Storage Gateway (File Gateway) を使って Amazon S3 に保存する方法について解説します。また、これらの報告書を AWS Transfer Family を使って外部組織に安全に共有する方法についても解説します。File Gateway と AWS Transfer Family を併用すれば、お使いの既存のファイル転送ワークフローを維持したまま、オンプレミスのインフラストラクチャを削減することが可能です。さらに、既存のファイル転送サーバーを AWS Transfer Family に移行すれば、第三者アクセス用のオンプレミス DMZ を使用せずに済みます。 このブログ記事で紹介するソリューションでは、財務報告書の作成および共有を目的とした、特定のユースケースに焦点を当てています。このソリューションの応用範囲は、SFTP、FTP または FTPS などの転送プロトコル、および NFS もしくは SMB […]

Read More

AWSも参加した調査研究として(社)行政情報システム研から「パブリッククラウド活用」の報告書が発表されました

──── シス研の調査研究報告書 AWSも参加した調査研究の成果として、行政情報システム研究所(以下、愛称の「シス研」)より、『行政機関におけるパブリック・クラウドの活用に関する調査研究 報告書』が公開されました(以下、『報告書』。2020年6月16日より掲載)。この報告書には、いくつもの有益な提言が含まれています。 今回のブログでは、AWSジャパン・パブリックセクターより『報告書』の概要と、読み取られるべきインパクトについて解説します。 画期的な『行政機関におけるパブリック・クラウドの活用に関する調査研究 報告書』 行政情報システム研究所(AIS=institute of Administrative Information Systems)は、行政機関と企業、社会一般との接点に位置する一般社団法人として、行政の情報化・電子政府の実現及びこれに伴う社会の発展に貢献するため、各種事業を展開する一般社団法人です。 今回の『報告書』の冒頭から、調査研究の狙いに関しまして以下、抜粋します(強調は、ブログ筆者)。 「>本調査研究は、行政機関におけるパブリック・クラウドの活用及び関連する調達・契約手法に関して、諸外国政府での先行事例を調査・分析するとともに、我が国政府及び当研究所会員企業の協力を得て、課題及び解決策の検討を行うことで、現場の実務で役立つハウツーやノウハウ及び中長期的に講ずべき施策を抽出・提示することを目的として行うものである。」 「なお、本調査研究は、[・・中略・・]内閣官房 IT 総合戦略室、総務省行政管理局、及び会員企業からは研究会への参画を、自治体、各国政府、専門家各位には、インタビューや資料提供の協力をいただいた。この場を借りて深く感謝申し上げたい。」 先行する多くの「調査研究」「レポート」に比べて、今回の調査研究は2つの点において画期的であると言えます。まず、1)先行する多くの調査研究は、単に「クラウド」に関するものであるのに対し、今回のシス研の報告書は「パブリック・クラウド」に調査スコープを明確に限定していること、また、2)パブリック・クラウドの活用シーンだけではなく、その前段の「調達・契約手法」にまで整理を果敢に試みたこと──という2点において、この調査報告書を高く評価したいと思います。今回の調査研究に参加したシス研皆様や内閣官房・総務省からの参加者をはじめ関係者皆様と議論ができたことは、AWSジャパンとしても多くの学びと発見がありました。 以下、本編・資料編を併せると130頁を超える大部の資料でありますため、今回の報告書のハイライトを幾つかご紹介させていただきます。 【結論】パブリッククラウドは、政府・行政機関にとって既に実用的な選択肢──と位置づけ 2018年に内閣官房IT総合戦略室から「政府情報システムにおけるクラウドサービスの利用に係る基本方針」(2018年6月) が発出され、「政府情報システムのシステム方式について、コスト削減や柔軟なリソース の増減等の観点から、クラウドサービスの採用をデフォルト(第一候補)と」するべく方針が示されたあとも各府省の現場では、”果たして行政機関・政府情報システムにとってクラウドは安全なのか、最適なのか”、という議論がなされてきました。 今回の『報告書』は、こうした論争に終止符を打つものです。 行政機関にとって、【結論】「パブリッククラウドは、既に実用的な選択肢となっている」旨、報告書のサマリーである「概要」においても明記され、本編の「まとめ」(p.50)のセクションにおいても「本調査研究を通じて、パブリック・クラウドは既に行政機関において実用的な選択肢たり得ることが明らかになった」との記載で、報告は結ばれています。 内容紹介①:「パブリック・クラウド特有のリスクは確認できない」と明言 また、今回の『報告書』では、「クラウド導入に対する心理的抵抗」「クラウド移行に伴うリスクへの懸念・不安・負担感」が各調達現場には今現在においても蔓延していると指摘しながらも、それらは新しい技術体系一般に対して言えるものであり、今回の調査の結果として「パブリック・クラウド特有のリスクは確認できない」と明言しています(『報告書』本編 p.32 以降も同様に、断りが無い限り、ページ番号のみの引用は”本編”を指す。) これまで、さまざまな「リスク」が折に触れ語られてきましたが、クラウドはそれらを低減しこそすれ、特有のリスクを伴うものでは無い旨を明記いただいたことは、多くの行政機関にとって、今回の『報告書』がクラウド利用に向けた大きな後押しとなるものと考えます。 内容紹介②:現行の会計法規の枠内で、クラウドの特有の従量課金などのメリットは享受可能と整理 これまで、パブリッククラウドのメリットの中核であるはずの「従量課金」に対し、しばしば「現行の会計法規」との整合性を不安視する意見が出されてきました。 今回の『報告書』では一段踏み込んだ整理が行われ、諸外国政府機関と同様、「複数年の運用を通じて見積の精度を高めていく」、あるいは初年度に関しても 見積もり時点との発生差額を「補正するための手段(年度途中での契約変更や上限価格付従量契約等)を検討する」、「 技術的対話の実施」、「調達仕様書の記載を[クラウドネイティブに]適正化し、[予算の意図せぬ大幅超過や想定外のサービスの大量追加など]トラブルの原因となるリスクを低減させる」────など、実用的な共存策および対応策が紹介されています。これらは、現行の法令改正など大幅な制度改正を何ら必要とするものでは無いため、すぐにでも試行を開始することが可能です。(「」書きの抜粋は、全て p.33から) 内容紹介③:クラウドの”使い始め”に天王山。政府職員へのトレーニングなど、利用開始の「入口」を簡素化することが有効 諸外国政府機関からのヒアリングからも語られているとおり、柔軟性に富むパブリック・クラウドでは「まずは使い始める」アプローチによりメリットを即座に体感することが可能です。 これまで、日本の多くの行政機関・公的機関においては、導入に先立って非常に多くの工数を費やした「事前の検討」が行われ、時間的かつ人的な行政リソースが浪費されてきた反省があります。 今回の『報告書』では、米国・英国・カナダの政府機関へのヒアリングをベースとし、クラウド利用を加速するためには「[政府]職員に多様な人材育成メニューを提供」すること、あるいは「コンソールを触り、クラウドを体感する研修もベンダーの協力を得て提供」するなどの、工夫を徹底していることなどが紹介されています(「概要」)。「トレーニングは政府機関が自ら行う場合に加えて、CSP[=クラウド・サービス・プロバイダー]が提供している研修コースを活用するという方法を採る場合もある」とする今回の『報告書』の提言を踏まえて(p.24)、AWSでは将来的には人事院・総務省・シス研・内閣官房IT室などの横断的な取り組みにより、日本の政府職員皆様にも海外政府と同様のトレーニング受講をいただけることが望ましいと考えています。(カナダ政府における、職員のクラウドスキル強化の取り組みに関しては、こちら。『報告書』本編のp.49でも紹介いただいています) 内容紹介④:「包括契約」のメリットに言及し、「調達・契約スキーム」の類型として記載 今回の調査研究『報告書』では、個別の調達に際しての契約を束ねた「包括契約」に関し、次のように定義しています。包括契約とは、「調達手続きの一部または全部の一元化を図ることにより、各機関が個別に調達することで重複して発生していたコストや手続きの負荷を軽減するとともに、政府全体として多様かつ革新的なIT製品・サービスを活用することにより、政府の提供するサービスをより効率的かつ質の高いものとすることを目的とする仕組み」──である、と。 また、そのメリットに関しても、「包括契約を導入することにより、多様なサプライヤー及びサービスへのアクセス、サービスの効率的な調達によるコストと調達サイクルの短縮化、機関間での契約条件の標準化、革新的かつ最新の技術・製品・サービス・ソリューションの活用、そして政府、サプライヤー双方のサービス品質の向上といった便益も得られる」旨、明記されています。( p.8) 従来の政府文書・行政文書では未済であった整理に関して定義の明確化を行い、併せて「包括契約」により獲得が目指されるべきメリットに関しても言及がある点、『報告書』のひとつの成果であると位置づけられます。 加えて、米国・英国・オーストラリア・ニュージーランドの海外文献調査をもとに、各国の政府機関では「包括契約を前提に、物品・サービスの簡易な発注が可能になっている」(「概要」)と、包括契約締結のメリットを追記しています。 日本政府においても、こうした「調達手続き」を「一元化」する構想は近年、検討が加速しています。例えば、昨年2019年12月に閣議決定された「デジタル・ガバメント実行計画」では(p.27)、以下のように「一元的なプロジェクト管理」の重要性が記載されています。  これまでの政府の情報システム投資は、各府省・業務ごとに情報システム化の要否を検討し、各府省における当該業務の担当部局が予算要求・執行を含め運用の主体として責任を持つことが前提となっており、政府全体でのIT ガバナンスについても、個々の情報システム単位での妥当性検証が中心であった。 企画、予算要求、執行、チェック、見直しというPDCA サイクルそのものが、基本的には、縦割りでの情報システムを前提に動いていたと評価することができる。 その結果、重複的な政府情報システムの整備・運用やオーバースペックでのシステム設計、予算・調達が政府情報システム単位に細分化されているため、事業者との交渉時に十分なスケールメリットを発揮できていないといった問題が生じている。こうした問題を解決し、政府情報システムの一層の改革を進め、データの標準化、政府情報システム間の互換性、円滑な情報連携、高度な情報セキュリティ対策等について、政府として統一性を確保しつつ効率的に実現していくことが必要となる。 そのため、グランドデザインに基づく横断的かつ業務改革(BPR)を意識したサービス視点での政府情報システムの整備・運用を実現する観点から、政府情報システムの統一的管理のための取組を抜本的に強化する。 具体的には、全ての情報システムを対象として、予算要求前から執行の段階まで年間を通じたプロジェクト管理(以下「一元的なプロジェクト管理」という。)を、政府CIO の下で行う。特に、①予算要求前(プロジェクトの計画段階)、②予算要求時(プロジェクトの具体化段階)、③予算執行前(詳細仕様の検討段階)の3段階について、一元的なプロジェクト管理を実施する 日本の会計法令は、IT製品やクラウドなど新しい商材が普及してきた過去数十年間においても、大きな変更が加えられないまま現在に至っています。今回の調査研究では中央省庁の各機関を横断する「包括」の類型だけではなく、中央省庁+自治体+独法など各種公的機関をも包含する「包括契約」の類型にも触れられています(p.8)。 AWSでは今回の研究成果を踏まえ、日本においても必ずしも会計法令の改正に踏み込まずとも、包括契約のもたらすメリットを追求することが可能であるものと整理しており、今後とも関係各所への提言を行っていきたいと考えています。 ❖参考:「アマゾン ウェブ サービスとオーストラリア連邦政府、 AWSクラウドの組織横断的な調達を目的とした、 政府包括契約を締結」 内容紹介⑤:行政機関と言えど、CSPに個別対応を期待しないことが原則である旨明記 政府機関向けの特別な契約条項の有無を、多くの政府機関から問い合わせいただいています。社訓として「Customer Obsession」を掲げるAWSにとっては全ての顧客が特別です。よって、民間企業であるか、政府機関であるかを問わず、100万を超える数の団体・顧客に適用されている「AWSの利用規約(カスタマーアグリーメント)」は、年々その記載内容が拡充され続けています。例えば、数年前に比べても、SLAに列記されるサービス数は増加し続けており、ユーザーが享受するベースラインでのサービスの充実度が向上しているものと言えます。 […]

Read More

【開催報告】「コンテナ × スポットインスタンス」 活用セミナー

スポットインスタンススペシャリスト ソリューションアーキテクトの滝口です。2020年6月10日にオンラインで開催された「コンテナ × スポットインスタンス」 活用セミナーでは、200名を超えるご参加人数という大盛況のもと、AWSのソリューションアーキテクトによる技術解説と、各種コンテナ技術を最大限に活用してスポットインスタンスをご利用いただいている3社のお客様から、実際の事例についてお話いただきました。 本記事では、お客様のご登壇資料を含む当日資料のご紹介、また参加者の皆様からいただいた当日のQ&Aの一部をご紹介します。 当日アジェンダと資料 12:00~13:00 Amazon EC2 Auto Scaling によるスポットインスタンス活用講座 講師:滝口 開資(アマゾン ウェブ サービス ジャパン株式会社 ソリューション アーキテクト) 13:00~14:00 具体的実装に学ぶ、Amazon ECS × EC2 スポットインスタンス、Amazon EKS × EC2 スポットインスタンスによる低コスト & 高可用アーキテクチャ 講師:Hara Tori(アマゾン ウェブ サービス ジャパン株式会社 シニアデベロッパー アドボケイト) 14:00~14:30 AWS Batchによる大規模バッチ処理でのスポットインスタンス活用 講師:宮本 大輔(アマゾン ウェブ サービス ジャパン株式会社 ソリューション アーキテクト) Containers + EC2 Spot: AWS Batch による大規模バッチ処理でのスポットインスタンス活用 from Daisuke Miyamoto   14:30~15:00 ECS×スポットインスタンス活用の秘訣 講師:田中 […]

Read More

認知科学と学習 3: エラボレーションを使って概念の理解を強化する

このブログは、認知科学の原則を使って AWS クラウドの学習効果を高める方法に関するシリーズ記事の第 3 回(最終回)です。 このシリーズの前回と前々回では、プレゼンテーションや講義からの情報を受動的にインプットすることばかりに依存しないということが、いかに重要であるかについてを取り上げました。長期的な学習効果を強化していくためにはインプットばかりでなく、その情報を能動的に 記憶から引き出す(または思い出す) よう、セルフテストに挑戦することが大切です。またこの考え方をふまえ、 時間間隔を空けた反復学習 を実践することで、学習をより効率的かつ効果的にする方法についてもご紹介しました。 どちらの戦略でも強調されているのは、学習プロセスにおいては記憶が重要な役割を果たすということです。ある分野についてのプロフェッショナルになるためには、その分野に関する主要な概念や事実といった強固な基礎を身につけることから始める必要があります。たとえば機械学習 (Machine Learnning: ML) について言えば、そもそも特徴量エンジニアリングとは何かを知らなければ、ML モデルで特徴量エンジニアリングを実践することは不可能です。 しかしこれまでに説明してきたことを鑑みると、キーとなる情報を記憶するためにいたずらに反復学習を行うことが正しいとは限りません。情報に対する理解を深めるのに役立つテクニックがいくつかあります。そのうちの 1 つはエラボレーションと呼ばれるものです。 エラボレーションとは エラボレーションとは、学習中の新しい情報を既存の知識と関連付けていくことで、新たにインプットしている情報に詳細を付け加えていくプロセスのことです。エラボレーションのプロセスでは What (何を) 学習しているかよりも、学習中のトピックの背後にある How (どのように) や Why (なぜ) により重きを置きます。ここでは簡単な例を使って、この概念をより具体的につかんでいきましょう。 エラボレーションの実践 機械学習を例にとった場合、おそらく最初に直面するハードルの 1 つは、この分野特有の用語や概念についての語彙を理解することでしょう。そのためまず Demystifying AI/ML/DL や What is Machine Learning? といったトレーニングを受講し、そこに出てくる用語や概念について時間差学習によって小刻みにセルフテストを行います。 機械学習のタイプの違いを理解しているかを確認するセルフテストの問題の 1 つとして、たとえば以下のような問題があったとします(正解は1)。 次のうち、教師あり学習が最も適しているのはどれか答えなさい 画像内の鳥を特定する 購買傾向に基づいてある集団をより小さな集団にグループ化する データセット内の特徴量の数を減らす クレジットカード取引データ内の異常を特定し、不正としてラベル付けする この問題やその他の同様の問題に正解することはさほど難しくありません。つつまり、回答にあたって教師あり学習ついて深い理解が必要な問題とは言えません。フォローアップの問題に挑戦することでエラボレーション、つまりこのトピックに関する詳細を付け加えていきます。こうすることで、より深い理解が得られます。 以下に示すのは、この状況またはその他の同様の状況でフォローアップエラボレーションとして活用できる問題の例です。 「画像内の鳥の特定」が、どのように教師あり学習の良い例であるか説明しなさい 他の選択肢が、教師あり学習に適していないのはなぜですか 正解の選択肢に加えて、教師あり学習の適切なユースケースを他に挙げなさい 正解の選択肢が、教師なし学習の例でないのはなぜですか   エラボレーションが脳に与えるインパクト エラボレーションの問題が学習に大きな効果をもたらすメカニズムは、脳が情報を最も効果的に保存および取り出す仕組みと関連しています。長期的な観点では、脳内にある他の情報と密接に接続された情報(大きく強固に張りめぐらされたクモの巣状のニューロンをイメージしてください)は、そうでない情報、つまり他の情報との関連付けが乏しく接続の弱い状態で保存された場合と比べて、はるかに簡単に記憶から取り出せるようになります。エラボレーションの問題に取り組み、学習中のトピックに詳細を付け加える訓練を実践すると、先に述べたニューロン同士の密接な結合の形成につながります。 では、この エラボレーション の原則を AWS クラウドの学習に活用するにはどうしたらよいでしょうか。以下にいくつかのアイデアを示します。 フォローアップ問題に挑戦する。反復学習 (小テストの問題に解答する、メモカードでセルフテストをする、難しい ハンズオンラボ […]

Read More
Lambda Thumb

新機能 – Lambda関数の共有ファイルシステム – Amazon Elastic File System for AWS Lambda

本投稿は AWS の Chief Evangelist (EMEA)であるDanilo Pocciaによる寄稿です。 AWS Lambda関数がAmazon Elastic File System(EFS)をマウントできるようになったことを非常に嬉しく思います。EFSは、高可用性と耐久性のために複数のアベイラビリティーゾーン(AZ)にまたがってデータを格納するスケーラブルでエラスティックなNFSファイルシステムです。このように、使い慣れたファイルシステムインターフェイスを使用して、関数単体、および複数のLambda関数のすべての同時実行環境にわたってデータを保存および共有できます。 EFSは、強力な整合性やファイルロックなどの完全なファイルシステムアクセスセマンティクスをサポートしています。 Lambda関数を使用してEFSファイルシステムを接続するには、EFSアクセスポイントを使用します。これは、ファイルシステムへのアクセス時に使用するオペレーティングシステムのユーザーとグループを含むEFSファイルシステムへのアプリケーション固有のエントリポイント、ファイルシステムのアクセス許可、およびファイルシステム内の特定のパスへのアクセスを制限できます。これにより、ファイルシステム構成をアプリケーションコードから切り離しておくことができます。 同一のアクセスポイント、または異なるアクセスポイントを使用して、複数の関数から同じEFSファイルシステムにアクセスできます。たとえば、異なるEFSアクセスポイントを使用して、各Lambda関数はファイルシステムの異なるパスにアクセスしたり、異なるファイルシステムのアクセス許可を使用したりできます。 同じEFSをAmazon Elastic Compute Cloud(EC2)インスタンス、Amazon ECSとAWS Fargateを使用するコンテナ化されたアプリケーションや、オンプレミスサーバーと共有できます。このアプローチに従って、異なるコンピューティングアーキテクチャ(関数、コンテナ、仮想サーバー)を使用して同じファイルを処理できます。たとえば、イベントに反応するLambda関数は、コンテナで実行されているアプリケーションによって読み取られる構成ファイルを更新できます。または、Lambda関数を使用して、EC2で実行されているWebアプリケーションによってアップロードされたファイルを処理できます。 このようにすると、いくつかのユースケースではLambda関数によって実装がより容易になります。例えば: /tmpで使用可能な容量(512MB)より大きいデータを処理またはロードする。 頻繁に変更されるファイルの最新バージョンをロードする。 モデルやその他の依存関係をロードするためにストレージ容量を必要とするデータサイエンスパッケージを使用する。 呼び出し間で関数の状態を保存する(一意のファイル名またはファイルシステムロックを使用)。 大量の参照データへのアクセスを必要とするアプリケーションの構築。 レガシーアプリケーションをサーバーレスアーキテクチャに移行する。 ファイルシステムアクセス用に設計されたデータ集約型ワークロードとの相互作用。 ファイルを部分的に更新する(同時アクセス用のファイルシステムロックを使用)。 アトミック操作でファイルシステム内のディレクトリとそのすべてのコンテンツを移動する。 EFSの作成 EFSをマウントするには、Lambda関数がEFSマウントターゲットに到達できるAmazon Virtual Private Cloud(VPC)に接続されている必要があります。ここでは、簡単にするために、各AWSリージョンで自動的に作成されるデフォルトのVPC を使用しています。 Lambda関数をVPCに接続する構成にすると、ネットワーク環境の変化に伴う変更が必要になることがある点に注意してください。 Lambda関数がAmazon Simple Storage Service(S3)またはAmazon DynamoDBを使用している場合は、それらのサービスのゲートウェイVPCエンドポイントを作成する必要があります。 Lambda関数がパブリックインターネットにアクセスする必要がある場合、たとえば外部APIを呼び出す場合は、NATゲートウェイを構成する必要があります。通常、デフォルトVPCの構成は変更しません。特定の要件がある場合は、AWS Cloud Development Kitを使用してプライベートおよびパブリックサブネットで新しいVPCを作成するか、これらのAWS CloudFormationのサンプルテンプレートのいずれかを使用します。このようにすることで、ネットワークをコードとして管理できます。 EFSコンソールで、[Create file system]を選択し、default のVPCとそのサブネットが選択されていることを確認します。すべてのサブネットで、同じセキュリティグループを使用してVPC内の他のリソースへのネットワークアクセスを提供するデフォルトのセキュリティグループを使用します。 次のステップでは、ファイルシステムにNameタグを付け、他のすべてのオプションをデフォルト値のままにします。 次に、[Add access […]

Read More

Amazon EKS Windows コンテナで Calico を使用する

 この投稿は、ソフトウェア開発エンジニアの Anuj Singh 氏とエンタープライズソリューションアーキテクトの Steven David 氏によって提供されたものです。 このブログ投稿では、Amazon Elastic Kubernetes Service (EKS) で実行されている Calico for Windows コンテナをインストールして使用する方法について、順を追って説明します。 Tigera Calico for Windows は、Kubernetes ベースの Windows ワークロード向けのネットワーキングおよびネットワークセキュリティソリューションです。.NET アプリケーションなどの Windows ワークロードを EKS 環境に移動でき、ネットワークポリシーの適用の管理に Calico を役立てることができます。ネットワークポリシーは、ポッドなどの低レベルのデプロイでネットワークを定義できる AWS セキュリティグループに似ています。 Calico は以前 Amazon EKS Linux 環境で検証されました。プロセスはこちらに記載されています。本日は、EKS Windows ワーカーノードにおける Calico のサポートについて詳しく説明しています。Windows ノードの Calico は、Linux ノードのポッドとは対照的に、Windows サービスとして実行されます。 Tigera Calico for Windows は通常、Tigera […]

Read More

“共有型”AWS DirectConnectでも使えるAWS Transit Gateway

AWS Transit Gateway (TGW)は徹底的に進化することにより、クラウドネットワーキングを簡素化しました。本記事では、複数Amazon Virtual Private Cloud(VPC)とオンプレミスの接続パターンを紹介します。 AWSでは、オンプレミスのネットワークとの接続にはAWS Direct Connect(DX)を使います。DX接続は様々な形態がありますが、日本のお客様に多い“共有型”DX接続ではTGWを直接使うことができません。TGWを使うことができることが“専有型”DX接続の優位点の一つですが、本記事では”共有型”DX接続でTGWを使った接続実現する方法を含めて、いくつかの接続パターンを解説します。 TGWのメリット TGWを使用すれば、一貫した信頼性の高いネットワークパフォーマンス を実現しながら、複数のVPCおよびDXを使ってオンプレミスネットワークを相互接続するのはお手の物です。TGWは各VPC、VPN、DXの間のすべてのトラッフィクを一箇所で制御することができます。 専有型が利用できる場合にはTGWとDXをつなぐと、AWSを経由してインターネット接続することもできます。 上の例では、TGWがAWS Direct Connect Gateway(DXGW)にアタッチされています。 DXの複数VPCでの利用は典型的なユースケースです。一方で、DXは1Gbps以上の接続につきTGWのためのトランジット仮想インターフェースは1つだけという制限があります。つまり、日本のお客様に多い、“共有型”DX接続ではTGWを直接使うことができません。 ここでは、複数VPCとオンプレミスの接続パターンを以下4つに整理してみます。1つ目だけが、“専有型または1Gbps以上のホスト型接続”のみ実現可能です。 TGWにDXをつける DX用のVPCにNetwork Load Balancer(NLB)を配置。VPC間はTGW DX用のVPCにNLBを配置。VPC間はAWS PrivateLink(Private Link) DXGWにVPCをつける 1. TGWにDXをつける この場合、すべてのトラフィックはTGWで管理できます。AWSを経由したインターネット接続もProxyなしで実現できます。また、全トラフィックを”監査用アプライアンス”に通すことで全トラフィックの記録 / 制限 / 監査も可能ですので、セキュリティ面でも有利です。 2. DX用のVPCにNLBを配置。VPC間はTGW DXにつながるVPCとして“DX用VPC”1つが現れました。このとき、DXからみれば1つの”DX用VPC”がつながるだけですので、”共有型”でも問題ありません。VPC間の通信はTGWで設定制御ができます。 オンプレミス↔VPC間で通信をしなければならない特定のサーバのフロントにはDX用VPCにNLBを設置することで通信できるようにします。サーバの数だけNLBを設定するため、サーバ数が増えるとNLBの時間あたり費用がかさむことに注意してください。 3. DX用のVPCにNLBを配置。VPC間はPrivateLink このパターンでは、PrivateLinkが重要です。マイクロサービスなど、VPCを自由にいくつも使っている場合には、IPアドレスブロックが重複することはよくあることです。2つ目のパターンでは、TGWをつかってVPC間の通信を制御していました。TGWではアドレス重複の答えにはなりません。PrivateLinkはその解決策です。 VPC間およびオンプレミスとの特定の通信はPrivateLinkで設定します。VPCからオンプレミス上のサーバにアクセスするためにも使うことができます。 4. DXGWにVPCをつけたとき VPCとオンプレミスの間の通信はあるけれども、VPC同士の通信が無いのであれば、TGWは実は必要なかったのかもしれません。なお、一つのDXGWに接続できるVPCは10までですので、スケーラビリティにもやや難があるかもしれません。VPCの数が10以上になった場合、2つめの共有型Private VIFを利用する事により、多くのVPCと接続することができます。ただし、共有型VIFを増やし続けると、”1.”でご紹介した専有型接続の方が結果的に安価となる分岐点に到達します。詳細な見積もりが必要な場合は、利用するパートナー様にご確認ください。 比較 比較の一覧を追加しておきます。料金試算は、東京リージョンで、3つのサービス用VPCと1つのオンプレミスのネットワークを接続し、サービスするVPCひとつあたり月間10TB通信があり、DXのIn/Outの比率が1:1の場合です。(詳細は最後に) 案1: TGWにDXをつけたとき 案2: DX用のVPCにNLBを配置。VPC間はTGW 案3: DX用のVPCにNLBを配置。VPC間はPrivateLink […]

Read More

AWS Storage Gateway を使用してオンプレミスアプリケーションをクラウドにバックアップする

データは世界中で指数関数的に増加し続けており、どの組織にとってもデータの保護と保持は重要課題です。お客様の中には、クラウドジャーニーを何年にもわたって続けているところもおり、ハイブリッドクラウドモデルでオンプレミスのストレージインフラストラクチャを管理および維持し続けています。データ保護と長期保存要件を満たすために、多くの組織は、オンプレミスの物理テープインフラストラクチャ、バックアップインフラストラクチャ、およびオフサイトストレージを管理および維持するために多大な時間とリソースを費やしています。ビジネスや規制遵守のためにデータを保存する必要があるため、お客様はオンプレミスのストレージ容量の問題に直面することがよくあります。これは、新しい要求に対応する能力を遅らせ、俊敏性を損ない、最終的にはデータ保護戦略に潜在的なリスクをもたらします。 お客様からは、コストとスケーリングの課題に対処するために、AWS を活用するのにオンプレミスのデータ保護インフラストラクチャをどのように変革したらよいかという質問をよく受けます。AWS Storage Gateway を使うと、お客様はオンプレミスアプリケーションを事実上無制限のクラウドストレージにバックアップできます。これにより、AWS にデータを永続的に保存しながら、オンプレミスのストレージを解放できます。 この記事では、お客様が Storage Gateway を使用してオンプレミスアプリケーションをクラウドにバックアップおよび復元する方法を示します。File Gateway、Tape Gateway、Volume Gateway のユースケースと、各ゲートウェイをストレージターゲットとして使用してコスト効率よくオンプレミスアプリケーションを AWS にバックアップする方法について説明します。 AWS Storage Gateway お客様は Storage Gateway を使用して、オンプレミスアプリケーションを保護し、バックアップインフラストラクチャと管理コストを削減しています。Storage Gateway を使用して、ファイル、アプリケーション、データベース、ボリュームを Amazon S3、Amazon S3 Glacier、Amazon S3 Glacier Deep Archive、Amazon EBS にバックアップしています (AWS のファイル、ボリューム、スナップショット、仮想テープを通じて)。一部のお客様は、Storage Gateway を使用して既存のストレージインフラストラクチャをシームレスに補完し、オンプレミスのストレージ容量をオフロードしたり、拡張したりしています。ハードウェアの調達が必要ないため、このようなデプロイはより迅速に、より短時間で行えます。 お客様は Storage Gateway を使用して、オンプレミスアプリケーションを AWS にシームレスに接続して、クラウドストレージのスケーラビリティ、信頼性、耐久性、経済性を活用できます。Storage Gateway は、NFS、SMB、iSCSI や iSCSI-VTL などの標準ストレージプロトコルをサポートしています。既存のアプリケーションに必要な変更は最小限で、オンプレミスとクラウドの両方をブリッジするハイブリッドストレージ環境をサポートする必要があるお客様にとって理想的なソリューションです。Storage Gateway は、高度に最適化されたデータ転送メカニズム、帯域幅管理、および自動化されたネットワーク回復力を使用して、効率的なデータ転送を実現しています。すべてのデータは、送信時およびクラウドでの保管時に暗号化されます。 ユースケースに応じて、Storage Gateway […]

Read More

Amazon EC2 スポットインスタンスを活用したウェブアプリケーションの構築

本記事は、EC2スポットインスタンススペシャリスト シニアソリューションアーキテクトのIsaac Vallhonratによる寄稿です。 Amazon EC2 スポットインスタンスを使うと、AWS クラウド内の使用されていない EC2 キャパシティーを用いて、オンデマンド料金に比べ最大 90% の割引価格でご利用いただけます。スポットインスタンスは、バッチジョブ、ビルド等のCI/CDパイプライン、負荷テスト、コンテナ化されたワークロード、ウェブアプリケーション、ビッグデータの分析クラスター、ハイパフォーマンスコンピューティング(HPC)用計算クラスターなど、複数のインスタンスタイプで柔軟に実行できる、耐障害性を備えたワークロードに最適です。このブログ投稿では、スポットインスタンスでウェブアプリケーションを実行するための方法とベストプラクティスについて説明し、これによりもたらされるスケールと費用節減の両方のメリットを得られるようにします。 スポットインスタンスには中断という特徴があります。この特徴を踏まえて、これから構築するウェブアプリケーションはステートレスかつ耐障害性があり、また疎結合されていることが望ましいです。また永続データの保持には Amazon ElastiCache, AmazonRDS, Amazon DynamoDB などの外部データストアを使用する必要があります。 スポットインスタンスのおさらい 2009 年に提供開始されたスポットインスタンスは、ここ最近のアップデートや関連サービスとの統合によって、お使いのワークロードで格段に活用しやすくなっています。ウェブアプリケーションを構築する方法の詳細に入る前に、スポットインスタンスの動作の概要のおさらいにお付き合いください。 まず、スポットインスタンスは EC2 の購入オプション、買い方のひとつです。 他の購入オプションである、オンデマンドインスタンス、リザーブドインスタンスやSavings Plansで起動した場合と比べて、EC2インスタンスとして提供するハードウェアに違いはありません。スポットインスタンスと他の購入オプションの違いはただ一つ、EC2 サービスが容量を必要とする場合には、2 分前に通知したのち、EC2サービスがスポットインスタンスを中断する、という動作です。つまり、大幅な割引価格で提供する代わりに、オンデマンドインスタンスやリザーブドインスタンスからの起動需要が高まってきたとき、スポットインスタンスの使用していたキャパシティをEC2サービスに戻し、需要に応える、というのがスポットインスタンスサービスの動作原理です。 スポットインスタンスは、スポットキャパシティプールと呼ばれる、いわば空きキャパシティがある限り起動できます。スポットキャパシティプール(スポットプール)とは、とは、インスタンスタイプ (m5.large など), オペレーティングシステム種別(Linuxなど), アベイラビリティーゾーン (us-east-1a など) が同一である、Amazon EC2 サービスが使用していない(空の) EC2 インスタンスの集合を指します。属性の異なるプール同士はそれぞれ独立したプールとして区別されます。例えば、us-east-1aゾーンのLinux向けm5.largeのスポットプールと、us-east-1bゾーンのLinux向けm5.largeのスポットプールは、独立した別のプールです。このそれぞれに空きがあるとき、スポットインスタンスを起動し、使用できます。 スポットインスタンスの料金は Amazon EC2 サービスによって設定され、各プールの EC2 インスタンスの需要と供給の長期的な傾向に基づき、徐々に調整されます。スポット料金は急激に変化することはなく、突然のスパイクや変動がないことが期待できます。 EC2 マネジメントコンソールと API の両方から、最大過去 3 か月間の価格履歴データを表示できます。次の図は、バージニア北部 (us-east-1) リージョンにおける m5.xlarge […]

Read More