Amazon Web Services ブログ

Category: *Post Types

LAMP ベースの多層ウェブアプリケーションを AWS Snowball Edge にデプロイする

遠隔地でアプリケーションを構築していて、モニタリングカメラや検出システムなど、ローカルで生成されたデータに基づいて処理および決定を行う必要があるころを想像してみてください。ネットワークのレイテンシーが長い場合、このようなアプリケーションをクラウドで実行してデータをリアルタイムで処理することはできません。 また、災害から復旧する状況で作業していることもあるでしょう。この場合、クラウドでデータを転送し、処理するのに十分な帯域幅がない可能性があります。また、コンピューティング、ストレージ、ネットワーク、アプリケーションを短時間でデプロイするという制約も加わります。インターネット接続が利用できない場合は、オフラインで実行し、ネットワーク接続が利用できるようになったときにデータをクラウドと同期できるはずです。 AWS Snowball Edge はローカル環境とクラウド間でデータ転送が行える高耐久化されたエッジコンピューティングソリューションです。これは、ネットワークに断続的に接続または切断された環境でコンピューティングインスタンスを実行するのに利用できます。Snowball Edge の運用に必要なインフラストラクチャは最低限でよく、特に専用のデータセンターは必要ありません。Snowball Edge では、さまざまな vCPU とメモリオプションを備えた Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを作成し、アプリケーションをホストできます。これらのユニークな機能により、Snowball Edge は前述のユースケースの理想的なソリューションになっています。 このブログ記事では、Snowball Edge で EC2 インスタンスを起動し、ウェブアプリケーションを起ち上げる方法を詳しく見ていきます。Apache、MySQL、PHP (LAMP)、および人気のあるコンテンツ管理システム (CMS) である Drupal をインストールします。Drupal の動画モジュールを活用して、ここで説明したメディアワークフローの一部を実装できます。このモジュールにより、動画を任意の形式でアップロードし、動画を H.246、Theora、VP8 (ウェブ互換形式) にトランスコードし、サムネイルを作成できます。動画モジュールは、Amazon Simple Storage Service (Amazon S3) を活用するクラウドトランスコーディングサービスである Zencoder、またはサーバーでオープンソースの FFMPEG を使用します。 AWS Snowball Edge の機能 Snowball Edge により、さまざまな vCPU およびメモリオプションを備えた EC2 インスタンスを作成し、アプリケーションをホストできます。Amazon […]

Read More

Amazon S3 バッチオペレーションを使用して保存期間を一括管理する方法

Amazon S3 バッチオペレーションが S3 オブジェクトロックをサポートするようになりました。この記事では、これら 2 つの Amazon S3 機能を一緒に使用して、一般的なデータ保護のニーズに対処する方法を紹介します。S3 バッチオペレーションは、何百万ものオブジェクト間でタグセットをコピーしたり更新したりするなどの反復アクションまたは一括アクションを 1 度のリクエストで実行できる機能です。提供するのはオブジェクトのリストのみで、S3 バッチオペレーションは再試行の管理や進行状況の表示など、すべての手動作業を処理します。S3 バッチオペレーションの詳細については、こちらのブログ投稿をご覧ください。 S3 オブジェクトロックを使用すれば、オブジェクトに保存日と訴訟ホールドを適用して、オブジェクトが無期限、あるいは特定の日付が経過するまで削除または上書きされないようにすることができます。S3 オブジェクトロック向け S3 バッチオペレーションのサポートは、ライトワンスリードメニー (WORM) ストレージの規制要件を満たすのに役立ちます。さらに、オブジェクトを変更または削除する際に保護するためのレイヤーを追加するだけです。 ベーシック Amazon S3 オブジェクトロックには、オブジェクトの保持期間を管理する 2 つの方法があります。 保持期間は、オブジェクトがロックされたままの状態になる固定期間を指定します。この期間中、オブジェクトは WORM で保護されており、オブジェクトのバージョンを削除または変更することはできません。S3 オブジェクトロックは、2 つの保存期間モードを提供します。 ガバナンスモードでは、ほとんどのユーザーによって削除されないようにオブジェクトを保護していますが、保存設定を変更したり、必要に応じてオブジェクトを削除したりする権限をユーザーに付与することもできます。 コンプライアンスモードで保護されたオブジェクトのバージョンは、AWS アカウントのルートユーザーを含め、どのユーザーも上書きまたは削除を行うことができません。 訴訟ホールドは、保持期間として同じ保護を行いますが、期限がありません。代わりに、訴訟ホールドは、明示的に削除するまでその場に置かれたままになります。 オブジェクトのバージョンは、保持期間または訴訟ホールドのいずれか、あるいはその両方の組み合わせを設定できます。たとえば、1 年間の保持時間プラス訴訟ホールドが設定されたオブジェクトをもつ場合があります。正確な保存日がわかる場合は保存期間を使用し、要件に合った保存モードを選択します。 S3 オブジェクトロック向け S3 バッチオペレーションのサポートはいつ使用しますか? バケット内の多数のオブジェクトに S3 オブジェクトロック設定を適用、更新、または削除する必要がある場合は、S3 オブジェクトロック向け S3 バッチオペレーションサポートの使用をご検討ください。S3 オブジェクトロックを初めて使用する場合、S3 オブジェクトロック向け S3 バッチオペレーションのサポートを使えば、これらの変更を簡単に行えます。既存の S3 オブジェクトロック要件が変更され、多数のオブジェクトのロックを更新、追加、または削除する必要がある場合にも当てはまります。オブジェクトがバケットに追加されたときに、S3 […]

Read More

認知科学と学習 1: 反復学習テクニックを活用した学びの効率化

アマゾン ウェブ サービス (AWS) の 175 を超えるサービス群、数百にもおよぶ機能、クラウドコンピューティングの用語や概念という新しい語彙。これらは AWS の構築を学ぼうとする際に最初の壁となり立ちはだかります。この壁は多少険しいものに感じられるかもしれません。また、情報を受動的にインプットする学習法にばかり頼っていると、壁を乗り越えるのは難しくなってしまいます。 一方でこの障壁の高さを引き下げて、 AWS ビルダーとしての学習目標の達成を支援してくれるものもあります。人間にとって最も効果的な学習方法に関する、数十年にわたる研究から得られた認知科学的な知見、そして 数百に及ぶ AWS トレーニングポートフォリオ を活用できることです。 これからシリーズブログとして、数回にわたってこのテーマを扱っていきます。シリーズ内の各記事では、AWS のサービス、機能、および関連する概念をより効果的に学習し、結果としてより優れたビルダーになるために活用できる認知科学の原則に焦点を当てていきます。このシリーズでは次のテーマに基づいて概説していきます。 反復学習 時間差学習 エラボレーション   シリーズ第 1 弾となる今回は、反復学習についてご紹介しましょう。 反復学習の原則とは、学習者が以前に見たり聞いたりした情報を定期的に記憶から取り出して、その情報を使用して問題を解決したり質問に回答したりすることで、長期学習が強化されることと規定されています。 つまり反復学習とは、自分の記憶から情報を引き出す機会を学習者が自分自身に与えることです。 これは情報のインプットのみに重点を置いた、前述のアプローチとはまったく対照的です。学習した情報を保存するニューラルネットワークはその情報を繰り返し受動的に取り込むのではなく、自分の力で情報を思い出す(または記憶から取り出す)ことで強化されます。   通俗的な学習方法においては情報のインプットに重点を置く傾向がありますが、脳の学習方法に関する研究では、(反復: Retrieval により) 情報の取り出しを行うことが長期学習に不可欠であることがわかっています。   簡単な例を見てみましょう。2 つのグループがあります。どちらのグループも、Amazon S3 に関するプレゼンテーションに参加しました。それ以降 2 週間にわたり、1 つ目のグループ (反復学習グループ (Retrieval Group):RG) のメンバーは、参加したプレゼンテーションで紹介された主な概念やトピックを思い出せるかどうかを試す一連のクイズに参加します。 一方で 2 つ目のグループ (非反復学習グループ (Non-Retrieval Group):NRG) のメンバーは、プレゼンテーションで紹介され主な概念とトピックを繰り返す、一連のフォローアッププレゼンテーションに参加します。RG とは異なり学んだ情報に関するクイズやテストは受けません。 最初のプレゼンテーションから数週間さらには数か月後、RG は Amazon S3 に関連する記憶の保持に関して […]

Read More

AWS Snowball Edge での AWS Identity and Access Management

お客様の多くは、安全なデータ転送とエッジコンピューティングアプリケーションのために AWS Snowball Edge デバイスを使用しています。最近、AWS は Snowball Edge での AWS Identity and Access Management (IAM) のサポートを発表しました。Snowball Edge に IAM を導入する前まで、IT 管理者はファイルをコピーしたり、コンピューティングワークロードを実行したりするユーザー全員と、単一のアクセスキー/シークレットキーの組み合わせを共有していました。このアクセス方法は、個々のサービスを制御できるほどの詳細度と柔軟性を持ち合わせていませんでした。IAM では、ユーザーが実行できるアクションを制御することにより、Snowball Edge デバイスで実行されている AWS サービスおよびリソースへのアクセスを安全に管理できます。IAM を使用すれば、デバイスユーザーがアクションを実行するために使用するデバイス上のどの AWS リソースも管理することができます。このブログでは、Snowball Edge での IAM 機能を探索し、いくつかの実用的な例を示しています。 概要 Snowball Edge を使用すれば、インターネットへの接続が選択肢にない場所でも、AWS クラウドのストレージとコンピューティングパワーにローカルで費用対効果の高い方法でアクセスできます。オンプレミスのデータセンターと Amazon Simple Storage Service (Amazon S3) の間で数百テラバイトまたはペタバイトのデータを転送できます。さらに、Snowball Edge は特定の Amazon EC2 インスタンスタイプと AWS Lambda 関数を実行する機能を提供するため、オンプレミスまたはクラウドで開発されたアプリケーションを同じデバイスにデプロイできます。Snowball Edge の一般的な使用例には、データ移行、データ転送、データ分析、画像照合、IoT […]

Read More
SharedResponsibilityModel

責任共有モデルとは何か、を改めて考える

本Blogは、クラウドにおける新しい常識”new normal”を考えるBlogの第二弾です。(第一弾「クラウドにおける安全なデータの廃棄」はこちら) 今回は、クラウドの基本的な考え方である”責任共有モデル”をとりあげます。こちらのBlogをご覧の皆様の中には”何故、いまだに責任共有モデルなのか”という疑問を持つ方もいらっしゃるかもしれません。しかし、未だに本モデルの考え方や実際のビジネスへの適用方法は十分に理解されていないようにも見受けられます。今回は責任共有モデルとは何か?を振り返るとともに、いくつかの理解のポイントをお伝えします。 セキュリティ責任共有モデルとは? ”セキュリティとコンプライアンスはAWSとお客様の間で共有される責任です。この共有モデルは、AWSがホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティに至るまでの要素をAWSが運用、管理、および制御することから、お客様の運用上の負担を軽減するために役立ちます。お客様には、ゲストオペレーティングシステム (更新とセキュリティパッチを含む)、その他の関連アプリケーションソフトウェア、およびAWSが提供するセキュリティグループファイアウォールの設定に対する責任と管理を担っていただきます。使用するサービス、それらのサービスの IT 環境への統合、および適用される法律と規制によって責任が異なるため、お客様は選択したサービスを慎重に検討する必要があります。また、この責任共有モデルの性質によって柔軟性が得られ、お客様がデプロイを統制できます。以下の図に示すように、この責任の相違は通常クラウド ’の’ セキュリティ(Security ‘of’ the Cloud)、およびクラウド ’における’ セキュリティ(Security ‘in’ the cloud)と呼ばれます。” 責任共有モデルを踏まえたセキュリティ効率性の改善 責任共有モデルを適用するうえでのメリットを考えてみましょう。例えばお客様がPCI DSS等の認証の取得を考えた場合、全ての要件を自社で管理を行うことは非常に負荷が高く、コストもかかる作業となります。AWSはPCI DSSを含めた様々なコンプライアンスプログラムや第三者認証に取り組んでおり、お客様は自らの認証の範囲からデーターセンターの物理的な統制を除外することができます。お客様はAWS Artifactからリポートを入手することで、物理統制の評価が可能となります。この場合、認証の範囲を縮小することは審査だけでなく運用上の負荷においても大きな便益をお客様にもたらします。 同様にAWSのサービスを考えた場合、Amazon EC2インスタンスにサービスを構築する場合と、Amazon RDSなどのマネージドサービスやAWS Lambdaなどのサーバレスアーキテクチャを活用してサービスを構築した場合では、パッチの適用やバックアップ管理等、セキュリティに関連する負荷は大きく異なります。サービス自体やセキュリティ管理策に対する運用の経済性を考えた場合、AWSにセキュリティ管理を任せることで、お客様はその分の投資をサービスの改善やより重要なワークロードに振り分けることができることになります。つまり、組織がガバナンス上で何を重要とするかといった考え方に基づき、選択肢を持つことが可能となります。 AWSは”クラウド内のセキュリティに対する責任”を助けないのか。 上記のモデル図で考えた場合、責任の分界点として、”ユーザのセキュリティに対してAWSは何もしてくれないのか”という疑問をもたれるケースがあります。もちろん、そうではありません。AWSは様々な手段でお客様のセキュリティの実現を支援します。第一に、AWSは豊富なセキュリティサービスや機能、アップデートを提供しています。AWSにおける脆弱性の発見等はセキュリティ速報に公開され、お客様はRSSフィードで購読することが可能です。これらにより、お客様は自らのニーズにあったセキュリティの実装や対応を行うことができます。次に、開発者ガイドや各種ホワイトペーパーなどをもとにお客様のセキュリティに対して必要な情報を提供しています。また、単に設定方法を伝えるだけではなく、Well Architectedフレームワークは、クラウドの特性を活かしたサービスの原則を提供することで、お客様のセキュリティを支援する道具になります。 また、支援は機能やサービスだけではありません。AWSではSolution Architectによる技術支援やProfessional Servicesによる有償コンサルティングサービスの提供、Certification and Training teamによるトレーニングサービスの提供、AWS Supportによるお客様課題の支援や対応窓口の提供など、様々な形での組織的な支援を行っています。例えばAWS Supportではナレッジセンターとしてお客様からのお問い合わせの頻度の多い質問に対する回答を公開しています。 また、お客様がコンプライアンスに準拠した環境でサービスを設計、運用するためには、実際の構築や運用の担い手となるパートナー様の尽力が不可欠です。政府機関における「政府機関等の情報セキュリティ対策のための統一基準群」に対するリファレンスや金融業界における「FISC安全対策基準」へのリファレンス等は、AWSJの協力に基づきAPNパートナー様により開発、公開されており、システムインテグレーターや開発、運用事業者はこれらを活用することが出来ます。 このようにAWSは組織的、技術的に様々なアプローチでお客様のセキュリティをサポートする手段を提供しています。 多くの”責任共有モデル”は二階層ではない。 上記のモデル図は”AWS”と”お客様”の二階層で責任共有を表現しています。しかし、様々な場合において、二階層で責任共有モデルを考えることは現実的ではないことがあります。例えば、日本では多くの調達や開発、運用において、システムインテグレーターや開発、運用事業者が存在する場合がありますし、例えばお客様がSaaS事業者と契約した場合、そのインフラストラクチャをAWSが提供している場合があります。こうした場合、セキュリティは重層的になります。実際にはお客様の中でも様々な責任共有の形があります。また、お客様の中にも責任共有モデルは存在します。事業部門とシステム部門、監査やリスク管理部門など、単一の組織においてもセキュリティの責任は複数の組織で共有しているものとなります。責任の範囲を明確にすることは本来は自然なことであり、まずは範囲を明らかにした上で、どのように協働をおこなうかというプロセスが重要になります。 重層的な責任共有モデルにどう向き合うか お客様がSaaS事業者やシステムインテグレーターと契約した場合、セキュリティに対する説明責任はそのような事業者自身がAWSが提供する様々な情報を活用してお客様と向き合うとともにセキュリティの実装などに責任を持つことになります。こうしたパートナー様のエコシステムの育成や拡充のために、APNパートナープログラムではセキュリティコンピテンシーやパブリックセクターコンピテンシー等、お客様が業界や技術に明るいパートナーを選択できる仕組みを提供しています。既にご説明したAPNパートナー様によるセキュリティリファレンスなどの取り組みも進展しています。また、お客様の中における責任共有モデルにおいても、AWSでは実際にお客様の様々なクラウド移行を支援してきた経験から、お客様内におけるクラウド推進組織であるCloud Center of Excellence (CCoE)の設立などをベストプラクティスとしてお客様にお伝えしています。 責任共有モデルは”セキュリティだけ”のものではない。 このような責任共有という考え方は、”セキュリティだけ”に適用されるものではありません。例えば、ある情報システムのクラウド移行を想定した場合にも、“移行計画”の策定、“予算”の見積もりと確保、“クラウド要件”の定義、“調達/購買”の実施、(特に公共部門の場合には)“契約”の締結、実際の“精算”・・といった一連のプロセスが伴います。ここで注目すべきは、ユーザ側・調達者側が上記の一連のプロセスにおいてガバナンスを強化することが望ましい「new normal」においては、従来のモデルとは責任主体や責任の共有の仕方が異なるケースが頻発する、ということです。例えば:  “予算”の見積もりと確保──クラウドのコストメリットは、従量課金により実際に使った分だけを支払うことができる点に求められます。旧来の情報システムの発注は、その運用までも含め、固定額で見積もられることがほとんどでした。しかしクラウドを前提とした予算の確保では、ユーザ側・調達者側が積極的にクラウド利用料金の実績値管理(その頻度は週次であったり、日次で行うことも可能です)に主体性を持ち、次年度(場合によっては次期四半期)の予算確保の精度を継続的に上げていくことが求められます。ツールとしてはAWS Cost Explorer等が役立つはずです。 “調達/購買”の実施──旧来の情報システムの“調達/購買”においては、システム・インテグレーター(SI)によってシステム構成要件の全てを満たすことが期待されていました。しかしクラウドを前提とした調達/購買においては、これらの要件をSI/AWS/調達者の三者(あるいは、リセラーを含めた四者)によって分担し、共有することが必要となります。SIに求めるべきことをクラウドサービス事業者に求めるべきではなく、その逆もまた然りであるため、両者には別途独立した要件を求めることが妥当です。 […]

Read More

金融機関で活用される AWS のテレワーク支援サービス

金融機関の皆様においては、社会を取り巻く状況の急変に伴い、お客様及び従業員の皆様を保護しつつサービスレベルや業務効率を維持されるためのさまざまな対策を講じられていることと存じます。そして金融庁からも4月13日に「出勤者7割削減」の要請が周知され、テレワーク環境の構築は、金融業界全体としても喫緊の課題として認識されているものと思います。 欧米各国においては、金融機関の事業継続に向けて、AWS のサービスを活用したテレワーク対応を進めて頂いている事例があります。例えば、ある大手金融機関では、在宅オペレーター数を数百人から数千人に拡張したり、また、別の金融機関では、FAQ におけるチャットボットの活用を促進しています。また、従業員及びその顧客を対象に数千席規模の仮想デスクトップ環境を提供することで業務の継続を図っているケースもあります。 日本でも多くの金融機関のお客様から、テレワークのソリューションに関する問合せ・ご相談を頂いています。既に日本の金融機関でも、AWS  のテレワークを支援するサービスを活用して、数週間でコンタクトセンターのオペレーターの在宅勤務環境を構築したり、仮想デスクトップ端末を短期間で数千台規模に拡大させて社員のテレワーク対応に取組んでいる事例が出てきています。 AWS では、お客様のテレワークを支援するサービスとして、在宅コンタクトセンターの迅速な構築をご支援するフルクラウド型のコンタクトセンター Amazon Connect、社内システムへのリモート環境からのアクセスを実現する仮想デスクトップソリューション Amazon WorkSpaces、フルマネージド型のコンテンツコラボレーションサービス Amazon WorkDocs、リモートでのコミュニケーションやコラボレーションを支援する Amazon Chime、スケーラブルなリモートネットワークアクセスを可能とする AWS Client VPN などを提供しています。 いずれの AWS サービスも、クラウドならではの俊敏性と拡張性を備えており、今回のように急遽テレワーク環境構築が必要とされているケースにご活用いただけるものです。そして、AWSでは、クラウドのセキュリティが最優先事項です。AWSは、高いセキュリティ及びコンプライアンス要件を持つ金融機関のお客様に、テレワークを支援するサービスを安心してご利用いただけるよう、アーキテクチャーの設計をご支援します。 本 Blog では、AWS のテレワークを支援するサービスの中でも、お客様からの問い合わせが多い Amazon Connect と Amazon WorkSpaces について概要をご紹介したいと思います。また、これらのサービスの詳細をご紹介するオンラインセミナーを5月22日に開催する予定です。こちらも是非お申込み頂ければと思います。

Read More

AWS Academy による高等教育への投資

世界中で高等教育が面している課題については、既知の事実であり嘆くべきことです。高騰を続ける学費は、教育への投資に対する利益率を減少させるばかりでなく、教育の享受のしやすさや公平性まで脅かし、企業が求める人材へのニーズと、卒業生が持つスキルのギャップも広げています。こうしたトレンドは、教育システムに対する信頼の危機を招いています。米国 Gallup polls の調査によると、2015 年以来、高等教育システムの信頼度は低下の一途を辿り、英国でも多くの学生が自身の能力の価値について懸念を持っていることが報告されています。 こうした動向は憂慮すべき一方、同時にイノベーションや連携への新しい扉を開いているとも言えます。高等教育機関には、学生たちがより良い学習体験を得て成果をもたらすことを視野に、競争力かつ創造性のある方法を見い出すことが求められています。そのため、従来のビジネスモデルやアプローチの見直しを図ることを余儀なくされています。 しかし、新しい世代の若者が社会に羽ばたく準備をする負担を、高等教育機関だけに押し付けるべきではありません。企業もその責任の一端を担い、教育機関と連携し支援することに対し膨大な動機付けが必要です。米国 Manpower Group の報告によると、世界中の企業の 54% が、最長では 10 年以上に渡り人材不足であると報告しています。アマゾン ウェブ サービス (AWS) では、お客様やパートナー様から、クラウドコンピューティング業界では、「量」と「質」の両方の側面でこのスキルギャップの課題が顕著になっている – 大学は雇用側が求めるレベルのクラウドスキルを身につけた十分な数の学生を輩出できていないと耳にします。この課題を効果的かつ意図的に解決し、必要な人材のサプライチェーンを構築するためには、産学連携が必要不可欠です。 AWS Academy で世界中の高等教育機関に投資を行っているのはこのためです。AWS Academy は、クラウドコンピューティングのエントリーレベル人材のパイプラインを構築するために設計され、AWS 公認のコース、教育者向けのトレーニングを無償で提供するプログラムです。私たちは高等教育がまだ世界的に労働力創出の重要な場であると信じています。そして、学生が需要のある役職に就職する準備をするのに必要なスキルやリソースが確実に教育者に行き渡るよう尽力しています。 では、産学連携とは言っても、効果的な連携とはどのようなものなのでしょうか。これまで、世界中の地方や都市部のコミュニティーで、小規模のコミュニティ・カレッジや大規模な研究機関で、この連携が形になっているのを目にしてきました。最も成功しているのは、卒業生の雇用適性について前向きかつフレキシブルで、熱意を持って取組んでいる教育機関です。   インド Charotar University の AWS Academy 認定講師、Sandip Patel 氏と学生たち   例えばインドの Charotar University of Science and Technology では、AWS Academy 認定講師である Sandip Patel 氏が地元のスタートアップ企業 2 社と連携し、学生に AWS のハンズオンプロジェクトワークを提供しています。地元のリクルーターが大学を訪れた際、20 […]

Read More

既存のAWSアカウントを AWS Control Tower へ登録する

AWS Control Tower のリリース後、多くのお客様からいただいていたご要望がありました。既存のAWS Organizations に AWS Control Tower をデプロイすることと、組織が持つ他のアカウントにもガバナンスを拡張することです。 このたび、AWS Control Tower を既存の AWS Organization にデプロイできるようになったことをアナウンスいたします。一方で、AWS Control Tower をデプロイする前に作成した AWS アカウント(ここでは「未登録アカウント」と呼びます)は、デフォルトでは AWS Control Tower ガバナンスの範囲外になります。そのため、これらの未登録アカウントは明示的に AWS Control Tower へ登録する必要があります。 既存アカウントを AWS Control Tower へ登録することで、アカウントベースライン(基本設定)と追加のガードレールが配備され、継続的なガバナンス(Continuous Governance)が有効になります。なお、アカウントを登録する前には、適切なデューデリジェンス(事前評価)を行う必要があります。以下に記載されている「考慮すべき事項」セクションの追加情報を参照してください。 このブログでは、AWS Organizations 内の 未登録 AWS アカウントと 未登録 OU(Organization Units = 組織単位)内のアカウントを、プログラムによって AWS Control Tower へ登録する方法を解説します。

Read More

AWS Config 適合パックを使用したAWS Control Tower発見的ガードレールの実装

多くのお客様から、AWS Control Towerによるガバナンスを実現する前に、Control Towerの発見的ガードレールだけを既存のAWSアカウントに適用したいという要望をいただいています。この度、既存のAWS OrganizationでAWS Control Towerを起動できるようになりました。これにより、お客様は既存のアカウントにてAWS Control Towerの発見的ガードレールのコンプライアンスを適用できるようになりました。加えて、我々はControl Towerの配下にアカウントを登録する機能も発表しました。Control Towerガバナンスをアカウントに拡張する前に、Control Towerのガードレールがアカウントにどのように影響するかを確認することをお勧めします。 このブログでは、AWS Config適合パックを使用してControl Towerガードレールを既存のアカウントに適用する方法を示します。AWS Control Towerに登録する前に、そのアカウントのリソースのコンプライアンスを評価できます。また、適合パックを変更し、管理されていないアカウントに発見的ガードレールのサブセットを適用する方法を示します。最後に、適合パックを使用して、AWS Control Towerがデプロイされていないリージョンに存在するアカウントのリソースを管理する方法を示します。

Read More

AWS DataSync で数分でマネージドファイルストレージに移動

クラウドのメリットの概要はすでにご存知かと思います。IT インフラストラクチャの維持とは対照的なコアビジネス、向上した俊敏性と革新性、および収益の拡大に注力しましょう。AWS のフルマネージド型のファイルサービスポートフォリオは、ストレージの面でも、これらのメリットを実現するのに役立ちます。 この点をもう少し詳しく見ていきましょう。当社は、これを「他との差別化に繋がらない重労働の排除」と呼ぶこともあります。 おそらく、ファイルサーバーの実行は、コアコンピテンシーではないでしょう。そうではなく、ほとんどの場合、ファイルサーバーは、お客様が実行するアプリケーション、または顧客のためにホスティングしているサービスをサポートするために必要です。オンプレミスで実行している場合、ファイルサーバーの管理においては、いくつかの対応が必要となります。これらには、ハードウェアの調達、フロアスペースと施設の契約の調整、キャパシティーのプロビジョニング (おそらくピークデマンドに対応するための過剰なプロビジョニング)、およびストレージレイヤーでのビジネス継続性と災害復旧のための計画が含まれます。 この投稿では、クラウド内のマネージド型ストレージに移行するためのビジネスドライバーについて説明します。また、フルマネージド型のデータ転送サービスである AWS DataSync の使用を開始する方法についても説明します。 クラウド内のフルマネージド型のストレージ クラウドで独自のファイルサーバーを実行することにより、インフラストラクチャをオンデマンドでプロビジョニングできるため、調達やデータセンターの物理的なスペースの負担が軽減されます。しかし、キャパシティーとインフラストラクチャの管理は複雑であり、クラウドストレージのビルディングブロックを最大限に活用し、規模に応じたアーキテクチャを実現するという課題もあります。 フルマネージド型のストレージサービスに移行することで、キャパシティープランニング、インフラストラクチャとオペレーティングシステムのメンテナンス、スケールと高可用性のためのアーキテクチャの構築などに必要な労力をさらに削減できます。フルマネージド型のファイルシステムを使用すると、アプリケーションを書き直したり、環境をリファクタリングしたりする必要がないため、アプリケーションの Time-to-Value を最大化できます。アプリケーションが期待する形式でデータをロードし、その使用を開始するだけなので、とても簡単です。さらに良いことに、キャパシティープランニングなどのアクティビティ、バックアップ、高可用性といった機能は、すぐに使用できます。 当社の金融サービス分野のお客様の 1 社である LoanLogics は、マネージド型のストレージへの移行について次のように述べていました。 「当社では、多数ご参加いただいている新規顧客に対応するため、即刻、ストレージキャパシティーを拡大する必要がありました。AWS のファイルストレージサービスでは、アプリケーションのコードの変更は一切必要なく、数日の内にインフラストラクチャの拡大が可能でした。」 –Terrell Cassada 氏、CIO、LoanLogics アプリケーションのニーズに対応する AWS ファイルおよびデータ転送サービス AWS は、ビジネスクリティカルなアプリケーション向けに、フルマネージド型のファイルシステムサービスをいくつか提供しています。これらのうちの 2 つには、NFS を介してシンプルでスケーラブルかつ伸縮自在なファイルシステムを提供する Amazon Elastic File System (Amazon EFS) と、SMB を介してマネージド型のファイルシステムを提供する Amazon FSx for Windows ファイルサーバー (Amazon FSx) が含まれます。パフォーマンス、料金、マネージド型のストレージに移行した後にアプリケーションを最大限に活用する方法などのトピックに関する詳細情報については、re:Invent 2019 の次のプレゼンテーションをご覧ください。 データをオンプレミスから AWS に移動するため、当社は、EFS と […]

Read More