Amazon Web Services ブログ

Category: Technical How-to

委任された管理者からAWS Configルールと適合パックをデプロイする

AWS Configルールの使用により、リソースの構成をベストプラクティスに照らし合せて評価し、決められた構成ポリシーに従っていない場合は修正することができます。 AWS Config適合パックを使用すると、AWS Organizations全体に適用されるAWS Configルールと修復アクションのセットを単一のパックで作成できます。これにより、Configルールの集中管理と展開が可能になります。 今までは、組織全体にまたがる適合パックとConfigルールの展開は、組織のマスターアカウントのみが実施できました。しかし、マスターアカウントを一括請求にのみ使用するお客様も多数おられます。お客様がセキュリティ、監査、コンプライアンスのための専用アカウントを持っている場合、代わりにその専用アカウントを使って組織全体にわたるConfigの展開を管理したいと考えるでしょう。このようなご要望にお応えして、AWS Organizationsの非マスターアカウントからConfigルールと適合パックのデプロイができるようになりました。このAWS Config新機能を使用すると、これらのConfigリソースをAWS Organizations全体に展開し管理できる権限を委任する管理者アカウントを登録できます。 このブログ投稿では、委任された管理者アカウントにて、組織全体に適合パックを展開し、AWS Configルールと適合パックを管理する方法について示します。

Read More

CloudFormation で cfn-init に代えて State Manager を利用する方法とその利点

はじめに AWS CloudFormationを介してAmazon Elastic Cloud Compute (EC2) インスタンスをデプロイした後には、ソフトウェアのインストール、またはオペレーティングシステムの設定が必要になることがほとんどです。多くのAWSのお客様はCloudFormationのヘルパースクリプトの一つである cfn-init (2012年2月から利用可能)を使用していると思います。しかし、それ以後もAWSは、お客様のフィードバックに応じて多くの新機能とサービスをリリースしてきました。そのうちの一つはAWS Systems Managerです。このブログ記事では、AWS CloudFormationを介してデプロイされたAmazon EC2インスタンスに対して、AWS Systems Manager State Managerを使用してインスタンスを設定する、よりシンプルで堅牢な方法を紹介します。

Read More

File Gateway を使用して SQL Server バックアップを Amazon S3 に簡単に保存する

昨年公開したブログで、AWS Storage Gateway をセットアップして、File Gateway でクラウドベースの SMB 共有を使用して SQL Server バックアップを Amazon S3 に保存する方法を説明しました。 オンプレミスのバックアップコストが増加し、運用オーバーヘッドが増加しているお客様は、SQL Server バックアップを永続的かつ確実に AWS に保存するために、このソリューションを使っています。これにより、費用を節約し、オンプレミスのストレージインフラストラクチャを削減しながら、バックアップ操作を簡素化できます。 File Gateway は、ローカルキャッシュを使用して S3 バケットに保存されたデータへの SMB および NFS アクセスを提供し、データへ低レイテンシーでアクセスできるようにします。AWS は前回のブログ記事以来、 Storage Gateway の多くの機能をリリースし、耐障害性を高め、パフォーマンスを向上させ、機能を強化しました。このような機能には、VMware デプロイの高可用性、SMB 共有の監査ログ記録、パフォーマンスの向上、統合された CloudWatch アラーム、および S3 Intelligent-Tiering のサポートなどがあります。 この記事では、前回のブログを基に、File Gateway の設定、モニタリング、パフォーマンスに関するベストプラクティスについて説明します。また、さまざまな File Gateway 環境設定で実行した SQL Server バックアップテストの結果を示します。さらに、これらの結果から外挿して、独自の SQL Server 環境を計画する方法も示します。このブログを読むと、SQL Server バックアップワークロード用のスケーラブルで耐久性のあるソリューションをより適切に設計できるようになっていることでしょう。 File Gateway […]

Read More

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

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

Amazon EFS を使用して WordPress のパフォーマンスを最適化する

多くの組織は、単一ノードインストールを使用して WordPress のようなコンテンツ管理システム (CMS) を使用していますが、マルチノードインストールがパフォーマンスと可用性の面でメリットを提供するベストプラクティスであることから、これを使用することで恩恵を受けることができます。AWS Well-Architected フレームワークの信頼性の柱では、次の設計原則を推奨しています。すなわち、「水平方向にスケールしてシステム全体の可用性を高める: 1 つの大規模なリソースを複数の小規模なリソースに置き換えることで、単一の障害がシステム全体に与える影響を軽減します。リクエストを複数の小規模なリソースに分散させることで、共通の障害点を共有しないようにします」というものです。 このブログ投稿では、Amazon Elastic File System (Amazon EFS) を可用性の高い WordPress デプロイの共有コンテンツストアとして使用する方法について説明し、サイトのパフォーマンスを改善するための最適化のヒントを紹介します。 マルチノードの WordPress サイトを実行する 1 つのアプローチは、ファイルを 1 か所に保存し、ブートストラッププロセス中にこのデータをダウンロードすることです。これでも機能しますが、このオプションを使用すると、ウェブサイトの進化に合わせてコンテンツを常に同期することが難しくなります。Amazon EFS のような共有ファイルシステムを使用すると、複数のノードが同時に WordPress ファイルにアクセスできます。これにより、水平スケーリングとウェブサイトの更新のプロセスを大幅に簡略化できます。 ページをロードする時間を理解する Amazon EFS は、AWS クラウドサービスおよびオンプレミスリソースで使用するための、シンプルでスケーラブルで伸縮自在な完全マネージド型の NFS ファイルシステムを提供します。アプリケーションの運用を妨げることなく、オンデマンドでペタバイト単位にまで拡張できるように構築されており、ファイルを追加および削除すると自動的に拡大および縮小するため、成長に対応するためにキャパシティーをプロビジョニングしたり管理したりする必要はありません。Amazon EFS はリージョナルサービスであり、複数のアベイラビリティーゾーン内およびこれらにまたがってデータを保存し、高可用性と耐久性を実現しています。 ネットワーク化されたファイルシステムについては、クライアントとサーバー間のネットワーク通信に関連するオーバーヘッドがあります。シングルスレッドアプリケーションから小さなファイルを操作する場合、このオーバーヘッドも併せて大きくなります。多くの場合、マルチスレッド I/O およびより大きなファイルの I/O はパイプライン処理できるため、ネットワークのレイテンシーをより多くの操作で償却できます。 例えば、PHP ウェブサイトがホームページを生成するには、100 個の小さなファイルにアクセスする必要があるとします。これは、PHP ファイル、インクルード、モジュールなどです。PHP パーサーにページをロードするときに小さな 1 桁のミリ秒の低レイテンシーを導入すると、ユーザーがウェブサイトにアクセスするときに数百ミリ秒のさらなる遅延が発生します (100 ファイル X 数ミリ秒の遅延)。ウェブページのロードに対するユーザーの許容度はそれほど高くないため、これは重要です。 この図は、ページをロードするために実行する必要があるさまざまな手順を示しています。各ステップで追加のレイテンシーが発生します。私たちは、WordPress […]

Read More

AWS上でどのようにゼロトラストアーキテクチャを考えていくか

厳しい規制への対応やリスク回避を考慮事項として擁するお客様は、レガシーアプリケーションのリファクタリングや新しいアプリケーションのデプロイに際し、ゼロトラストアーキテクチャに関心を向けることがあります。このブログでは、お客様がお客様のアプリケーションを評価し、ゼロトラストの原則とAmazon Web Services (AWS)を利用して安全でスケーラブルなアーキテクチャを構築するための手助けを行います。 ゼロトラストとは? ゼロトラストセキュリティとは、アプリケーションのコンポーネントやマイクロサービスが互いに分離しており、どのコンポーネントやマイクロサービスも他のコンポーネントやマイクロサービスを信頼していないというモデルです。これは、あらゆるソースからの入力を潜在的に悪意のあるものとみなすように設計されたセキュリティの考え方です。基礎となる内部ネットワーク・ファブリックを信頼しないことから始まり、さらにすべてのマイクロサービスにおける入力と出力の評価におよびます。加えて、個々のコンポーネント、マイクロサービス、またはアイデンティティの侵害から保護するために、多層防御アプローチを設計することも含まれます。 (訳者注:ゼロトラストは特定の製品やソリューションを指すものではなく多層的なセキュリティ手法を踏まえた概念として、現在アメリカ国立技術標準研究所(NIST)においても、SP800-207(本blog執筆時点においてはドラフト)として定義化が進められています。) 伝統的なネットワークセキュリティの設計は、セキュリティの境界に依拠します。境界内のすべてのものは信頼され、境界外のものは信頼できないものとみなされます。ゼロトラストネットワークは、ビジネスデータや機密リソースへの意図しないアクセスのリスクを低減するために、リアルタイムですべてのアクションとリソースを評価します。 ゼロトラストの原則を用いたAWS上での設計 ゼロトラストアーキテクチャをよりよく理解するために、脅威モデリングにより、従来のアーキテクチャやクラウドネイティブアーキテクチャとを比較してみましょう。脅威モデリングは、ユーザーはすべての潜在的な攻撃の可能性を評価してリスクを定義し、管理策を決定するための試みです。脅威モデルの一つであるSTRIDEでは、以下のようなカテゴリの脅威を特定しています。 ユーザーIDのなりすまし(Spoofing) データの改ざん(Tempering) ソースの否認(Repudiation) 情報漏洩(Information Disclosure) サービスの拒否(Denial of Service) 特権の昇格(Elevation of Privilege) AWSのベストプラクティスアーキテクチャ AWSでは、AWS上でWell-Architectedなアプリケーションを設計するための基礎となるツールを提供しています。AWS Well-Architected Frameworkは、AWSのベストプラクティスとワークロードを比較し、安定的かつ効率的なシステムを構築するためのガイダンスを得るための戦略を紹介しています。Well-Architected Frameworkには、セキュリティを含む5つの明確な柱が含まれています。このフレームワークを基に、ゼロトラストをAWSアーキテクチャに適用した例としてWebアプリケーションを考えてみましょう。 図1: Webサイトホスティングの例 表現されているアーキテクチャは、セキュリティを考慮したWell architectedの一例です。システムは、以下のサービスを活用して一般的な攻撃ベクターから保護されています。 Elastic Load Balancing (ELB)/Application Load Balancer (ALB)による負荷分散により、複数のアベイラビリティゾーンとAmazon Elastic Compute Cloud (Amazon EC2) Auto Scalingグループに負荷を分散し、サービスの冗長化と疎結合を実現します。 AWSのSecurity Groupを利用した仮想ファイアウォールでは、インスタンスにセキュリティを移動させ、Webサーバとアプリケーションサーバの両方にステートフルなホストレベルのファイアウォールを提供します。 Amazon Route 53を利用したDNS(Domain Name System)はDNSサービスを提供し、ドメイン管理を簡素化します。 Amazon CloudFrontによるエッジキャッシングにより、顧客へのレイテンシが減少します。  AWS Web […]

Read More

S3 バケット間で既存のオブジェクトをレプリケートする

 お客様は、そのビジネス要件またはエンタープライズポリシー上、既存の Amazon S3 オブジェクトの追加コピーを求められることがよくあります。Amazon S3 レプリケーションは、新しくアップロードされたオブジェクトを S3 バケット間でレプリケートするために広く使われていますが、S3 バケット間で既存のオブジェクトを多数レプリケートする最も簡単な方法をまだご存知ではないお客様が数多くいらっしゃいます。この記事では、Amazon S3 レプリケーションを使用して既存のオブジェクトのクロスリージョンレプリケーションをトリガーする方法を説明します。 Amazon S3 レプリケーションは、オブジェクトをある Amazon S3 バケットから別のバケットにコピーするための、低コストで柔軟なマネージド型ソリューションです。Amazon S3 レプリケーションでは、Amazon S3 Cross-Region Replication (CRR) を使って、異なる AWS リージョンをまたいで S3 オブジェクトを自動的にレプリケートするルールを設定できます。または、Amazon S3 Same-Region Replication (SRR) を使用して、同じ AWS リージョン内のバケット間でオブジェクトをレプリケートするルールを設定できます。 お客様は、AWS サポートに連絡してこの機能をソースバケットに追加することにより、同じ AWS リージョン内または異なる AWS リージョン間の別のバケットに既存のオブジェクトをコピーできます。ソースバケットで既存のオブジェクトのレプリケーションのサポートを有効にすると、お客様は、新しくアップロードされたオブジェクトに加えて、既存のすべてのオブジェクトに対して S3 レプリケーションを使用できるようになります。レプリケーションプロセスが完了すると、お客様はすべてのオブジェクトが含まれる 2 つのバケットを持つことができ、新しくアップロードされたオブジェクトは宛先バケットにレプリケートされます。 既存のオブジェクトのレプリケーションは、既存の S3 レプリケーション機能を拡張したものであり、同じ機能がすべて含まれます。これには、メタデータ (オブジェクトの作成日時など) を保持しながらオブジェクトをレプリケートしたり、オブジェクトを異なるストレージクラスにレプリケートしたり、異なる所有権でオブジェクトのコピーを保持したりする機能が含まれます。Amazon S3 Replication Time Control […]

Read More

Amazon S3 暗号化を S3 マネージドから AWS KMS に変更する

 Amazon Simple Storage Service (Amazon S3) を使用するお客様は、サーバー側のオブジェクト暗号化 (SSE) に S3 マネージド暗号化キー (SSE-S3) を利用することがよくあります。多くのお客様の場合、SSE-S3 を使用することにより、データを保護するためのセキュリティ要件を満たしています。一方で、一部のお客様の場合、最初は SSE-S3 が要件を満たしていたはずが、時間の経過とともに要件が変更された可能性があります。たとえば、顧客が別の標準セットに対する準拠を必要とする新しいビジネスを拡張している場合があります。別の例として、分析を使用するお客様の多くは、機密データ以外を使用して概念実証を実行することから始めます。分析プラットフォームから価値を引き出すにつれて、さまざまなデータソースからさらに多くのデータを追加し、このデータ集約によって分類が変更されることがよくあります。暗号化キーにアクセスできるユーザーをより詳細に制御できるようにすることで、暗号化キーを処理するための追加制御を実装しなければならない場合があります。また、ログ記録と監査を分離したり、ストレージと暗号化を別々に認証するための PCI-DSS コンプライアンス要件をサポートしたりすることもできます。AWS マネージドキーとカスタマーマネージドキーの違いについては、このブログ記事をご覧ください。 より強力なセキュリティとコンプライアンスの要件を満たすために、一部のお客様は、暗号化モデルを SSE-S3 から SSE-KMS に変更したいと思う場合があります。SSE-KMS は、暗号化に AWS Key Management Service (AWS KMS) を使用します。そうすることで、許容が大きすぎるポリシーからの保護など、いくつかの追加利点を提供できます。たとえば、個々のユーザーやロールではなく、過度に広いデータへのアクセスを許可するバケットポリシーを追加します。KMS キーを使用して暗号化を実装することにより、リソースにアクセスする者は、Amazon S3 ポリシーアクセスと、データを復号化するための KMS キーへのアクセスを必要とします。カスタマーマネージドキーで AWS KMS を使用することを選択したお客様には、追加のコンプライアンス要件をサポートできる次の利点もご利用いただけます。 キーの所有権を維持してアクセスを取り消し、データへのアクセスを不可能にします。 独自のコンプライアンス要件に合わせて、AWS KMS コンソールから監査可能なカスタマーマネージド CMK を作成、ローテーション、無効化することができます。 AWS KMS のセキュリティ管理は、暗号化関連のコンプライアンス要件を満たすのに役立ちます。 この記事では、4 つのことを説明します。 暗号化に KMS キーを使用するよう、バケットにデフォルトの暗号化を設定する方法。 […]

Read More