Category: Compute

AWS が設計した第 1 世代の Graviton プロセッサは 2018 年末に発表され、1 年後には第 2 世代の Graviton2 が発表されました。現在、AWS のお客様は、メモリを大量に消費するワークロード用に設計された新しい X2GD インスタンスを含む、12 種類の Graviton2 搭載インスタンスを使用しています。すべての Graviton プロセッサには、各 vCPU 専用のコアとキャッシュに加え、AWS Nitro System によるセキュリティ機能が追加されています。Graviton2 プロセッサには、常時オンのメモリ暗号化のサポートが追加されています。 現在準備中の C7g これからリリースされる C7g インスタンスについてお話しします。

この記事は Docker Official Images now available on Amazon Elastic Container Registry Public を翻訳したものです。 コンテナベースのアプリケーションを構築する開発者は、Amazon Elastic Container Registry (Amazon ECR) Public から直接 Docker 公式イメージを見つけて、ダウンロードできるようになりました。この新しい機能により、AWS のお客様は豊富な AWS 無料利用枠を利用しながら、Docker 公式イメージをプルするためのシンプルで可用性の高い方法を得ることができます。Amazon ECR Public から任意の AWS リージョンにイメージをプルするお客様は、事実上無制限にダウンロードできます。AWS 外で動作するワークロードについて、AWS 上で認証されていないユーザーは毎月 500 GB のデータダウンロードが可能です。さらにデータをダウンロードしたい場合は、AWS アカウントにサインアップまたはサインインすることで、毎月 5 TB までのデータをダウンロードすることができ、その後は 1 GB あたり 0.09 ドルの料金が掛かります。

2021 年の re:Invent では、参加者の皆さんに対して対面およびバーチャルのカンファレンス体験を提供します。イベントの対面部分は、2021 年 11 月 29 日から 2021 年 12 月 3 日までラスベガスで開催されます。バーチャルイベントの参加者は無料で登録でき、バーチャル re:Invent プラットフォームによりセッションのサブセットにアクセスできます。本記事では、コンテナトラックを取り上げており、Amazon Elastic Container Service (ECS)、Amazon Elastic Kubernetes Service (EKS)、AWS App Runner、AWS Fargate、AWS Proton、Amazon Elastic Container Registry (ECR)、AWS App Mesh に関するセッションを紹介します。 いつものように、re:Invent 2020 以降に AWS が取り組んできたものを皆さんと共有できることにワクワクしています。まだ re:Invent へ登録していない場合は、今すぐバーチャル参加者としてプラットフォームに登録し、すべてのアジェンダを確認してお気に入りのセッションをカレンダーに追加してください。

この記事は Rackspace の Solutions and Services Engineering チームの Principal Engineer である Ryan Walker 氏と共同で作成しました。 クラウド技術が普及した現在、企業がサーバーをホスティングしたりソリューションを構築したりする際に多くの選択肢があります。Rackspace は、複数のクラウドプロバイダーの利用から、ベアメタルデバイス、プライベートクラウド、さらにはオンプレミスのリソースに至るまで、多様なポートフォリオをお客様に提供しています。お客様のシステム構造は、ビジネスニーズ（例えば、クラウドの多様化への関心）に起因することがあります。あるいは、クラウド環境への移行の初期段階に起因するかもしれません。お客様は、オンプレミスの契約が終了するのを待っているのかもしれません。どのような理由であっても、お客様は共通して同じ質問をします。「マルチクラウド環境やハイブリッド環境、オンプレミス環境でのパッチ適用を一元管理するにはどうすればいいですか？」と。

本投稿は Jens-Uwe Walther による記事 “Migrating Amazon EKS clusters from gp2 to gp3 EBS volumes” の日本語翻訳文です。翻訳文は CNCF アンバサダー いんだくたー氏より寄稿されました。 Kubernetes (K8s) はオープンソースのコンテナオーケストレーションエンジンで、Cloud Native Computing Foundation (CNCF) がホストする成長の速いプロジェクトです。K8s はオンプレミス上やクラウド上でステートフルからステートレスまでコンテナワークロードを動かすために広く採用されています。ステートフルワークロードでは永続ストレージが必要です。Kubernetes においては、ストレージやネットワークのようなオンプレないしはクラウドに固有のインフラ要素をサポートすることを目的として、旧来から「in-tree プラグイン」と呼ばれる構成要素がソースコード内部に含まれていました。ストレージやクラウドの事業者が新しいストレージシステムを追加したり、バグ修正や新機能を追加したい場合、これまでは Kubernetes のリリースサイクルに頼る必要がありました。このような Kubernetes のライフサイクルを事業者に固有の実装から開放するために、Container Storage Interface (CSI) の開発が始まりました。これは、Kubernetes のようなコンテナオーケストレーションシステム上でブロックストレージやファイルストレージを利用するための標準仕様です。これを通じることによって、顧客は Kubernetes の新しいバージョンのリリースを待つこと無く最新の CSI ドライバーの恩恵を受けられるようになりました。

AWS Graviton2 プロセッサは、64 ビットの Arm Neoverse コアを使用して AWS がカスタムビルドし、Amazon Elastic Compute Cloud（Amazon EC2）で実行されるクラウドワークロードに最高のコストパフォーマンスを提供します。幅広いワークロードに対して、同等の x86 ベースのインスタンスと比べて、最大 40% 優れたコストパフォーマンスを提供します。Intuit、SmugMug、Snap、F1、Honeycomb.io などの多くの消費者は、Graviton2 ベースのインスタンスを使用してワークロードを実行し、Amazon EC2 でのワークロードのコストパフォーマンスを向上させ、コストパフォーマンスを向上させています。

この記事は、Extend Amplify backend with custom AWS resources using AWS CDK or CloudFormation を翻訳したものです。 AWS AmplifyでAWS Cloud Development Kit(CDK)またはAWS CloudFormationを使用し、Amplifyが作成したバックエンドに175以上のAWSサービスを追加する新しいコマンドamplify add customが発表されました。カスタムリソースを追加する新しい機能により、開発者は1つのコマンドでAmplifyに組み込み済みのユースケース以外にリソースを追加できます。

8 月に最新世代のインテル Xeon スケーラブルプロセッサ (コードネーム Ice Lake) を搭載した汎用 Amazon EC2 M6i インスタンスを導入しました。このインスタンスは、全コアターボ周波数 3.5 GHz です。コンピューティング最適化 EC2 C6i インスタンスも先月利用可能になりました。 2021 年 11 月 22 日（米国時間）、第 6 世代の x86 ベースの製品を拡大し、メモリを最適化した Amazon EC2 R6i インスタンスを提供できることを嬉しく思います。 R5 インスタンスと比較した新しい R6i インスタンスの利点を簡単にまとめると、次のようになります。

AWS Japan ソリューションアーキテクトの堀内です。 先日 11/2(火) に CloudNative Days Tokyo 2021 （以降、CNDT2021）の Co-Located ハンズオンイベント にて、 “Security for Developers – DevSecOps on AWS” と “Amazon EKS Observability Workshop” の2つのハンズオンイベントを開催いたしました。

この記事は、Speeding up Windows container launch times with EC2 Image builder and image cache strategy を翻訳したものです。 本投稿は、Sr. Solution Architect – Microsoft Specialist の Marcio Morales により寄稿されました。 お客様から「コンテナイメージのサイズが原因で、Windows コンテナの起動が速くない」という話を何度も聞いたことがあります。これは部分的には真実ですが、「大きなイメージ」を解明し、ディスク上での高コストな操作 (前処理、原文では extract・ion という言葉を本記事では「前処理」としています) を回避し、Windowsコンテナの起動を高速化するためのキャッシュ戦略をどのように実施するかが重要です。