Category: Launch

Amazon CloudFront を使用すると、データ、動画、アプリケーション、API を低レイテンシーと高速転送速度で世界中の顧客に安全に配信できます。カスタマイズされたエクスペリエンスを可能な限り最小のレイテンシーで提供するために、今日の多くのアプリケーションはエッジで何らかの形式のロジックを実行します。エッジでロジックを適用するユースケースは、主に 2 つのカテゴリに分類できます。 最初のカテゴリは、オブジェクトがキャッシュにないときに実行される複雑な計算負荷の高いオペレーションです。私たちは、広範で複雑なカスタマイズを実装するための完全にプログラミング可能なサーバーレスエッジコンピューティング環境を提供するために 2017 年に Lambda@Edge を立ち上げました。Lambda@Edge 関数は、リージョンのエッジキャッシュで実行されます (通常は、クライアントがアクセスする CloudFront エッジロケーションに最も近い AWS リージョン内にあります)。たとえば、動画やオーディオをストリーミングする場合、Lambda@Edge を使用して適切なセグメントをすばやく作成して提供することで、オリジンのスケーラビリティの必要性を減らすことができます。もう 1 つの一般的なユースケースは、Lambda@Edge と Amazon DynamoDB を使用して、短縮されたユーザーフレンドリーな URL を完全な URL ランディングページに変換することです。 ユースケースの 2 番目のカテゴリは、非常に短命の関数で実行できるシンプルな HTTP(S) リクエスト/レスポンス操作です。このユースケースでは、パフォーマンス、スケール、費用対効果を備え、各リクエストで操作を実行できる柔軟なプログラミングエクスペリエンスが必要です。 この 2 番目のユースケースを支援するために、218 以上の CloudFront エッジロケーションで軽量の JavaScript コードを Lambda@Edge の 1/6 のコストで実行できる新しいサーバーレススクリプトプラットフォームである CloudFront Functions の提供が開始されました。 CloudFront Functions は、次のようなウェブリクエストの軽量な処理に最適です。 キャッシュキーの操作と正規化: HTTP リクエスト属性 (URL、ヘッダー、クッキー、クエリ文字列など) […]

Amazon S3 は今年初めに 15 歳になりましたが、 Amazon EC2 も数か月後に同様になります。本日は、AWS Identity and Access Management (IAM) の 10 歳の誕生日を祝いたいと思います。 最初の 10 年 それでは過去 10 年をふり返り、最も重要な IAM の歴史を見ていきましょう。 2011 年 5 月 – IAM をリリース。ユーザー、ユーザーのグループを作成し、ポリシードキュメントをいずれかにアタッチする機能を備え、15 種類の AWS のサービスをサポートしていました。AWS Policy Generator を使用すると、ポリシーを最初から構築でき、事前定義されたポリシーテンプレートを適度に備えたコレクションもありました。このローンチにより、IAM の標準が定まり、アクションとリソースに対するきめ細かなアクセス許可、ポリシーを有効にするタイミングを制御する条件の使用が可能になりました。このモデルは AWS とともに拡張され、現在も IAM の中心的な役割を果たしています。 2011 年 8 月 – 短期間の一時的 AWS 認証情報のサポートなど、AWS アカウントにフェデレーションすることで既存の ID を使用できる機能を導入しました。 2012 年 […]

従来のワークロードが引き続きクラウドに移行するため、一部のお客様は、通常はオンプレミスのファイルサーバーに保持されているデータをホストするクラウドネイティブなサービスを利用することができませんでした。例えば、チームやプロジェクトのファイル共有、またはコンテンツ管理システムで一般的に使用されるデータは、顧客の施設とクラウドの間でのレイテンシーが大きい、あるいは帯域幅が制限または共有されているという問題があるため、オンプレミスに常駐する必要がありました。 本日、 Amazon FSx ファイルゲートウェイを発表いたしました。これは、オンプレミスのファイルサーバーを引き続き使用および管理する代わりに、 Amazon FSx for Windows ファイルサーバーを使用してクラウドに保存されたデータにアクセスするのに役立つ新しいタイプの AWS Storage Gateway です。 Amazon FSX File Gateway はネットワークの最適化およびキャッシュを使用するため、共有データがオンプレミスにあるかのようにユーザーやアプリケーションに表示されます。ファイルサーバーデータを Amazon FSx for Windows ファイルサーバーに移動および統合することで、クラウドストレージの規模と経済性を活用し、オンプレミスのファイルサーバーの管理にかかわる非差別化されたメンテナンスを利用することができます。サーバーを使用できますが、 Amazon FSX ファイルゲートウェイ はレイテンシーと帯域幅に関する問題を解決します。 オンプレミスのファイルサーバーの置き換え Amazon FSx File Gateway は、オンプレミスのファイルサーバーを交換する際に考慮すべき理想的なソリューションです。低レイテンシーのアクセスにより、レイテンシーの影響を受けやすいオンプレミスアプリケーションを引き続き使用できます。また、キャッシュにより、オンプレミスとクラウド間の共有帯域幅が節約されます。これは、多数のユーザーがファイル共有データに直接アクセスしようとする場合に特に重要です。 すべて同じ Active Directory ドメインのメンバーであり、AD インフラストラクチャを AWS Directory Service でホストするか、オンプレミスで管理することが可能であれば、Amazon FSx ファイルシステムをアタッチし、ゲートウェイを介してアプリケーションとユーザーに提示することができます。 前述のように、お客様のデータは、フルマネージド型で、信頼性が高く、復元力のあるファイルシステムである Amazon FSx for Windows ファイルサーバーに存在し、ファイルサーバー、ストレージボリューム、およびバックアップのセットアップや操作に伴う複雑さを排除します。Amazon FSx for Windows ファイルサーバーは、完全なサーバーメッセージブロック […]

このブログはSteve Roberts (Developer Advocate focused on .NET and PowerShell development on AWS)によって執筆された内容を⽇本語化したものです。原⽂はこちらを参照して下さい。 従来のワークロードがクラウドに移行していく中で、一部のお客様は、データがオンプレミスのファイルサーバに保存されているため、クラウドの恩恵を十分に活かしきれていません。例えば、チームやプロジェクトのファイル共有、コンテンツ管理システムなどで一般的に使用されるデータは、お客様の拠点とクラウド間のネットワーク遅延、帯域の制限・共有などの問題により、オンプレミスに設置する必要があるからです。 今回、新しいタイプのAWS Storage GatewayであるAmazon FSx File Gatewayを発表します。これは、オンプレミスのファイルサーバーを運用する代わりに、Amazon FSx for Windows File Serverでクラウドに保存されたデータにアクセスすることを支援するものです。Amazon FSx File Gatewayは、ネットワークの最適化とキャッシングをしているため、ユーザーやアプリケーションからは、共有データがあたかもオンプレミスにあるかのように見えます。ファイルサーバーのデータをAmazon FSx for Windows File Serverに移行して統合することで、クラウドストレージの拡張性とコストメリットを活用し、オンプレミスのファイルサーバーのメンテナンスから解放され、Amazon FSx File Gatewayがネットワーク遅延と帯域の問題を解決します。

Amazon Redshift は、規模に関係なく、他のクラウドデータウェアハウスよりも最大 3 倍優れたコストパフォーマンスを提供します。これは、独自のハードウェアを設計し、機械学習 (ML) を使用することによって実現しています。 例えば、私たちは、2019 年の終わりに Amazon Redshift 向けの SSD ベースの RA3 をローンチしました (「Amazon Redshift Update – Next-Generation Compute Instances and Managed, Analytics-Optimized Storage」)。昨年 4 月 (「Amazon Redshift update – ra3.4xlarge Nodes」) と 12 月にノードサイズを追加しました (「Amazon Redshift Launches RA3.xlplus Nodes With Managed Storage」)。高帯域幅ネットワーキングに加えて、RA3 ノードには、洗練されたデータ管理モデルが組み込まれています。RA3 ノードのローンチでは、次のような記事を書きました。 各インスタンスには S3 でバックアップされた大容量の高性能 SSD ベースのストレージのキャッシュがあり、スケール、パフォーマンス、および耐久性を確保できます。ストレージシステムは、データブロックの温度、データのブロック、ワークロードパターンなどの複数のキューを使用して、キャッシュを管理して高性能を実現します。データは自動的に適切な階層に配置され、キャッシュやその他の最適化の恩恵を受けるために特別なことをする必要はありません。 多くのお客様が RA3 […]

2009 年に Amazon CloudWatch の立ち上げを行った際（Elastic Load Balancing、Auto Scaling、および Amazon CloudWatch の Amazon EC2 の新機能をリリース）、EC2 インスタンスのパフォーマンスメトリクス（CPU 負荷、ディスク I/O、ネットワーク I/O）を追跡し、それらを 1 分間隔でロールアップし、2週間にわたり保存しました。当時、パフォーマンスメトリクスは、インスタンスの状態をモニタリングし、 Auto Scaling をドライブするために使用されました。現在の CloudWatch は、はるかに総合的で洗練されたサービスになっています。最新の追加機能には、 すべての EBS ボリュームタイプに対して 1 分単位のメトリクス 、CloudWatch Lambda Insights、Metrics Explorer などが含まれます 。 AWS パートナーが CloudWatch メトリクスを使用して、あらゆる種類のモニタリング、アラート、コスト管理のためのツールを作成しました。パートナーはメトリクスにアクセスするために、それぞれの顧客の ListMetrics 関数と GetMetricData 関数の呼び出したポーリングフリートを作成しました。 これらのフリートは、各パートナーの顧客が作成した AWS リソースの数と、リソースごとに取得される CloudWatch メトリクスの数に比例して拡張が必要です。このポーリングは、各パートナーで行う必要のある単に差別化されていない手間のかかる作業です。この作業は、付加価値がなく、もし他のことに充てればより良い投資ができる貴重な時間を奪っています。 新しい Metric Streams AWS パートナーや他のユーザーが CloudWatch […]

ネットワーク内でアウトバウンド接続をする際には、通常、DNS ルックアップから始めます。セキュリティグループ、ネットワークアクセスコントロールリスト (ACL)、AWS ネットワークファイアウォールなどの AWS サービスを使うと、Amazon Virtual Private Cloud (VPC) のリソースとインターネットサービスが不必要に直接通信しないようにすることができます。これらの AWS サービスはネットワークトラフィックをフィルタリングしますが、パブリック DNS レコード、Amazon Virtual Private Cloud (VPC) 固有の DNS 名、および Amazon Route 53 プライベートホストゾーンに対する DNS クエリに自動的に応答している Amazon Route 53 Resolver に向けたアウトバウンド DNS リクエストはブロックしません。 DNS 漏洩により、DNS クエリを介して犯罪者が管理するドメインにデータが流出する可能性があります。例えば、犯罪者がドメイン「example.com」を管理しており、「sensitive-data」を流出させたい場合、VPC 内の犯罪者が侵入しているインスタンスから「sensitive-data.example.com」の DNS ルックアップを発行できます。これを防ぎ、不正行為による DNS ルックアップをフィルタリングするために、従来は各自が DNS サーバーを操作する手間が必要でした。 こういった DNS レベルの脅威を防ぐことができる Amazon Route 53 Resolver DNS Firewall (DNS […]

Amazon Elastic File System (Amazon EFS)では、シンプルかつサーバーレスで設定後の管理も不要の、伸縮自在なファイルシステムが利用できます。このファイルシステムは、Amazon Elastic Compute Cloud (EC2) インスタンス間で共有されるデータの他にも、各種のコンテナやサーバーレスサービス (Amazon Elastic Container Service (ECS)、Amazon Elastic Kubernetes Service (EKS)、AWS Fargate、およびAWS Lambda など) での使用が可能です。これまでお客様には、地理的に分離された複数のアベイラビリティーゾーン (AZ) にまたがりデータを冗長的に格納する、Amazon EFS 標準ストレージクラスにより、最高レベルの可用性と耐久性をご提供してまいりました。 今後は、Amazon EFS の 1 ゾーンストレージクラスにより、Amazon EFS標準ストレージクラスと比較して、ストレージコストを 47% まで削減することが可能になります。例えば、米国東部 (バージニア北部) リージョンにおいて、ライフサイクル管理を使用されておりデータの 80% へのアクセスが低頻度であるお客様の場合には、0.043 USD/GB (月間) というコスト効率の高いストレージをご利用いただけます。Amazon EFS は、非常に高い耐久性 (99.999999999％) を実現するために設計されています。EFS 1 ゾーンストレージクラスでは、可用性の SLA において 99.9 % が提示されていると同時に、伸縮性、シンプルさ、スケーラビリティ、ライフサイクル管理の使用など、標準ストレージクラスと同じ機能も維持されています。 当社では今回、新たに […]

AWS では、信頼性の高いシステムを構築するために必要とされるコンポーネントを各種提供しています。それらには、複数のリージョン (それぞれに複数のアベイラビリティーゾーンがあります)、Amazon CloudWatch (メトリック、モニタリング、アラーム)、Auto Scaling、Load Balancing、複数の形式のクロスリージョンレプリケーションを含む、多くの種類があります。これらのコンポーネントを、Well-Architected フレームワークに記載されているガイダンスに則って配置することで、個別のコンポーネントに障害が発生した場合でも、システムの連続稼働を期待できます。 しかし、適切な種類のテストを実行してみないことには、これらに確信を持つことはできません。カオスエンジニアリング (障害の達人こと Jesse Robbins が Amazon.com の初期の頃に行った先駆的な検証を基に、その後、Netflix のカオスモンキーによって強化された) の比較的新しい分野では、中断の原因となるイベントを作成しアプリケーションにストレスを加え、システムの応答を観察し、改善を行うということに専念します。カオスエンジニアリングは、改善の余地がある領域を指摘するだけでなく、追加のモニタリングやアラームを適用すべき盲点を発見し、目に付きにくい実装上の問題を明らかにします。さらに、ユーザーが運用スキルを向上させる機会を生み出すので、リカバリ時間の向上につなげられます。このトピックの詳細については、当社従業員の Adrian Hornsby による「Chaos Engineering – Part 1 (カオスエンジニアリング – パート 1)」を参照してください。 AWS Fault Injection Simulator (FIS) のご紹介 今回、当社は AWS Fault Injection Simulator (FIS) を発表いたしました。この新しいサービスは、AWS ワークロードに対し管理された形の障害を注入する実験を実施して、その場合の反応を確認するのに役立ちます。お客様は、さまざまな種類の障害にシステムがどのように反応するかを検証でき、障害モードをより良く把握することができます。運用前の環境での実験から開始して、その後 CI/CD ワークフローの一部として実行できるようにステップアップし、最終的には実稼働環境の中に移行できます。 AWS Fault Injection Simulator (FIS) による実験では、特定の AWS リソースのセットがターゲットになり、それらに対して一連のアクションが実行されます。このサービスの現在のサポート対象は、Amazon Elastic Compute Cloud […]

Graviton 搭載の EC2 インスタンスを 2018 年後半に開始し、その一年後に後続の Graviton2 プロセッサを発表しました。デュアル SIMD ユニット、int8 および fp16 命令のサポート、世代間でのその他のアーキテクチャの改良が組み合わさって、Graviton2 は非常に費用対効果の高い主力プロセッサになっています。 現在、汎用 (M6G および m6GD)、コンピューティング最適化 (C6G、C6gn、およびC6GD)、メモリ最適化 (R6G および R6GD)、バースト可能 (T4G) インスタンスから選択できます。すべて高速かつ効率的な Graviton2 プロセッサを搭載しています。当社のお客様は、これらのインスタンスを使用して、アプリケーションサーバー、ゲームサーバー、HPC ワークロード、ビデオエンコーディング、広告サーバーなどを実行しています。複数のベンチマーク (これとこれを含む) によると、これらの Graviton2 ベースのインスタンスは、既存の EC2 インスタンスよりも優れたコストパフォーマンスを提供することが示されています。 新しい X2gd インスタンス Graviton2 を搭載したインスタンスの増え続けるラインアップの最新情報を発表いたします。 新しい X2gd インスタンスは、メモリ最適化された R6g インスタンスと比べて vCPU あたり 2 倍のメモリ容量を持ち、メモリを大量に必要とするワークロードに合わせて設計されています。これには、メモリ内データベース (Redis と Memcached)、オープンソースのリレーショナルデータベース、電子設計オートメーションの設計と検証、リアルタイム分析、キャッシュサービス、コンテナが含まれます。 X2gd インスタンスは 8 つのサイズで利用可能であり、ベアメタル形式でも利用できます。仕様は以下のとおりです。 名前 […]