Amazon Web Services ブログ

Category: Amazon EC2 Container Service*

プロセッサの投機的実行 – オペレーティングシステムの更新

モダンコンピュータプロセッサ上で投機的実行によるサイドチャネル分析の調査が新しく公開されたのを受け、AWS は AWS Security Bulletin(セキュリティ情報)AWS-2018-013 を先日公開しました。このセキュリティ情報では、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 の3つのセキュリティ勧告に触れています。これらの勧告は Google Project Zero の調査に基づいたもので、Google Project Zero の発表はモダンコンピュータプロセッサ上でのサイドチャネル分析の新しい方法を発見したというものでした。これらの方法は、基礎的な技術、具体的には投機的実行に着目したもので、投機的実行は多くのベンダーのプロセッサに用いられています。そのため研究結果の対象となる範囲は幅広く、その範囲はハイパーバイザーからオペレーティングシステム、さらには Web ブラウザ、携帯電話からクラウドを構成するデータセンター内のサーバにまで及びます。   EC2 インスタンスの分離   Amazon EC2 のすべてのインスタンスは、上述の CVE に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 大多数の EC2 ワークロードに有意なパフォーマンスの影響は見られていません。   オペレーティングシステムへのパッチ   現代のオペレーティングシステムには、「ユーザー空間」プロセスからのカーネル分離、それぞれのプロセスの分離などの、いくつかのタイプのプロセス分離があります。影響を受けうるプロセッサ上でオペレーティングシステムが実行されている環境では、いかなる設定においても、公開された 3 つの問題すべてがプロセス分離に影響を与える可能性があります。ハイパーバイザで実装されている保護は、オペレーティングシステム内のプロセスレベルの分離にまで拡張されないため、リスクを軽減するためにオペレーティングシステムパッチが必要です。 準仮想化(PV)インスタンスでは、CVE-2017-5754 のプロセス間の問題に対処するためのオペレーティングシステムレベルの保護は無いことに注意してください。PV インスタンスは、前述のようにインスタンス間の問題について AWS ハイパーバイザーによって保護されます。しかしながら、PV インスタンスにおけるプロセスの分離(信頼できないデータ処理やコードの実行、ユーザのホスト)にご懸念をお持ちでしたら、長期的に見てセキュリティの恩恵を受けるため、HVM インスタンスタイプへの変更を強くお勧めします。PVとHVMの相違点(およびインスタンスアップグレードパスのドキュメント)の詳細については、以下の URL を参照してください。 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html インスタンスのオペレーティングシステムにパッチを適用することで、同じインスタンス内で動作するソフトウェアを分離し、CVE-2017-5754 のプロセス間の問題を緩和することを強く推奨します。以下のオペレーティングシステムのパッチの詳細を記載します。 Amazon Linux & […]

Read More

2018年2月のAWS Black Belt オンラインセミナーのご案内

こんにちは。ソリューションアーキテクトの有岡です。2018年2月のAWS Black Belt オンラインセミナーの配信についてご案内をさせて頂きます。 re:invent 2017の振り返りを終え、2018年2月のBlackBeltセミナーでは、ソリューションカットとしてAWS上での位置情報と動画配信ソリューション、Amazonのコンテナサービスをご紹介します。 サービスカットでは、クラウド型仮想デスクトップサービスのAmazon Workspaces、同じくBIツールのAmazon QuickSight、AWS Lambdaをエッジロケーションで活用する方法、エンタープライズのお客様でお使いになるケースの多いAWS Organizationsなど、盛り沢山でお送りします。   2月の開催予定 ソリューションカット 2月6日(火) 12:00~13:00 AWS における位置情報 2月13日(火) 12:00~13:00 動画配信 on AWS 2月20日(火) 12:00~13:00 Amazon Container Services サービスカット 2月7日(水) 18:00~19:00 Amazon Workspaces 2月14日(水) 18:00~19:00 AWS Organizations 2月21日(水) 18:00~19:00 AWS Lambda @ Edge 2月28日(水) 18:00~19:00 Amazon QuickSight お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同、みなさまのご参加をお待ちしております。    

Read More

プロセッサの投機的実行に関する調査の公開について

【日本語訳】日本時間 2018年02月14日19:30 関連する CVE: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 日本時間 2018年02月06日09:30 以下は本件に関するアップデートです。 Amazon Linux 用の更新されたカーネルは、Amazon Linux のリポジトリにて入手できます。2018年1月13日以降にデフォルトの Amazon Linux 設定で起動された EC2 インスタンスには自動的に最新のパッケージが含まれています。 最新のパッケージでは、 CVE-2017-5715 に対処するための安定版オープンソース Linux セキュリティの改善がカーネル内に組み込まれています。また 以前取り込まれた CVE-2017-5754 に対処するカーネルページテーブルアイソレーション(KPTI)にもとづいて作成されています。インスタンス内の CVE-2017-5715 のプロセスープロセス間の問題と CVE-2017-5754 のプロセスーカーネル間の問題を効果的に軽減するには、最新の Amazon Linux カーネルまたは AMI にアップグレードする必要があります。詳細は「プロセッサの投機的実行 – オペレーティングシステムの更新」を参照してください。 para-virtualized(PV)インスタンスについては、以下の「PV インスタンスガイダンス」の情報を参照してください。   Amazon EC2   Amazon EC2 のすべてのインスタンスは、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 […]

Read More

kopsを使ってKubernetesクラスタをAWS上で構成

この記事では、KubernetesクラスタをAWS上で構成し運用するツールの1つであるkopsを利用すると、簡単にKubernetesを始められることをご紹介します。なお最新情報は、GitHubで公開しているAWS Workshop for Kubernetesをご覧頂き、さらに構築したクラスタを使って様々なワークショップをご自身の手で試して頂くことをお勧めします。 kopsについて Kubernetesのトップレベルプロジェクトで、Kubernetesのクラスタを構成し運用するためのツールです。また、クラスタのローリングアップデートや、アドオンもサポートしています。必要に応じて、AWS CloudFormationやTerraformのテンプレートを出力することもできるので、それを基準にカスタムして行くということも可能です。 kopsをインストール kopsは2017年12月26日時点では、macOS、Linux、Windows 10 Linux Subsystemで利用可能です。この記事ではmacOSを利用していきます。Homebrewが対応しているので以下のコマンドでインストールするのが最も簡単です: $ brew update && brew install kops SSH鍵の生成 kopsはクラスタ作成の際にSSHの公開鍵を利用します。デフォルトの配置場所は~/.ssh/id_rsa.pubとなります。ssh-keygenコマンドを利用して作成しておきます。 $ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (~/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in ~/.ssh/id_rsa Your […]

Read More

AWS CodePipelineとAmazon ECSを使って継続的デリバリパイプラインを設定する

この記事はAWS Senior Technical EvangelistのAbby Fullerの投稿です。 2017年12月12日に、AWSはAWS CodePipelineのターゲットとしてAmazon Elastic Container Service (ECS)をAWS Fargateも含めてサポートしたことをアナウンスしました。このサポートにより、コンテナベースのアプリケーションやマイクロサービスを継続的デリバリするパイプラインを作成するのがより簡単になりました。 コンテナ化したサービスを手動で構築しデプロイするのは、時間がかかりますしエラーを起こしがちです。自動化されたビルドとテスト機構と組み合わせた継続的デリバリは、早期にエラーを発見し時間を短縮することを助け、失敗を減らしてくれるので、アプリケーションのデプロイモデルとして一般的なものとなってきています。以前は、ECSでコンテナワークフローを自動化するには、AWS CloudFormationを使った自前のソリューションを構築する必要がありました。これからは、わずか数ステップでCodePipelineとCodeBuildをECSと連携させてワークフローを自動かすることができます。 CodePipeline、CodeBuild、そしてECSを使った典型的な継続的デリバリのワークフローは、以下のようなものです: ソースを選択する プロジェクトをビルドする コードをデプロイする GitHub上にこのワークフローのための継続的デプロイのリファレンスアーキテクチャも公開しています。 はじめてみよう 最初に、CodePipelineで新規プロジェクトを作成し、例として”demo”というプロジェクト名を設定します。 次に、コードが保管されているソースの場所を選択します。ここには、AWS CodeCommit、GitHub、またはAmazon S3が選択できます。この例では、GitHubを入力し、CodePipelineにレポジトリへのアクセス権を与えます。 次に、ビルドステップを追加します。JenkinsサーバURLやCodeBuildプロジェクトの様に既存のビルドを持ってくることもできますし、CodeBuildで新しいステップを作成することもできます。もし既存のCodeBuildのプロジェクトがなければ、以下の様に選択してCodePipelineから新しいものを作成しましょう: Build provider: AWS CodeBuild Configure your project: Create a new build project Environment image: Use an image managed by AWS CodeBuild Operating system: Ubuntu Runtime: Docker Version: aws/codebuild/docker:1.12.1 Build specification: […]

Read More

新世代のAmazon Linux 2 リリース

Amazon Web Services (AWS) が提供しているAmazon Linuxに新世代のAmazon Linux 2がリリースされました。他のサービスがそうであるようにAmazon Linux 2ではお客様からいただいた多くのフィードバックを元に作成されています。この新しいAmazon Linuxの特長をみていきましょう。 LTS(Long Term Support)の提供 これまでのAmazon Linuxはローリングアップグレードで定期的に新しいバージョンのパッケージが提供され続けることにより、常に最新の状態を維持できる環境として提供されていました。Amazon Linux 2でもこれは変わりませんが、加えてLTS (Long Term Support: 長期サポート)を提供する予定です。LTSでは5年間に渡りコアオペレーティングシステムにセキュリティパッチとバグフィックスを提供し続け、その間のユーザ空間のABI(Application Binary Interface)とAPI(Application Programming Interface)の互換性を維持します。互換性を維持しつつ安全なLinux環境を提供するのが目的であり、新しい環境に更新されることより互換性のある環境を長期に渡って使い続けることの方を望むお客様からのリクエストに応えるものです。 またコアオペレーティングシステムには無い、もしくは新しいバージョンのパッケージについてはAmazon Linux Extrasリポジトリから入手可能です。詳しくはamazon-linux-extrasコマンドのマニュアルを御確認ください。 LTSビルドは現在リリース候補(Release candidate)の状態として提供されており、評価を開始いただける状態です。 オンプレミス環境でのテストや開発が容易に Amazon Linux はAmazon EC2やAmazon ECS (コンテナ環境)上で容易に利用いただけるディストリビューションですが、Amazon Linux 2ではこれらに加えて、VMware、Microsoft Hyper-V、Oracle VM VirtualBoxの仮想イメージを提供します。これによりオンプレミス環境でのテストや開発が容易になります。Amazon Linux 2を稼働させるには最小で512MBのメモリが必要です。 新しい環境とセキュリティの強化 Kernel 4.9やSystemdのサポート等、OS環境全体が刷新されています。またセキュリティ面でも必須パッケージを厳選することによりリスクを減らし、重要度が高いセキュリティパッチについてはOS起動時に自動的に適用する等、高いセキュリティレベルを保つための仕組みが組み込まれています。 今からご利用いただけます! 全ての商用リージョンでAMIが選択可能になっていますので、ぜひ御利用ください。HVMをサポートする全てのインスタンスタイプで御利用いただけます。Amazon LinuxをEC2上で利用する上で追加の費用は不要です(通常のAmazon EC2費用で利用可能)。DockerリポジトリにもAmazon Linux 2のベースイメージが準備済です。またフォーラムでは新しい告知に加えてみなさまからの利用のフィードバックをお待ちしております。   […]

Read More

Amazon Elastic Container Service for Kubernetes

私の同僚 Deepak Singh が、コンテナに関してたくさんお伝えしたいことがあります! – Jeff; AWS 上で Kubernetes を利用している多くのお客様がいます。実際、Cloud Native Computing Foundationによると、Kubernetes のワークロードの63%が AWS 上で動作しています。AWS は Kubernetes を実行するうえで人気の場所ですが、お客様が Kubernetes クラスターを管理するためには、依然として多くの手動設定が必要となります。Kubernetes のマスターをインストールして運用し、Kubernetes のワーカーのクラスターを構成する必要があります。Kubernetes クラスターで高可用性を実現するには、異なる AZ 間で少なくとも三つの Kubernetes マスターを実行する必要があります。各マスターは、それぞれで対話し、障害が発生した場合に備え情報を共有し、負荷分散、フェールオーバーを他のマスターに確実に実行するように構成する必要があります。そして、すべての設定と実行が完了しても、マスターとワーカーのソフトウェアのアップグレードとパッチ適用を行う必要があります。これらは運用の専門家とその努力必要としており、我々はお客様からもっと簡単にしてほしいと言われてきました。 Amazon EKS の紹介 Amazon Elastic Container Service for Kubernetes (Amazon EKS) は、Kubernetes クラスターの専門家でなくてもKubernetesを AWS 上で簡単に使用することができるフルマネージドサービスです。開発者の皆様にこのサービスを気に入ってもらえるいくつかの点があります。まず、Amazon EKS は オープンソースの Kubernetes を基に実行されますので、Kubernetes コミュニティの全ての既存のプラグインとツールを使用できます。Amazon EKS 上で動作するアプリケーションは、オンプレミスのデータセンターやパブリッククラウドで動作しているかにかかわらず、標準の Kubernetes 環境で動作するアプリケーションと完全に互換性があります。つまり、コード変更なしで簡単にあなたの Kubernetes アプリケーションを […]

Read More

AWS Fargate: サービス概要

AWS上でコンテナを運用管理するお客様の手助けになるようAmazon Elastic Container Service(Amazon ECS)をアナウンスしたのは約3年前でした。Amazon ECSを利用することで、クラスター管理やオーケストレーション用ソフトウェアを運用することについて心配する必要がなくなり、大規模に高い可用性を持ってワークロードを稼働させることが可能になりました。 2017/11/29、AWSは AWS Fargateをアナウンスしました。下回りとなるインスタンス群の管理をせずとも、コンテナを基本的な計算単位として利用することができる技術です。Fargateをご利用いただくことで、コンテナを動かすためにクラスター内の仮想マシンのプロビジョニング、設定やスケールを行う必要はもうありません。Fargateは現在Amazon ECSから利用可能ですが、将来的にはAmazon Elastic Container Service for Kubernetes (Amazon EKS)もサポートする予定です。 Fargateでは、アプリケーションの要件に対して最も近い設定を柔軟に行うことができ、請求は秒単位となります。 Amazon ECSとFargate Amazon ECSは、コンテナを大規模に稼働させることを可能にします。また、このサービスは、VPC networking、load balancing、IAM、Amazon CloudWatch LogsやCloudWatch metricsといったAWSプラットフォームとネイティブに連携しています。これらの連携により、ECSタスクはAWSプラットフォームの中でファーストクラスオブジェクトとして扱うことができます。 タスクを起動するためには、適切なインスタンスタイプと数を選び、Auto Scalingを設定し、パフォーマンス向上のためにクラスターのサイジングを管理するといったクラスターの立ち上げが必要ですが、Fargateでは、それらを全て忘れることができ、アプリケーションの定義、権限やスケーリングについてのポリシー設定に専念することができます。

Read More

AWS Fargateの紹介 – インフラストラクチャの管理不要でコンテナを起動

コンテナは、開発者がアプリケーションを開発・パッケージ・デプロイするのに強力な手法の1つです。AWSでは、十万以上のアクティブなECSクラスタが稼働しており、毎週数億の新しいコンテナが起動しています。これは、2016年からすると400%を超えるお客様成長率です。Amazon ECSやKubernetesといったコンテナのオーケストレーションソリューションは、コンテナワークロードのデプロイ・管理・スケールをより容易にし、敏捷性を増します。しかし、それらのどのソリューションも下回りとなるインフラストラクチャの可用性、キャパシティやメンテナンスを行う必要が依然としてあります。AWSにおいて、私たちはこれを差別化とならない重労働を取り除く機会と考えました。私たちは、コンテナがもたらすスピード、敏捷性や不変性のメリットを十分にお客様にご利用いただき、インフラストラクチャの管理ではなくアプリケーションの構築に注力いただきたいと思っています。 AWS Fargate AWS Fargateは、コンテナをデプロイする最も簡単な方法です。端的に言うと、FargateはEC2に似ていますが、仮想マシンを提供する代わりに、コンテナを提供します。これにより、下回りとなるインスタンス群の管理をせずとも、コンテナを基本的な計算単位として利用することができる技術です。やるべきことは、コンテナイメージ構築し、CPUやメモリの要件を指定し、ネットワークやIAMポリシーを定義し、そしてコンテナを起動することです。Fargateでは、アプリケーションの要件に対して最も近い設定を柔軟に行うことができ、請求は秒単位となります。

Read More