Amazon Web Services ブログ

Category: General

インターリージョンVPCピアリングのサポートのお知らせ

Amazon EC2にて、他のAWSリージョンを跨いでVirtual Private Cloud (VPC)ピアリングの確立ができるようになりました。(※2018/02/21 追記、新たに9つのリージョンが追加されました 詳細はこちら) インターリージョンVPCピアリングでは、Gateway、VPNコネクション、ネットワークアプライアンスなどを使う事なく、別なリージョンで稼働しているEC2インスタンス、RDSデータベース、LambdaファンクションなどのVPCリソースに対してPrivate IPアドレスにて通信が可能です。 インターリージョンVPCピアリングは、リージョン間のリソース共有や地理的な冗長性を得るためのデータレプリケーションに関して、シンプルかつコスト効率の良い方法となります。インターリージョンVPCピアリングはVPCと同様な水平方向のスケール、冗長、高可用性テクノロジーにより構築されており、単一障害点や帯域のボトルネック無しに暗号化します。インターリージョンVPCピアリングのトラフィックは常にグローバルAWSバックボーンにとどまり、パブリックなインターネットを横断することは無く、一般的な悪用であったりDDoS攻撃のような脅威を減らすことができます。 インターリージョンVPCピアリングコネクションによって転送されたデータのコストは、インターリージョン間の通常のデータ転送費用となります。 インターリージョンVPCピアリングはAWSの米国東部(バージニア北部)、米国東部(オハイオ)、米国西部(オレゴン)、欧州(アイルランド)にて利用可能です。他のリージョンについても、まもなく予定しています。 さらなる情報については、Amazon VPC Peeringのドキュメントをご参照下さい。   翻訳はSA益子が担当しました。 原文:こちら

Read More

AWS Systems Manager – クラウドとハイブリッドリソースの管理用の統合されたインターフェース

AWS Systems ManagerはクラウドとハイブリッドIT環境を管理する新しい方法です。AWS Systems Managerは、リソースとアプリケーション管理を簡素化し、運用の問題を検知して解決する時間を短くし、セキュアに大規模なインフラを運用および管理することを容易にします。こちらのサービスは機能のすべてが含まれています。リソースに跨ったオペレーションを可能にするために、Amazon EC2 Systems Manager (SSM)のような製品の機能を使ってグルーピングや可視化、問題への対処することができます。 先にお伝えしように、こちらのサービスには多くのパワフルな機能があります。それらのすべてについて深く説明しませんが、コンソールへアクセスして、簡単にいくつかのツールで使い始めてみることができます。

Read More

AWS DeepLens ディープラーニングと新しいビデオカメラによるハンズオン

過去一度か二度お伝えしましたとおり、私は生涯学習を強く信じる人です。技術の変化は今までよりも早くやってきており、あなたの現在のスキルを追従させるためにあなたも同じことをする必要があります。 私の経歴のほとんどにおいて、人工知能は学術的なトピックであり、実用的なアプリケーションや実世界への展開は”もう間もなく”というものでした。私はコンピュータービジョンやディープラーニングといった機械学習の実用的なアプリケーションの数をもって、人工知能はもうやってきたということができると思いますし、今はハンズオンを開始し、あなたのスキルを磨く時だと思います。また、どちらもより最新で少ない時間で生まれた一方、IoTとサーバレスコンピューティングはここにあり、あなたのリストにあるべきだと言えます。   New AWS DeepLens 今日(2017/11/29 PST)、AWS DeepLensという、ディープラーニングモデルをデバイスで直接で実行する新しいビデオカメラが出たことをお伝えします。あなたはこれを使ってAI、IoT、サーバレスコンピューティングのハンズオンを体験し、クールなアプリを構築できます。AWS DeepLensは最先端のハードウェアと洗練されたソフトウェアをあわせもち、あなたはAWS Greengrass、AWS Lambda、そしてそのほかのAWS AIやアプリ上のインフラを活用できます。

Read More

Amazon GuardDuty – 継続したセキュリティ監視と脅威の検知

ITインフラ(AWS アカウントでしたり、セキュリティクレデンシャル、またAWS上で稼働する仮想マシン、アプリケーション等)への脅威は日々形を変え、襲いかかります。オンラインの世界は陰険な場で、ITインフラを安全かつ健全に保つために、ツールでしたり、経験知識、知見をお持ちだと思います。 Amazon GuardDuty は正にそのためにデザインされました。公開データ、AWS 上で生成されるデータといった多数のデータをもとに、機械学習を行います。GuradDury はそれらをもとに、見落としがちな傾向、パターン、異常を追跡し、何億ものイベントの解析を行います。GuardDuty は数クリックで利用開始でき、数分でFindings(イベント)が表示されます。 動作方法 GuardDutyは 脅威情報を含む複数のデータストリームから、悪意のあるIPアドレス、デバイスドメインを認識し、あなたのAWSアカウントで悪意のある、もしくは不正な行動があるか特定するために学習します。VPC Flow Logs、CloudTrail のイベントログ、DNS ログを集め組み合わせることにより、GuardDuty は非常に多くのことなったタイプの危険性のある、悪意のある行動を検知します。その中には、既知の脆弱性でしたりポートスキャン、通常とは異なるロケーションからのアクセス等も含まれます。AWS の観点では、不正なデプロイメントでしたり、CloudTrail の異常なアクティビティ、API アクセスパターン、複数のサービスリミットを越えようとするアクセス等、疑わしいAWSアカウントアクティビティの検知を行います。それに加え、GuardDuty は悪意のあるエンティティ、サービス、データを抜き出そうとする行動、暗号侵害を試みるインスタンスと接続する、感染を受けたインスタンスも検知します。 GuardDuty はAWS上で提供され、パフォーマンス、信頼性の観点で既存サービスへの影響はありません。エージェント、センサー、ネットワークアプリケーションも必要ありません。このクリーンで既存に変更を加えない点は、みなさんのセキュリティチームへのアピールにもなりますし、すべてのAWSアカウントでGuardDutyを有効にする後押しになります。 Findings(検知されたアクティビティ) は3つのレベル(低・中・高)で通知され、詳細情報、復旧アクションの提案も合わせて通知されます。また、FindingはCloudwatch Eventsとの連携が可能で、ある特定の問題に関してはLambda ファンクションと連携し、復旧アクションを取ることが可能です。またこの連携機能により、GurdDuty のFinding 情報を、Splunk、Sumologic、 PagerDuty 等のイベント管理システムと簡単に連携が可能となりますし、JIRA、ServiceNowといったワークフローシステムとの連携、Slack連携も可能になります。 GuardDutyのはじめ方 では、簡単にGuardDutyの始め方をご説明します。はじめにGuardDuty Consoleを開き、開始をクリックします。 その後、GuardDuty を有効にするために確認を行います。そうすることで、GuardDuty のログ解析に必要なサービスリンク ロールが準備され、”GurdDuty の有効化”をクリックすると準備が整います。 アカウントによってはFindingがあまり無いアカウントもあるかもしれません。General Setting から、Generate sample findingsをクリックすると、サンプルのFindingsが確認できます。 あるFindingを選択すると、詳細が確認できます。 虫眼鏡アイコンから拡大し、関連リソース、アクション、その他値のフィルターを作成することが出来ます。下記のようにインスタンスに紐づくすべてのFindingsをフィルターすることも可能です。 信頼IP、また悪意のあるIPリストを追加することで、ご自身の環境にあったGuardDuty環境にカスタマイズもできます。 管理者アカウントでGuadDutyを有効にし、その他のアカウトを参加アカウントとして招待します。 それらアカウントが参加を承認すると、それらアカウントのFindingsが管理者アカウントと共有されます。 時間の関係もありGuardDuty の多くすべてをお話できないため、是非30日間のトライアルを是非ご利用下さい。トライアル終了後はVPC Flow Logs、CloudTrail ログ、DNS ログに対し解析を行った量に応じ課金されます。 利用可能リージョン […]

Read More

2018年度のAPN プレミアパートナー様が発表され、国内8社目の新たなプレミアパートナーとしてCTC様が紹介されました。

こんにちは、Partner SA 相澤です。 いよいよre:Invent 2017が始まりましたが、28日のGlobal Partner Summit 2017にて APN Premier Consulting Partnerが発表されました。 本年度の、新しいプレミアパートナーとして日本からはCTC様が紹介されました。 おめでとうございます! 今まで同様に非常に厳しいクライテリアを満たしたパートナー様のみの選出なっております。 また、既存のプレミアパートナー様も紹介され、日本からは7社のパートナー様が、昨年度から引き続きプレミアパートナー様として紹介されました。 Classmethod様、Cloudpack様、NRI様、ServerWorks様、TIS様、NEC様、 NTT Data様 おめでとうござます!   これでグローバルでのプレミアパートナー様は67社となり、そのうち8社が日本の企業です。 引き続き、日本市場へのAWS展開に向けて宜しくお願い致します! https://aws.amazon.com/jp/solutions/solution-providers-japan/premier-consulting/ ———————- エコシステムソリューション部 パートナーソリューションアーキテクト 相澤 恵奏  

Read More

AWS PrivateLinkのアップデート – お客様のアプリケーション&サービス向けのVPCエンドポイント

今月はじめに、私の同僚であるColm MacCárthaighがAWS PrivateLinkに関する記事でVPCエンドポイントを利用したAmazon Kinesis StreamsやAWS Service Catalog、AWS Systems Manager、そしてEC2やELBのAPIへのアクセス方法についてご紹介しました。VPCエンドポイント (1つまたは複数のElastic Network InterfacesまたはENIで表される) はVPC内に存在し、VPCのサブネットからIPアドレスを取得します。これらのAWSサービスにアクセスするためにはインターネットゲートウェイやNATゲートウェイは必要ありません。このモデルは明確で理解しやすく、言うまでもなくセキュアでスケーラブルです!   プライベート接続用のエンドポイント 本日、VPCエンドポイントを利用して自分のサービスにアクセスしたり、他のユーザからサービスにアクセスいただけるようにAWS PrivateLinkを拡張しました。AWSサービス向けのPrivateLinkをローンチする以前から、たくさんのお客様からこの機能に関するご要望をいただいており、おそらく非常に人気のある機能になると考えています。例えば、あるお客様は単一のマイクロサービス(詳細はMicroservices on AWSを参照)を提供する数百のVPCを作成する計画があるとお話いただいたことがあります。 各企業は他のAWSのお客様にプライベート接続を介したサービスを開発・提供することができるようになりました。Network Load Balancerを利用したTCPトラフィックによるサービスを作成し、直接またはAWS Marketplaceでサービスを提供することができます。利用者は新しいサブスクリプションリクエストの通知を受け取り、そのサービスの利用について許可または拒否をすることができます。2018年は強力で活気のあるサービスプロバイダーのエコシステムを構築するために、この機能が利用されていくことでしょう。 サービスの提供者と利用者は異なるVPCまたはAWSアカウントを利用し、エンドポイントを介した一元的な通信がAmazonのプライベートネットワークを経由します。サービス利用者はVPC間のIPの重複やVPCピアリング、ゲートウェイの利用について心配する必要はありません。また、AWS Direct Connectを利用することで、オンプレミスやその他で稼働しているサービスから、AWS上のクラウドベースのアプリケーションへのアクセスを実現することができます。   サービスの提供および利用 VPC API、VPC CLI、またはAWSマネージメントコンソールからすべてのセットアップを行うことが可能です。それでは、コンソールからどのようにサービスの提供または利用を行うのかご紹介しましょう。今回はデモ用に単一のAWSにアカウントを利用します。 それでは、サービスの提供について見ていきましょう。サービスはNetwork Load Balancerの背後で実行され、かつTCPを利用する必要があります。EC2インスタンス、ECSコンテナ、またはオンプレミス(NLBのIPターゲットによる設定)を利用し、予想される需要に応じてスケールできるようにします。低レイテンシまたは対障害性を確保するために、リージョン内のそれぞれのAZのNLBをターゲットとすることをおすすめします。 VPCコンソールを開き、[Endpoint Services]を選択し、[Create Endpoint Service]をクリックします。 NLBを選択します。今回の例では一つしか表示されませんが、実際には2つ以上選択し、ラウンドロビン方式で利用者にマッピングさせることも可能です。[Acceptance requred]をクリックし、リクエストベースでのエンドポイントへのアクセスを提供します。 [Create service]をクリックすれば、サービスはすぐに準備完了となります。 もし、AWS Marketplaceでサービスを提供する場合、先に進んでリストを作成します。このブログ記事ではサービスの提供者と利用者が同じため、手順はスキップします。”Service Name”を次の手順で利用するためにコピーします。 VPCダッシュボードに戻り、[Endpoints]を選択し、[Create endpoint]をクリックします。[Find service by name]を選択し、先ほどコピーした”Service Name”を貼り付け、[Verify]をクリックし次に進みます。そしてAZ、サブネット、セキュリティグループをそれぞれ選択し、[Create endpoint]をクリックします。 Endpoint Serviceを作成したときに”Acceptance required”にチェックを入れたため、この接続は”pending acceptance”状態となっています。 […]

Read More

DNS を使って AWS Certificate Manager の検証を簡単に

Secure Sockets Layer/Transport Layer Security (SSL/TLS) 証明書はインターネット越しのネットワーク通信を安全にし、Web サイトの身元を確認するのに使われています。アマゾンは証明書を発行する前に、そのドメイン名をあなたが管理している事を検証しなければなりません。今回、あなたが管理しているドメイン名について SSL/TLS 証明書の発行リクエストを AWS Certificate Manager (ACM) にした際に、Domain Name System (DNS) 検証を使えるようになりました。これまで、ACM はEメール検証のみをサポートしており、ドメインの所有者は証明書発行リクエストのつどEメール受け取り、確認して承認する必要がありました。 DNS 検証では、そのドメインをあなたが管理している事を証明するために CNAME レコード を DNS 設定に書き込む必要があります。CNAME レコードの設定後は、DNS レコードが変更されない限り、有効期限切れ前には ACM は自動で DNS 検証した証明書を更新します。Amazon Route 53 で DNS を管理している場合は、ドメインの検証がより簡単になるよう ACM が DNS 設定の更新も行うことができます。このブログ記事では、DNS 検証を使って Web サイトの証明書リクエストを行う方法を紹介します。同等のステップを AWS CLI、AWS API、AWS SDK を使って行うには、AWS Certificate Manager in the AWS […]

Read More

【変更版】11 月の AWS Black Belt オンラインセミナーのご案内

※11/20追記 直前のお知らせとなり申し訳ありません。11/21(火) 12:00-13:00に開催を予定しておりました「AWS上の位置情報」ですが、講師の都合により延期となりました。事前登録いただいておりました皆様、申し訳ございませんでした。また、改めて開催予定日を案内させていただきます。   こんにちは。ソリューションアーキテクトの岡本です。AWS Black Belt オンラインセミナー11月の配信についてご案内させて頂きます。初めてご紹介するNLB (Network Load Balancer) を中心としたELBのセッションをはじめ、今月も様々なテーマを取り扱います。 また今年もAWS re:Inventの開催期間中に現地からの生中継で最新アップデートをお伝えする回を予定しておりますので、こちらもぜひご登録いただければと思います。                   11月の開催予定 サービスカット 11/1(水) 18:00-19:00 Amazon EMR 11/15(水) 18:00-19:00 ELB Update – Network Load Balancer(NLB)と関連サービス 11/22(水) 18:00-19:00 AWS WAF – OWASP Top10脆弱性緩和策 – ソリューションカット 11/9(木) 12:00-13:00 Amazon Pinpoint で始めるモバイルアプリのグロースハック  ※ 通常の開催曜日と異なりますのでご注意ください 12/1(金) 12:00-13:00 […]

Read More

詳解: Amazon ECSのタスクネットワーク

この記事はECSのSr. Software Dev EngineerのAnirudh Aithalの寄稿です。 2017年11月14日に、AWSはコンテナにElastic Network InterfaceをアタッチできるようにするAmazon ECSのTask Networkingを発表しました。 この記事では、ECSが管理するインスタンス(コンテナインスタンスと呼ばれます)上でContainer Networking Interfaceプラグインを使って、この新しいコンテナネイティブなawsvpcネットワークモードがどのように実装されているかを詳しくご紹介したいと思います。 こちらはAmazon ECSでタスクネットワークが動作するかにdeep diveしたものです。もし自身のコンテナ化したアプリケーションでどうやってタスクネットワークを使い始めれば良いかについて学びたい時には、Amazon ECSコンテナにCloud Native Networkingが登場をご覧下さい。Cloud Native Computing Foundation (CNCF)がContainer Networking Interface (CNI)プロジェクトをホストしており、Linuxコンテナでネットワークインターフェースを設定するためのプラグインを書くための仕様やライブラリが含まれています。AWSのクラウドネイティブコンピューティングについての詳細は、Adrian CockcroftのCloud Native Computingについての投稿をご覧下さい。 コンテナインスタンスのセットアップ コンテナインスタンス上でのタスクネットワーク有効化の詳細をご説明する前に、ECSの典型的なインスタンスがどのようになっているかを見てみましょう。 上の図は典型的なコンテナインスタンスを示しています。ECS agentは自身もコンテナとして実行されているのですが、以下のような責任を負っています: EC2インスタンスをECSのバックエンドに登録 コンテナインスタンスに対してECSバックエンドが発生させたタスク状態の変化を、正しく適応 Dockerデーモンと会話しながら、コンテナの作成、開始、停止、監視 コンテナの状態とタスクの状態の遷移をECSバックエンドにリレー ECS agentはその管理下のコンテナのスーパーバイザーの様に動作するので、Dockerデーモン(Dockerのデフォルトネットワークモードで設定されたコンテナ用)、又はCNIプラグイン達(ネットワークモードがawsvpcで設定されたタスク内のコンテナ)のための、ネットワーク設定をする難しさをオフロードしてくれます。 いずれの場合にも、コンテナのネットワークスタックは、ネットワークのnamespaceを通じて設定されます。ip-netns(8)のマニュアルによると「ネットワークnamespaceは論理的なネットワークスタックのコピーで、自身のルーティング、ファイアウォールルール、ネットワークデバイスを持っています。」 とあります。ネットワークnamespaceの構成によって、ホスト上で動いているプロセスやコンテナ間でのネットワークスタックの隔離を可能としてくれます。 ネットワークnamespaceとCNIプラグイン CNIプラグインとは、CNI仕様を満たしコンテナのネットワーク接続性の設定を行う実行ファイル群です。CNIプロジェクトではプラグインの仕様を定義し、プラグインが利用するライブラリを提供することで、一貫していて信頼でき、かつ簡素なプラグイン用のインタフェースを提供してくれます。 コンテナやネットワークnamespaceを指定してプラグインを呼び出す時に、ADDコマンドでコンテナにネットワークインターフェースを追加したり、DELコマンドでそれを落としたりします。例えばリファレンスのBridgeプラグインは、ホストネットワークnamespaceの中にいるブリッジに対してホスト上の全てのコンテナを追加します。 このプラグインのモデルはECS agentの「コンテナのライフサイクルへの最小限の介入」というモデルと相性が良く、agentはコンテナのネットワーク設定の詳細について考慮する必要がなくなります。また拡張性の高いモデルなので、将来必要になった時には、agentが異なるプラグイン群を利用できるようにスイッチさせることもできます。最後に、これらプラグインは必要な時に呼び出されるだけなので、その死活監視をECS agentがする必要はありません。 ECS agentからCNIプラグインを呼び出す ECSがElastic Network Interfaceをインスタンスにアタッチし、agentに対しそのElastic Network Interfaceをタスク内のコンテナに対してプロビジョンするようにメッセージを送った時には、(任意のネットワークデバイスを使う) そのElastic […]

Read More

Amazon ECSコンテナにCloud Native Networkingが登場

この記事はECSのSr. Software Dev EngineerのAnirudh Aithalの寄稿です。 2017年11月14日に、AWSはAmazon ECSのTask Networkingを発表しました。これによって、Elastic Network Interfaceを使ったAmazon EC2のネットワーク機能をタスクに持ち込むことができるようになります。 Elastic Network InterfaceはVPC内のインスタンスにアタッチすることができる仮想的なネットワークインタフェースです。EC2の仮想マシンを起動する時には、インスタンスにネットワークの機能を提供するために自動的に1つのElastic Network Interfaceがプロビジョンされます。 タスクは実行されるコンテナの論理的なグループです。これまでは、Amazon ECSで実行されるタスクはそれが動くEC2ホストのElastic Network Interfaceを共有していました。これからは、新しいawsvpcというネットワークモードを使うことで、Elastic Network Interfaceが直接タスクにアタッチされます。 これによってネットワークの設定を簡略化することができ、VPCが持っているネットワークの全機能、隔離性、そしてセキュリティの制御を各コンテナにEC2インスタンスと同様のレベルで利用することができます。 この記事では、awsvpcモードがどのように動作し、ECSのタスクでどのようにElastic Network Interfaceを使い始めることができるかをご紹介します。 背景: EC2のElastic Network Interface VPC内にEC2インスタンスを起動する時には、各インスタンスが互いに通信できるようにするために、追加のオーバーレイネットワークを設定する必要はありません。標準で、VPCのルーティングテーブルがインスタンスや他のエンドポイント間での通信をシームレスに実現してくれます。これは、Elastic Network Interfaceと呼ばれるVPC内の仮想的なネットワーク・インタフェースによって可能となっています。全ての起動されるEC2インスタンスは自動的に1つのElastic Network Interface(プライマリネットワークインタフェース)がアサインされます。サブネット、セキュリティグループといった全てのネットワークパラメータは、このプライマリネットワークインタフェースの属性として扱われます。 さらに、各Elastic Network Interfaceは作成時にVPCによってIPv4アドレス(プライマリIPv4アドレス)が割当られます。このプライマリアドレスはユニークでVPC内でルーティング可能なものです。これによって、VPCは実際はフラットなネットワークとなり、ネットワークトポロジを簡潔なものとしてくれます。 Elastic Network InterfaceはVPC上で多様なエンドポイントとの接続を実現するための基本的なビルディングブロックとみなすことができ、そのうえでより高レベルな抽象レイヤを構築することができます。これによってElastic Network Interfacdeは以下の機能を利用することが可能となっています: VPCネイティブなIPv4アドレスとルーティング (VPC上でのインスタンス間や他のエンドポイントとの間) ネットワークトラフィックの隔離 ACLとファイアウォールルール(セキュリティグループ)を使ったネットワークポリシーの強制 (サブネットのCIDRを通じた)IPv4アドレスレンジの強制 なぜawsvpcを使うのか? 以前はECSはDockerが提供する標準のネットワークの挙動が提供するネットワーク機能に依存した形でコンテナ向けのネットワークスタックを構成していました。デフォルトのBridgeネットワークモードでは、インスタンス上のコンテナ達はdocker0ブリッジを使って互いにつながっています。インスタンス外のエンドポイントと通信する時には、コンテナはこのブリッジを利用し、それが実行されているインスタンスのプライマリネットワークインタフェースを使います。コンテナは、ファイアウォールルール(セキュリティグループ)やIPアドレスは、そのプライマリElastic Network Interfaceのネットワーク属性を共有しまた依存しています。 これは、Dockerによって割当られたIPアドレス(ローカルスコープのアドレスプールから割当られます)を使ってもこれらのコンテナに到達できないことと、細かいNetwork ACLやファイアウォールルールを強制できないことを意味します。代わりに、VPCからはインスタンスのプライマリElastic Network […]

Read More