インフラ管理が不要 Amazon QuickSight は AWS により管理されており、追加のインフラストラクチャやプロビジョニングの必要がなく、数名から数万人へのスケール時にも自動的に拡張されます。また、ソフトウェアのインストール、アップグレードなどのソフトウェアメンテナンスは不要です。 高いコスト効果 支払いは実際に使用した分のみとなります。 Author / Reader の 2 種類のユーザタイプを用意しており、ユーザ毎に月単位で利用可能となりますが、年契約によりさらに低価格で利用可能です。また Reader 向けに提供される従量課金のセッション課金は、ユーザーがダッシュボードやレポートにアクセスした場合にのみ、そのセッション数（ 1 セッション:ログイン後 30 分間）に応じた課金となります。前払い料金、年間契約に加え、インアクティブ（一度もアクセスしない）なユーザーへの課金が

3月にAWSのSLA対象サービスが大量増加したので一覧表にまとめました。ほとんどのサービス（SimpleDBを含む！）にSLAが設定され、ほとんどのサービスで95%を下回った場合にサービスクレジットが100%返還となりました。 大栗です。 1月にAWSのSLA対象サービスが大量増加したエントリを書いたのですが、3月にもっと大量になって、全体的に内容も変わっていたので一覧表にまとめたいと思います。 AWS Service Level Agreements 著者の拙い英語力を基に調査しているため内容に不備があるかもしれません。詳細はSLAの本文（英語版）をご確認ください。 AWSにおけるSLA AWSのサービスレベルアグリーメントは基本的に、定義された可用性以上で使用できるようにするため商業的に合理的な努力をAWSがするものです。サービスレベルを"Assurance"（保証）ではなく"Agre

Nintendo Switch 2: Everything we know about the coming release

「Microservices時代の監視設計」と言うエントリーを書きたいのだけど、そもそもなんでMicroservicesで作る必要があるのかというところを先に書く必要があると感じたので私見を述べてみる。すでにMicroservicesで作っている人からすると「何をいまさら」と言う内容も多いかもしれません。 Microservicesでなぜ作るのか ドメイン分割のレイヤーの変遷 今は成長段階 Microservicesのメリットとアーキテクト クラウドはフレームワークになった 共有データベースアンチパターンとMicroservices設計 Microservices時代の監視設計 参考図書など Microservicesでなぜ作るのか 身も蓋もないことを書いてしまうと、これはもう「潮流がそうなっているから」ということだと思う。業界がそういうアプリケーションの作り方をしてノウハウを貯めていく流