Category: Compute

クラウド上で Windows アプリケーションを利用しようとしている組織では、通常、既存のアプリケーションや Windows 環境と完全に互換性のあるネットワークストレージを探します。例えば、エンタープライズ企業では ID 管理目的で Active Directory を使用し、フォルダやファイルへのきめ細かなアクセス制御のために Windows Access Control List を使用し、これらの企業のアプリケーションは Windows ファイルシステム (NTFS ファイルシステム) と完全互換のストレージに頼った作りになっています。 Amazon FSx for Windows ファイルサーバー Amazon FSx for Windows ファイルサーバーはこれら全てのニーズに対応しています。既存の Windows アプリケーションや Windows 環境で作業することを前提に設計されており、Windows ワークロードのクラウドへの Lift-and-Shift を非常に簡単にしてくれます。完全マネージド型の Windows ファイルサーバーに裏付けられたネイティブ Windows ファイルサーバーに、広く採用されている SMB (Server Message Block) プロトコルを介してアクセスできます。SSD ストレージで構築されている Amazon FSx for Windows ファイルサーバーは、皆さん (と皆さんの Windows アプリケーション) […]

AWS Fargate と Amazon Elastic Container Service (Amazon ECS) 上で稼働するサービスでの Blue/Green デプロイメントがサポートされます。 AWS CodeDeploy を利用し、 Blue/Green デプロイメントを行うことでアプリケーションの更新時のダウンタイムを最小限に抑えることが出来るようになります。 Blue/Green デプロイメントは、古いバージョンと新しいバージョンのアプリケーションを同時に起動し、新しいバージョンをテストしてからトラフィックをルーティングします。デプロイ状況を監視し、問題が発生した場合はすぐにロールバックすることも出来ます。 この新しい機能により、デプロイメント、テスト、トラフィックのカットオーバーが管理されたサービスを、AWS Fargate または Amazon ECS で作成することが出来ます。 サービスを更新すると、AWS CodeDeploy によってデプロイメントがトリガーされます。 このデプロイメントは、Amazon ECSと連携して、新しいバージョンのサービスを Green 環境用のターゲットグループにデプロイし、ロードバランサのリスナーを更新してこの新しいバージョンをテストできるようにし、ヘルスチェックが成功した場合にカットオーバーを実行します。

本日(11/28)、Amazon Elastic Container Registry (Amazon ECR) を AWS CodePipline のソースプロバイダとして利用可能になりました。これにより Amazon ECR に新しいイメージをアップロードすることにより、AWS CodePipelineを起動することができるようになります。AWS Developer Tools による CI/CD 実現が一段と容易になりました。 Amazon ECR をソースとして使うには、AWS CodePipline コンソールでAWS CodeDeploy による Blue/Green デプロイメントを実装している必要があります。CodePipelineを使わず、Amazon Elastic Container Service (Amazon ECS) コンソールを使って Blue/Green デプロイメントを実装するより詳しい情報については、AWS CodeDeploy による AWS Fargate と Amazon ECS でのBlue/Greenデプロイメントの実装を参照してください。 この投稿では Amazon ECR とAWS CodePipeline を使用してエンドツーエンドの継続的デリバリ (CD) パイプラインを構築する方法について解説します。ここではアップストリームのベースイメージが更新されたらコンテナイメージを更新ためのパイプラインを作る一連の流れを説明します。

私の好きなAmazonリーダーシッププリンシプルの1つはCustomer Obsessionです。 私たちがAWS Lambdaをローンチしたとき、私たちは開発者にセキュアなサーバーレス体験を提供し、インフラストラクチャの管理を避けることに重点を置いていました。 目的のレベルの分離を達成するために、我々は各顧客に専用のEC2インスタンスを使用しました。 このアプローチにより、私たちはセキュリティ目標を達成することができましたが、私たちがLambdaを裏で管理する方法に関していくつかのトレードオフを余儀なくされました。 また、新しいAWSサービスの場合と同様に、顧客がLambdaをどのように使用するのか、あるいはサーバーレスモデル全体をどのように考えているのかもわかりませんでした。 私たちの計画は、時間の経過とともにバックエンドをより効率的にすると同時に、優れたカスタマーエクスペリエンスを提供することに重点を置くことでした。 ちょうど4年後 (Lambdaはre:Invent 2014でローンチされました)、サーバーレスモデルが普及したことは明らかです。 現在Lambdaは毎月何十万人ものアクティブな顧客に対して数兆件の処理を実行しています。 昨年、我々はAWS Fargateのローンチによりサーバーレスの利点をコンテナにまで拡張し、毎週AWSの顧客に数千万のコンテナを提供しています。 私たちの顧客がサーバーレスでの採用を進める中で、効率の問題を再検討する時が来ました。 Invent and Simplifyの原則を念頭に置いて、今のコンテナやファンクションの世界のための設計として仮想マシンがどのように見えるのか自分自身に尋ねました。 Firecrackerの紹介 本日、KVMを利用する新しい仮想化技術であるFirecrackerについてお話したいと思います。 仮想化されていない環境では、軽量のマイクロ仮想マシン（microVM）を数秒で起動することができ、従来のVMで提供されているセキュリティとワークロードの分離と、コンテナに伴うリソース効率性を向上しています。 Firecrackerについて知っておくべきことは次のとおりです: セキュア – これは常に最優先事項です! Firecrackerは複数レベルの分離と保護を使用し、攻撃面は最小限に抑えられています。 ハイパフォーマンス – 今日時点でわずか125ミリ秒 (さらに2019年に高速化予定) でmicroVMを立ち上げることができ、一時的なものや短命のものを含む多くの種類のワークロードに最適です。 Battle-Tested – FirecrackerはBattle-Testedであり、既にAWS LambdaとAWS Fargateを含む複数のハイボリュームなAWSサービスに利用されています。 低オーバーヘッド – Firecrackerは、microVMあたり約5 MiBのメモリを消費します。 同じインスタンス上で、さまざまなvCPUとメモリ構成を持つ数千のセキュアなVMを実行できます。 オープンソース – Firecrackerはアクティブなオープンソースプロジェクトです。私たちはすでにpullリクエストを確認して受け入れる準備を完了しており、世界中の寄稿者とのコラボレーションを楽しみにしています。 Firecrackerは最小限主義の流儀で造られました。 私たちはオーバーヘッドを減らし安全なマルチテナンシーを可能にするために、crosvmからスタートし、最小限のデバイスモデルを設定しました。 FirecrackerはRustで書かれており、その最新のプログラミング言語はスレッドの安全性を保証し、セキュリティの脆弱性を引き起こす可能性があるさまざまなタイプのバッファオーバーランエラーを防止します。 Firecrackerのセキュリティ 前述のように、Firecrackerには多数のセキュリティ機能が組み込まれています! ここに部分的なリストがあります: Simple Guest Model – Firecrackerのゲストには、ネットワークデバイス、ブロックI […]

私たちは昨年、強力なコンピューティング集約型のC5インスタンスを立ち上げ、今年初めにはローカルNVMeストレージを追加したC5dインスタンスをフォローアップしました。 どちらのインスタンスもAWS Nitroシステム上に構築されており、AWSカスタムの3.0Ghz Intel Xeon Platinum 8000シリーズプロセッサを搭載しています。 それはバッチ処理、分散解析、ハイパフォーマンスコンピューティング(HPC)、広告配信、ハイスケーラブルなマルチプレーヤゲーミング、ビデオエンコーディングなどのコンピューティング重視のアプリケーション用に設計されています。 新しい100 Gbpsのネットワーク 本日私たちはさらに強力な変種であるC5nのインスタンスを追加しました。 最大100 Gbpsのネットワーク帯域幅で、シミュレーション、インメモリキャッシュ、データレイク、その他の通信集約型アプリケーションがこれまで以上に優れたパフォーマンスを発揮します。 スペックは以下の通りです： Instance Name vCPUs RAM EBS Bandwidth Network Bandwidth c5n.large 2 5.25 GiB Up to 3.5 Gbps Up to 25 Gbps c5n.xlarge 4 10.5 GiB Up to 3.5 Gbps Up to 25 Gbps c5n.2xlarge 8 21 GiB Up to 3.5 Gbps Up […]

先日、AWS は AWS Application Auto Scaling の新機能を発表しました。Amazon Kinesis Data Stream に対してシャードを自動的に追加・削除するスケーリングポリシーを定義できる機能です。この機能の詳細については、Application Auto Scaling の GitHub リポジトリを参照してください。 ストリーミングの情報が増えると、あらゆるリクエストに対応するスケーリングソリューションが必要になります。逆にストリーミング情報が減る場合も、スケーリングを利用してコストを抑えなければなりません。現在、Amazon Kinesis Data Stream のシャードはプログラム的にスケーリングされています。あるいは、Amazon Kinesis のスケーリングユーティリティを使用することも可能です。その場合は、ユーティリティを手動で使用する方法と、AWS Elastic Beanstalk 環境で自動化する方法があります。 Application Auto Scaling の新機能を使うと、AWS を使用してスケーリングソリューションを作成することができ、人手の介入も複雑なソリューションも必要ありません。 Auto Scaling ソリューションの概要 今回のブログ記事でご紹介するのは、デフォルトの Amazon CloudWatch メトリクスに基づいて Amazon Kinesis Data Streams に Auto Scaling ソリューションをデプロイする方法です。環境を自動的に設定する AWS CloudFormation テンプレートと、Lambda 関数に関連するコードについても触れます。 Auto Scaling ソリューションのしくみ 始まりは、Kinesis Data […]

  皆様、こんにちは。セキュリティソリューションアーキテクトの桐山です。 2018/10/29(月)から11/2(金)にかけて開催されたAWS Dev Day Tokyo 2018で実施された、セキュリティ関連のセッションとワークショップをおさらいしてみます。 開発者向けカンファレンスということで、この度はセキュリティに興味のある多くの開発者にご参加いただきました。これから企業がデジタルトランスフォーメーション(DX)時代に向かっていく中、開発者の役割も更に高度化・専門化しています。 事業部門で、いわゆるSysmem of Engagement(SoE)領域に携わる開発者は、下記のような今までにない新しいワークロードをセキュアに開発することに挑戦しているでしょう。 IoTサービスにより、様々なデバイスから大量の信頼性の高い実データを収集する 企業内データを一元的に集約・保存する場所(データレイク)をセキュアに管理・運用する 迅速にビジネスインサイトを活用するために、データ分析・可視化・利用をサーバーレスコンピューティング環境で実現する 上のそれぞれに相当するIoTセキュリティ、データレイクセキュリティ、サーバーレスセキュリティは新しいセキュリティ技術領域と言えます。 一方で、IT部門にて、いわゆるSystems of Record(SoR)領域に携わる開発者は、事業成長を支えるセキュリティ基盤を実現しなければなりません。ITインフラ自体を変革させると同時に、事業活動の変化やスピードに対応するためにSecurity as a ServiceやSecurity Automationに取り組むことになるでしょう。 このようなDX時代のセキュリティをAWSで実現するとしたら・・・以下のワークショップとセッションが役に立つはずです。

2018年10月29日から11月2日まで行われた AWS DevDay Tokyo 2018の中で、Serverless&MobileのトラックオーナーをしておりましたSAの小梁川です。本投稿では2018/10/31に開催しましたServerless&Mobileトラックの内容をご紹介いたします。 イベント開催においては、お忙しい中に資料作成、登壇を頂いた ZOZOテクノロジーズ 柴田様、クックパッド 渡辺様に御礼申し上げます。また、会場に起こした頂いた、ストリーミング視聴をいただけた皆様へ、イベントご参加への御礼を申し上げます。 資料をゆっくり読みたい、参加できなかったが資料が見たいとの声を頂いておりましたので、本投稿にてServerless&Mobileセッションの資料をご紹介させていただきます。

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ビルドを使用します。

みなさん。こんにちは。アマゾン ウェブ サービス ジャパン株式会社、プロダクトマーケティング エバンジェリストの亀田です。 AWS Lambdaのタイムアウトが5分から15分に延長されましたのでお知らせいたします。マネージメントコンソールでは15分まで設定を投入できるようになっています。 デフォルトではNode.jsだと3秒、.NET Coreだと15秒が設定されていますが、そちらを修正できますので、アプリケーションの内容に応じた適切な内容を設定いただくことができます。 また、9月11日には、.NET Core 2.1 ランタイムを使用して、PowerShell Core 6.0 で AWS Lambda 関数を開発できるようになりました。サーバレス関数を作成する際、現在使用可能なすべての PowerShell cmdlets あるいはご自身で開発したものを使うことができます。開始するには、Powershell Gallery から PowerShell 用の AWS Lambda ツールモジュールをダウンロードしてください。 現在AWS Lambdaがサポートしている言語環境は以下になります。 用途が広がるAWS Lambdaですが、AWS Serverless Application Repositoryでは、サーバーレスコミュニティーのデベロッパー、企業、パートナーが公開したサーバーレスアプリケーションが登録されており、参考にすることができます。みなさんも、ご自身で開発したサーバレスアプリケーションを登録できます。   – プロダクトマーケティング エバンジェリスト 亀田