Amazon Web Services ブログ [発表] Lambda 関数が VPC 環境で改善されます 本投稿は AWS サーバーレス アプリケーションのプリンシパルデベロッパーアドボケートであるChris Munnsによる寄稿です。 元の投稿からの更新情報： 2019年11月28日（PST）：  次のリージョンに対して、元の投稿に記載されている改善を完全に展開しました：中東（バーレーン）。 2019年11月25日（PST）：次のリージョン、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中央）、EU（ロンドン）、EU（ストックホルム）、およびアジア太平洋（香港）に対して、これらのリージョンのすべてのAWSアカウントには、元の投稿で概説した改善を展開しました。 2019年11月6日（PST）：次のリージョン、米国西部（北カリフォルニア）、EU（アイルランド）、EU（パリ）、ア

Amazon Web Services ブログ Kinesis と DynamoDB をイベントソースにする際の AWS Lambda の新しいスケーリング管理 AWS Lambda は、Amazon Kinesis Data Streams と Amazon DynamoDB ストリームのイベントソースで利用可能な、新しいスケーリングパラメータを導入しました。Parallelization Factor は、各シャードにおける Lambda 関数呼び出しの同時実行数を増やす設定を可能にします。このパラメータは、デフォルトでは 1 です。これによって、処理されるレコードの順序を保証しながら、シャード数を過大にスケールすることなく、より高速なストリーム処理が可能になります。 一般的な最適化のシナリオには、高トラフィックと低トラフィックの2つがあります。たとえば、オンラインビジネスでは、季節的

本日より、AWS Lambda 関数の同期呼び出し、ホット行の競合、Backtrack、ハッシュ結合などの Amazon Aurora の多くの機能が Aurora の MySQL 5.7 互換エディションで利用可能になり、パフォーマンスと管理性が向上します。Amazon Aurora の MySQL 5.7 互換エディションは、JSON サポート、空間インデックス、生成された列などの機能強化をすでに提供しています。 AWS Lambda 関数の同期呼び出しを使用すると、Aurora MySQL データベースの機能を拡張し、データの変更に応じて動作する外部アプリケーションを呼び出すことにより、サーバーを考慮することなくコードを実行できます。

Amazon Web Services ブログ AWS Systems Manager Explorer – マルチアカウント、マルチリージョン対応のオペレーションダッシュボード アマゾン ウェブ サービスは 2006 年以来、IT インフラストラクチャの簡略化に努力してきました。Amazon Elastic Compute Cloud (EC2)、Amazon Simple Storage Service (S3)、Amazon Relational Database Service (RDS)、AWS CloudFormation など多数のサービスのおかげで、数百万ものお客様が AWS リージョンであればどこでも信頼性の高いスケーラブルでセキュアなプラットフォームをわずか数分で構築できるようになりました。10 年にわたって多数のハードウェアを調達、デプロイ、管理してきましたが、AWS

AWS Startup ブログ 技術選定、採用、マネジメント……。数多くの課題を CTO たちはどう乗り越えてきたか？ 【CTO Night & Day 2019 Day2のダイジェスト】 9 CTO Night & Day は、CTO や VPoE などの技術の立場から企業経営に関与するリーダー・マネージャーのための招待制オフサイト・カンファレンスです。 2014年から続くこのカンファレンスでは、参加者同士によるディスカッションや事例共有などを通じて、年齢や業種を超えた幅広い知識の交流が行われてきました。日常の業務から離れ、オフサイトならではの環境での交流を通じて、技術リーダー同士のコミュニティを活性化し、業界全体が発展していくことを目的としています。 2019年は、京都府京都市の「The SODOH」をメイン会場としてカンファレンスを開催。10月9日に行われた Day1 では、AWS

このブログ記事は、オープンソースの Redis 5 の記事シリーズにおける続きの記事です。この記事では Redis 5 のオープンソース版の新機能である Redis ストリームについて扱っており、Redis ストリームに関する 2 つ目の記事となります。Redis ストリームに関する最初の記事は、こちらから読むことができます。 ｢通常は Redis について話をするのです｣とメモリ内データベースの作成者である Salvatore Sanfilippo 氏は述べました。それから緊張感のある沈黙の後、｢しかし、今回は違います｣と付け加えました。 これは 3 年前の話です。 Sanfilippo は、パリで開催されたスケーラビリティに関する会議で、聴衆を前に話をしていました。Sanfilippo のプレゼンテーションは自身がリリースしたばかりのメッセージブローカー Disque についてのもので

Customers can now deploy to ECS from within a GitHub repository through the new ECS starter workflow on GitHub Actions. Whenever new code is pushed into a repository, the workflow builds and deploys it to AWS using 4 new GitHub Actions from the GitHub Marketplace. This speeds up the deployment process by automating each step and allows developers to push and test code in the cloud more efficiently

AWS News Blog New – Savings Plans for AWS Compute Services I first wrote about EC2 Reserved Instances a decade ago! Since I wrote that post, our customers have saved billions of dollars by using Reserved Instances to commit to usage of a specific instance type and operating system within an AWS region. Over the years we have enhanced the Reserved Instance model to make it easier for you to take ad

Amazon Web Services ブログ 新規 – Amazon CloudWatch anomaly detection – 異常検出  Amazon CloudWatch は、「AWS を使用して、高度でスケーラブルで堅牢なウェブアプリケーションをより簡単に構築できるようにする」という願い (当時の私の説明) の一環として、2009 年初めに開始されました。 私たちは長年にわたって CloudWatch の拡張を続けており、現在ではお客様がそれを使用してインフラストラクチャ、システム、アプリケーション、さらにはビジネス指標を監視しています。お客様はカスタムダッシュボードを構築、アラームを設定し、CloudWatch を使用して、アプリケーションのパフォーマンスや信頼性に影響する問題を警告しています。 CloudWatch アラームを使用したことがあれば、アラームのしきい値を設定

AWS News Blog New – Amazon CloudWatch Anomaly Detection Amazon CloudWatch launched in early 2009 as part of our desire to (as I said at the time) “make it even easier for you to build sophisticated, scalable, and robust web applications using AWS.” We have continued to expand CloudWatch over the years, and our customers now use it to monitor their infrastructure, systems, applications, and even bu

AWS News Blog Migration Complete – Amazon’s Consumer Business Just Turned off its Final Oracle Database Over my 17 years at Amazon, I have seen that my colleagues on the engineering team are never content to leave good-enough alone. They routinely re-evaluate every internal system to make sure that it is as scalable, efficient, performant, and secure as possible. When they find an avenue for impro

EC2 Linux インスタンスの統計に関する CloudWatch メトリクスの作成は、AWS コマンドラインインターフェイス (AWS CLI) でスクリプトを記述することで行えます。その後、そのメトリクスを CloudWatch にプッシュしてモニタリングできます。 作業を開始する前に、AWS CLI が、モニタリングの対象であるインスタンスと連携するようにインストール および設定されていることを確認しておいてください 。 カスタム CloudWatch メトリクスの作成 カスタムメトリクスの作成は以下のように行います。 1.AWS CLI からインスタンスにログインします。 2.次の Bash スクリプトをコピーし、インスタンス内に (例えば、mem.shなどの名称で) 保存します。 このサンプルスクリプトには、CloudWatch で発行できる値が記述されています。このサンプルで

Amazon Web Services ブログ 新機能 – 複数のインスタンスタイプをサポートする新しい EC2 Auto Scaling グループ & 購入オプション 今年はじめに EC2 フリートについてお話しました。EC2 フリートは、EC2 オンデマンドインスタンス、リザーブドインスタンス、複数の EC2 インスタンスタイプをカバーするスポットインスタンスを組み合わせるフリートを簡単に編成する AWS ビルディングブロックを指します。その記事でお話ししたのは、フリートの作成方法と、M4 および M5 インスタンスの組み合わせたゲノミクス処理パイプラインを作成した例についてでした。また、EC2 フリートを Auto Scaling および他の AWS サービスと統合することに取り組んでいることもお知らせしました。 複数のインスタンスタイプにわたる Auto Scaling とその購入

AWS Startup ブログ スタートアップのためのコンテナ入門 – AWS Fargate 編 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 前回「スタートアップのためのコンテナ入門 – 導入編」という記事を公開致しましたが、今回はスタートアップ企業に特におすすめな AWS Fargate についてご紹介します。 前回もお話しましたが、「そろそろコンテナやった方がいいか？」「なんとなく使い始めたけれどこれでいいのか？」「コンテナ自体は分かったけど、サービスでの利用に踏み切れていない」といった漠然とした課題感をお持ちの方は「スタートアップのためのコンテナ入門 – 導入編」から目を通して頂ければと思います。 ※ 本記事は Amazon ECS を前提に書かれております。（執筆時点では Amazon EKS に未対応であったためです。）Amazo

Amazon Web Services ブログ Amazon EBSのアップデート – 新機能エラスティックボリュームが全てを変える お客様からビジネスのダイナミックさと、それを実現するためのアプリケーションがブロックストレージに求めるものについてご意見をうかがうことは、いつも興味深いものです。ビジネス状況の変化に伴ってブロックストレージへの要求も変化し、容量を追加したり、性能特性の異なるボリュームが必要になったりすることもあるはずです。今日では、24時間運用され続けるシステムも珍しくはありません。結果として、ダウンタイムやシステム運用への影響なく変更作業を行えることがお客様にとって重要な要素となってきます。 我々は長年にわたり、お客様の様々なユースケースをカバーするために、EBSに新機能を追加し続けてきました。例えば、2016年にはスループット最適化HDD(st1)とコールドHDD(sc

AWS Well-Architected は、クラウドアーキテクトがさまざまなアプリケーションやワークロード向けに高い安全性、性能、障害耐性、効率性を備えたインフラストラクチャを構築する際に役立ちます。AWS Well-Architected では、6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性) に基づいて、お客様とパートナーがアーキテクチャを評価し、スケーラブルな設計を実装するための一貫したアプローチを提供しています。 AWS Well-Architected Framework には、ドメイン固有のレンズやハンズオンラボ、そして AWS Well-Architected Tool が含まれています。追加コストなしで AWS マネジメントコンソールで利用できる AWS Well-Architected Tool は、ワークロードの定期

2019年8月28日(日本時間)更新: 最初の事象概要で言及した通り、今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご

Amazon Aurora Multi-Master is now generally available, allowing you to create multiple read-write instances of your Aurora database across multiple Availability Zones, which enables uptime-sensitive applications to achieve continuous write availability through instance failure. In the event of instance or Availability Zone failures, Aurora Multi-Master enables the Aurora database to maintain read

Amazon Aurora Multi-Master は現在、一般公開されており、複数のアベイラビリティーゾーンにまたがって Aurora データベースの複数の読み書きインスタンスを作成できるようになりました。これにより、アップタイムに敏感なアプリケーションはインスタンスに障害が発生しても継続的な書き込みの可用性を実現できます。インスタンスまたはアベイラビリティーゾーンに障害が発生した場合、Aurora Multi-Master により、Aurora データベースはアプリケーションのダウンタイムなしで読み取りおよび書き込みの可用性を維持できます。Aurora Multi-Master を使用すると、書き込み操作を再開するためにデータベースのフェイルオーバーを行なう必要がありません。Aurora Multi-Master を使用して可用性の高い MySQL アプリケーションを構築する方法につ

Amazon EC2 または AWS Fargate で実行されている Amazon ECS サービスに、複数のターゲットグループをアタッチできるようになりました。ターゲットグループは、ロードバランサーの使用時に、登録されている 1 つ以上のターゲットにリクエストをルーティングするために使用します。サービスに複数のターゲットグループをアタッチすることにより、ECS サービスのインフラストラクチャコードの簡素化、コストの削減、管理のしやすさの向上を実現できます。 これまで、1 つの ECS サービスにアタッチできるのは 1 つのターゲットグループのみでした。そのため、内部および外部向けのアプリケーションや複数の Network Load Balancer からのトラフィックを配信し、複数のポートを公開するといったユースケースでは、サービスのコピーを複数作成する必要がありました。 今回、ECS