Category: Amazon EC2

Oracle社の最新のアナウンスメントによると、Oracle社が提供するOpenJDKへの無料のLTS (Long-Term Support) は2019年1月までで終了することが示されています。ここで改めてAmazon Linux 2上でのOpenJDK 8およびOpenJDK 11ランタイムへのLTSが最短でも2023年6月30日までAmazonより提供されることをお伝えします。私達はOpenJDKコミュニティとコラボレーションし、また貢献することで私達のお客様にJavaランタイムの無料LTSをご提供いたします。 加えて、Amazon Linux AMI の最新リリースである Amazon Linux AMI 2018.03では、Amazon Linux 2への移行を容易にするため、OpenJDK 8ランタイムのサポートを最短でも2020年6月30日までAWSよりご提供します。AWSのサービスである、AWS LambdaやAmazon EMR、Amazon Elastic BeanstalkはAWSがサポートするOpenJDKビルドを使用します。

私が1977年に組み立てたコンピュータAltair 8800は、わずか4キロバイトのメモリしか持っていませんでした。現在、約40億倍の12テラバイト (正確には12テビバイト)のメモリを搭載したEC2インスタンスを使うことができます。 新しいAmazon EC2 ハイメモリインスタンスは、Amazon Elastic Block Store (EBS)、Amazon Simple Storage Service (S3)、AWS Identity and Access Management (IAM)、Amazon CloudWatch、そしてAWS Configといった他のAWSサービスを活用できます。これらは、AWSのお客様が大規模なSAP HANAのインストールを実行できるように設計されており、エンタープライズレベルのデータ保護とビジネス継続性を提供する本稼働システムの構築に使用できます。 スペックは以下の通りです: インスタンス名 メモリ 論理プロセッサ 専用のEBS帯域 ネットワーク帯域 u-6tb1.metal 6 TiB 448 14 Gbps 25 Gbps u-9tb1.metal 9 TiB 448 14 Gbps 25 Gbps u-12tb1.metal 12 TiB 448 14 Gbps 25 Gbps

あなたは分散型サービス拒否 (DDoS) 攻撃やその他のサイバー攻撃の影響からビジネスを守るために働いており、アプリケーションの可用性と応答性を確保し、サービスに対するお客様の信頼を維持したいと考えています。また、攻撃に対応するためにインフラストラクチャをスケールする必要がある場合でも、不必要なコスト上昇を避けたいと考えています。 AWS はインターネット上の攻撃を防ぎ、高可用性・セキュリティの確保および回復力を得られるように、ツール・ベストプラクティスおよびサービスを提供することをお約束します。私達は最近、2018 年版の DDoS に対する AWS のベストプラクティス（英語のみ）のホワイトペーパーをリリースしました。今回のアップデートでは、 DDoS 攻撃への対策を強化するのに役立つ、以下の新しく開発された AWS サービスを考慮に入れています: 追加された AWS サービス: AWS Shield Advanced、AWS Firewall Manager および AWS Application Load Balancer のような新世代の ELB 追加された AWS サービスの機能: AWS WAF Managed Rules、AWS WAF Rate Based Rules、新しい世代の Amazon EC2 インスタンスおよび API Gateway のリージョン API エンドポイント このホワイトペーパーは、DDoS 攻撃に対する回復力のあるアプリケーションを構築するための規範的な DDoS ガイダンスを提供します。ボリューム型攻撃やアプリケーション層に対する攻撃など、さまざまな攻撃タイプを紹介し、各攻撃タイプを管理する上で最も効果的なベストプラクティスを説明します。また、DDoS 緩和戦略に適合するサービスや機能および、それぞれがどのようにアプリケーションを保護するのに役立つのかについて要点を説明します。 原文: AWS […]

最新の Amazon Linux AMI を取得するシンプルな方法が必要ですか？ AWS Systems Manager Parameter Store はすでに最新の Windows AMI を取得できます。今回、最新の Linux AMI も取得できるよう機能が拡張されました。各 Amazon Linux AMI は、固有の 公開パラメータストア名前空間 を持ちます。AMIの名前空間をクエリすることで、指定したリージョンのイメージIDを得ることができます。

こんにちは、マーケティングの鬼形です。 先日 (2018/4/11) 開催致しました AWS Black Belt Online Seminar「Amazon EC2」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

Amazon Elastic File System はファイルベースのストレージへの共有アクセスが必要なクラウドネイティブなアプリケーション向けにファイルシステム選択肢の一つとなるよう設計されました。私たちは2016年中頃に EFS の提供を始めて、以降、”Direct Connect 経由のオンプレミス環境からのアクセス”や”保管データの暗号化”など重要な機能をいくつも追加してきました。また、EFS を提供する AWS リージョンの追加も行ってきており、直近では US West (北カリフォルニア) が追加されました。EFS 自体がそうであったように、これらの機能追加はお客様からのフィードバックにより為されたもので、益々拡大するお客様の声に応えたいという私たちの願望を反映しています。 伝送データの暗号化 今日、EFS をより便利なものにするために伝送データの暗号化サポートを追加しました。既にサポートしている保管データの暗号化と共に使用する場合、多層防御セキュリティ ストラテジーによる格納ファイルの保護が実現されます。 伝送データの暗号化の実装をより簡単にするために、EFS マウント ヘルパーもリリースします。このヘルパー(ソースコードと RPM 形式で提供)は、EFS への TLS トンネルの確立を助けてくれるもので、また ID によるファイルシステムのマウントもできるようにするものです。この 2 つの機能はそれぞれ独立しています。ヘルパーを使用して、伝送データの暗号化をしていなくても ID でファイルシステムをマウントできます。ヘルパーは実際の mount コマンドのデフォルトオプションの推奨セットも提供してくれます。 暗号化のセットアップ Amazon Linux インスタンスに EFS マウントヘルパーをインストールするところから始めます。 $ sudo yum install -y amazon-efs-utils 次に、EFS コンソールを開き、ファイルシステム ID を取得します。 そして、その ID […]

いくつかの必須の EC2 リソースに対する長い ID を提供するための以前の仕事のフォローアップとして、当社は移行の期日を 2018 年 7 月に設定して、同じことを残りの EC2 リソースに対しても行っています。ユーザーごと、リージョンごと、タイプごとにオプトインして、コード、正規表現、データベーススキーマおよびデータベースクエリが期待通りに動作することを確認できます。 EC2 リソースのタイプについて ID を認識、処理、または保存するコードがある場合は、注意深く、この投稿をお読みください。知る必要があることは、次のとおりです。 移行期日 – お使いのコードおよびスキーマが新しい、長い ID を処理し、保存できるのは、2018 年 7 月までです。その後、長い ID はすべての新しく作成されたリソースにデフォルトで割り当てられます。既存のリソースの ID は、そのまま残り、機能し続けます。 詳細なリソースタイプ – 長い ID はすべてのタイプの EC2 リソースに対してサポートされ、希望に応じてオプトインすることができます。 できるだけ早く、テストアカウントから始めて、オプトインするようにお勧めします。このことは、コードを徹底的にテストし、コードを本番稼働させるためにプロモーションする前に、必要な変更を行うための時間を与えます。 その他のリージョン – 長い ID は、現在、AWS 中国 (北京) および AWS 中国 (寧夏) リージョンで使用可能です。 AMI のテスト – テストするために使用できる長い ID をもつ AMI を発行しました […]

ネットワークストレステスト 【日本語訳】日本時間 2018年02月08日09:00 このポリシーは、お客様の Amazon EC2 インスタンスから、他の Amazon EC2 インスタンス、AWS プロパティ/サービス、外部エンドポイントのような他の場所へ、大規模なネットワークテストを直接実施することを計画しているお客様に関係するものです。 これらのテストは、ストレステストや負荷テスト、ゲームデーテストと呼ばれることがあります。このポリシーでは、テストにおいて正当な大規模トラフィックあるいはテストトラフィックを特定の対象アプリケーションに対し送信する行為を「ネットワークストレステスト」とします。エンドポイントとインフラストラクチャは、このトラフィックを処理できる必要があります。 このポリシーは、通常のプロダクションのトラフィックとは関係ありません。ネットワークストレステストは、多くの場合、特定のエンドポイントを対象とし、送信元や対象が集中することを含め、通常とは異なるトラフィックパターンを持ち、持続的に大規模なトラフィックが発生し、予期している上限値を超える可能性があるため、通常のプロダクションとは異なります。ネットワークストレステストにおけるこれらの違いは、外部エンドポイント、他のお客様、AWS サービスに対し意図しない影響を与えうる潜在的なリスクとなります。 パケットや接続のフラッディング、それ以外の大規模なトラフィックで、ターゲットやインフラストラクチャへ意図的に過大な負荷をかけるテストは、ネットワークストレステストではなく、分散型 DoS (DDoS) テストとして扱われます。ボリュームのあるネットワークベースの DDoS シミュレーションは、Amazon EC2 プラットフォームでは明示的に禁止されています。このポリシーは、https://aws.amazon.com/security/penetration-testing の範囲のセキュリティやペネトレーションテストは対象としません。 ほとんどのお客様はこのポリシーには該当しません。通常、ユニットテストのように大規模なワークロードをシミュレートするストレステストでは、ネットワークストレステストに該当するだけのトラフィックは生成されません。このポリシーは、お客様のネットワークストレステストによって、Amazon EC2 インスタンスで以下の基準を満たすトラフィックが生成されたときに適用されます。”持続的に 1分以上の間 1 Gbps（秒間 1億ビット）あるいは 1Gpps（秒間 1億パケット）を超えるトラフィック、悪用目的や悪意があるように見えるトラフィック、テスト対象以外（ルーティングや共有サービスのインフラストラクチャなど）へ潜在的に影響を及ぼしうるトラフィック” などが該当します。 お客様は、対象のエンドポイントへのテストが承認され、その起こりうる規模について理解している必要があります。いくつかの外部エンドポイントや AWS サービスは、ある種のテストシナリオに対して期待する閾値よりも低い性能しか発揮できない可能性があります。 AWS を利用する多くのお客様は通常のプロダクションモードで定期的に 1Gbps もしくは 1Gpps 以上のトラフィックを生成していることを確認しております。これは完全に正常であり、特にネットワークストレステストの目的のために実施されたものではない限り、このポリシーの範囲下ではありません。 このポリシーの基準を満たすネットワークストレステストにはリスクがあります。お客様が悪質であると検知され報告されるリスク、お客様が意図せず悪質となり他の対象に影響を及ぼすリスク、お客様が所有するインスタンスで機能制限を受ける可能性などがあり、この際にはテストだけではなく、プロダクションのワークロードへ影響する可能性があります。 実施するテストがこれらの基準を満たすか、お客様で不明な場合は、このポリシーに従い、AWS 側にテストの評価を依頼する必要があります。お客様の体験や、その他の影響を受ける可能性があるサービスを改善していくため、これらのストレステストを実行する前には、Amazon EC2 ネットワークストレステストを申し込みフォームから申請してください。このフォームは aws-security-simulated-event@amazon.com へメールを送ることで入手できます。 お客様のネットワークストレステストが 外部や他の AWS サービスのような EC2 インスタンス以外から直接実行される場合、フォームからの申請が必要かどうかメールでお問い合わせください。 […]

多くのAWSのお客様がミッションクリティカルなワークロードをIBM Db2データベースプラットフォームを利用して実行しています。一般的に、こういったワークロードには、ノード障害やデータセンターサイトの障害時でも運用を続けられる高い可用性が必要とされます。 従来のIBMソフトウェアにおける高可用性手法は、共有ディスクと仮想IPアドレスを使用し、これをTivoli System Automation for Multi-Platforms (TSAMP)でコントロールするというものでした。このブログポストでは ネイティブのIBMとAWSの技術を用い、かつ自動化された手法を説明します。これによりミッションクリティカルなDb2ワークロードをAWS上で稼働でき、高可用性のDb2データベースを安心して提供できるようになります。 注：このガイドで使用するIBM Db2は、フル機能が90日間利用できるトライアル版のDb2 for Linux, Unix and Microsoft Windows バージョン11です。トライアル期間が終了したあとは、必要とするエディションを選択、購入し、ライセンスファイルを導入して利用することが可能です。このガイドで利用している機能が使用できるエディションは、Db2 Advanced Enterprise Server Edition、 Db2 Enterprise Server Edition、Db2 Advanced Workgroup Server Edition、Db2 Workgroup Server Editionです。より詳細な情報はIBM Webサイトを確認してください。（訳注：こちらにエディションの違いの詳細があります） この記事のステップを進めていくと、2つのアベイラビリティゾーン（AZ）にまたがって高可用性を実現するDb2 データベースを作成します。データはAZ1にあるプライマリーインスタンスとAZ2にあるスタンバイインスタンスの間でHADR(High Availability Disaster Recovery)機能でレプリケーションされます。もしプライマリーノードが利用できなくなった場合、TSAMPがそれを検知し、スタンバイインスタンスにフェイルオーバーさせます。Db2 クライアントアプリケーションは自動クライアントリルート機能 (IBM Automatic Client Reroute : ACR)により自動的に新しくプライマリーになったインスタンスに再接続されます。 事前準備のステップ このソリューションはAWSのデフォルトVPC (Virtual Private Cloud)にデプロイされます。デフォルトVPCはAWSアカウント作成時に自動的に各リージョンに作成されています。もしデフォルトVPCが無い場合は、次のステップに進む前に以下を実行してください。 同一リージョンの２つのパブリックサブネットを持つVPCを作成してください。それぞれのサブネットは別のAZに配置してください。 VPCにインターネットゲートウェイを配置してください。それぞれのサブネットはインターネットゲートウェイ経由でインターネットに出られるようにします。 最初にAmazon S3 […]

モダンコンピュータプロセッサ上で投機的実行によるサイドチャネル分析の調査が新しく公開されたのを受け、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 & […]