Amazon Web Services ブログ

Amazon QuickSight は最近、埋め込みオーサリング、マルチテナンシーの名前空間、カスタムユーザーアクセス許可、アカウントレベルのカスタマイズという 4 つの新機能を導入しました。Enterprise Edition で利用できる既存の ダッシュボード埋め込み 機能および API 機能と併用することにより、高度なダッシュボード機能と分析機能を SaaS アプリケーションに統合できるようになりました。これらのアプリケーションを構築する開発者や独立系ソフトウェアベンダー (ISV) は、組み込みの事前設定済み(予め用意された)ダッシュボードをすべてのエンドユーザーに提供できるようになり、高度なアドホック探索機能やダッシュボード構築機能もユーザーに提供できるようになりました。 本記事では、架空の ISV のユースケースとして、QuickSight を使うことで、インフラストラクチャのデプロイまたは管理を行うことなく、アプリケーションに簡単に分析を組み込み、数十万人のユーザーにスケールする方法を説明します。

先日 (2020/07/22) 開催しました AWS Black Belt Online Seminar「AWSアカウント シングルサインオンの設計と運用」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200722 AWS Black Belt Online Seminar AWSアカウント シングルサインオンの設計と運用 from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. AWS Single Sign-On (SSO) のアクセス権限セットですが、IAM ロールやグループ、ポリシーとは独立したものという認識で正しいですか？AWS Single Sign-On (SSO) の管理者がメンテする必要があるのかと思っています。 A. はい。アクセス権限セットは AWS Organizations マスターアカウントの IAM ロールやグループ、ポリシーとは独立したものになります。AWS Single Sign-On (SSO) の管理画面を通じて管理者が設定したアクセス権限セットに基づいて、メンバーアカウントのロールやポリシーが構成されます。 Q. AWS Organizations のマスターアカウントではなくメンバーアカウントで AWS Single Sign-On […]

先日 (2020/07/31) 開催しました AWS Black Belt Online Seminar「AWS App Mesh」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200721 AWS Black Belt Online Seminar AWS App Mesh from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. サービスメッシュはマイクロサービスアーキテクチャを構築する当初から導入すべきでしょうか？それとも、ある程度の規模になってから導入するべきでしょうか？ A. マイクロサービスアーキテクチャを採用したワークロードを新規構築する様な場合は、当初から導入することを検討いただければと思います。一方で、規模が小さい間からマイクロサービスアーキテクチャで構築するべきか？といった観点も必要になります。最初はモノリスで開発し、ある程度の規模になって運用の中でシステムのコンテキスト境界が見えてきた段階でマイクロサービスをサービスメッシュと合わせて検討する、といった例もございます。 Q. アプリケーション間の直接通信からサービスメッシュへ移行するためのコスト・タスク量について知りたいです。 A. サービスメッシュへ移行するためのマイグレーション手段はいくつか考えられますが、Envoy を導入したアプリケーションを別途作成し、既存のアプリケーションを縮退させる方法などが考えられます。上記の作業に関して、アプリケーションの規模や通信方式によって移行コストやタスク量が異なってきますので、まず、検証環境でマイグレーションを実施し、事前にコストやタスク量を見積もるよう推奨いたします。 Q. AppMesh と Istio の互換性について教えて下さい A. App Mesh と Istio は、サービスメッシュとしてのモデルや API に互換性はありません。 Q. AWS Lambda のネットワーク通信でも App […]

この記事でお知らせしたとおり、Amazon Macie で以前からご利用いただいていた Amazon Simple Storage Service (S3) アクティビティのための異常および脅威検知が Amazon GuardDuty の一部として強化され、コストも 80% 以上削減されました。これにより、GuardDuty の脅威検出の範囲がワークロードと AWS アカウントの枠を越えて拡大され、S3 に保存されるデータの保護にも役立つようになります。 この新しい機能は、通常とは異なる地理的場所から来るリクエスト、S3 ブロックパブリックアクセスなどの予防的な制御の無効化、または誤設定されたバケットアクセス許可を発見する試みと一致する API コールパターンなどの疑わしいアクティビティを検知するために、GuardDuty が S3 のデータアクセスイベント (通常データプレーンオペレーションと呼ばれます) と S3 設定 (コントロールプレーン API) のモニタリングとプロファイリングを継続的に行うことを可能にします。悪意があると思われる動作を検知するため、GuardDuty は異常検知、機械学習、および絶えず更新される脅威インテリジェンスの組み合わせを使用します。ご参考までに、GuardDuty S3 脅威検知の完全なリストをご覧ください。 脅威が検知されると、GuardDuty がコンソールと Amazon EventBridge に詳細なセキュリティ結果を生成します。これは、アラートをすぐに利用できるようにするとともに、アラートの既存イベント管理およびワークフローシステムへの統合、またはアラートによる AWS Lambda を使用した自動化された是正アクションのトリガーを容易にします。オプションとして、複数のリージョンからの結果を集約する、およびサードパーティーのセキュリティ分析ツールと統合するために、結果を S3 バケットに送信することもできます。 まだ GuardDuty をお使いではない場合は、サービスを有効にするときに S3 保護がデフォルトでオンになります。GuardDuty をお使いの場合は、GuardDuty コンソールで 1 回クリックする、または API […]

AWSに興味をお持ちのみなさん、こんにちは。ソリューションアーキテクトの小林です。 ついに梅雨も明け8月に入りました。素麺がおいしい時期がやってきましたね。毎年書いている気がしますが私は素麺が好きなので、この時期は素麺をヘビーローテーションすることになります。例年は「我が家の定番」的なめんつゆをカスタマイズすることにこっていたのですが、今年は趣向を変えてめんつゆ自体にこだわってみようと思います。同僚に聞いて見たりwebで調べたりするのですが、本当にたくさんの種類があり良さそうなものを選び出すのも一苦労ですね。めんつゆはそれなりの量で買うしか無いので、1食分だけ試すことが出来ないのが悩みです。めんつゆ試食セミナーとか、めんつゆトライアルセットとかがあれば良いなぁと思いながら、今日も素麺を茹でることでしょう。 それでは、先週の主なアップデートについて振り返っていきましょう。

“undifferentiated heavy lifting”という言葉をしばしば聞くことがあると思います。これは、競合他社との差別化にはなりえない作業にリソースを大量に消費することを言います。たとえば、サーバを構築し、OS にセキュリティパッチを適用するようなことです。このような作業は、より付加価値が高い製品やサービスを生み出すための活動から、ヒト・モノ・カネを奪い去ります。AWS では、お客様起点の重要な役割として、作業を簡素化し、自動化できるクラウドによるソリューションによって、開発者を”undifferentiated heavy lifting”から解放できるように支援しています。 金融業界では、過去20年間で大きな進歩を遂げています。たとえば、キャピタルマーケットの領域では、クラウドによるマーケットデータの活用により、トレーディングチームはリアルタイムでより良い洞察を導き出し、増え続けるデータからリスクをより効率的に計算できるようになりました。 しかしながら、いくつかの企業にとって、”undifferentiated heavy lifting”はまだ存在しています。それらの1つは、金融機関が規制機関や取引所によって設定された規制や業界ルールを遵守しなければならないことに関連しています。市場参加者は、これらの市場ルールを遵守する必要があり、遵守しない場合はペナルティを受ける場合もあります。 金融業界は、進化し続ける要件の複雑さと細分性が高まっている世界で最も規制の厳しい業界の1つです。しかし、金融機関がコンプライアンスに投資するすべてのリソースについて、多くは義務から機会への移行を行えていません。言い換えれば、ほとんどの金融機関では、同業他社との差別化を図るのではなく、ビジネスを行うためのコストとして、依然として規制やコンプライアンスを捉えています。 野球で例えるならば、プレイヤーはゲームのルールに従わなければなりませんが、優れたプレイヤーは、常に個人とチームの両方のレベルでパフォーマンスを改善するために戦略と戦術を使用しています。同様に、企業は規制要件に対応する必要がありますが、合理化、自動化、コスト効率の高い方法でそれに対応する必要があります。 このブログでは、日本取引所グループ (JPX) が AWS でどのように市場参加者にとってより良い顧客体験を生み出しているかをお話します。JPXは、これまでネットワークへのアクセスに関連していた”undifferentiated heavy lifting”を排除することで、市場参加者が新しいサービスのテスト、構築、立ち上げに向けてリソースを再利用できるようにしています。 JPXは、メンバー企業のクラウドでの市場アクセスを強化 2020年5月、JPX は市場参加者が AWS Direct Connect を介して、売買システムや清算決済システムなどにつながる高信頼ネットワークである arrownet にアクセスできるようにしました。 以前は、会員企業がarrownetに接続したい場合、JPXと自社のオフィスやデータセンター間に専用線を注文し、そのうえでネットワーク構築やセキュリティ対策を実施する必要がありました。このネットワーク構成は、変動する市場に迅速に対応するための信頼性と安定性が必要で、さらに十分な通信容量を提供する必要がありました。回線が接続されると、市場参加者は24時間365日体制で監視し、ハードウェア障害に対応するために人的リソースも投下する必要がありました。また専用線ベンダー側の監視にも、これらの重要なタスクのための人件費とサポート費も付属しています。つまり、arrownetへの接続は、利用者が長年にわたって対応してきた”undifferentiated heavy lifting”とも言えます。 JPXは、市場参加者からフィードバックを取り入れ、arrownetをクラウドに拡大し、市場参加者のアクセスを簡素化しました。市場投入までの時間が短縮され、マーケットからのデータを AWS 環境で扱うことで、マーケットの変動に対してオンデマンドで拡張できるようになります。 JPX は AWS Direct Connect の仮想インターフェイスを提供します。これにより、会員企業は短い期間でarrownetに接続して、テストすることができます。その結果、AWS の利用者は、以前は専用回線接続で直面していた”undifferentiated heavy lifting”な作業をすることなく、クラウド環境でマーケットからのデータを受け取ることができます。 現在の会員企業がこの合理化されたマーケットアクセスの恩恵を受けるだけでなく、FinTech スタートアップも恩恵を受けることができます。多くの Fintech スタートアップは AWS のサービスを使用しているため、彼らの既存の環境をより効果的に活用するには、クラウドネイティブ接続が必要でした。マーケットへの迅速なアクセスができるようになったFintech スタートアップは、新製品やサービスの市場投入までの時間をさらに短縮することができるでしょう。 現在、AWS Direct Connect により、JPX […]

  組織が多くの国で展開する多国籍企業であろうと、グローバルな成功を渇望している小さな新興企業であろうと、コンテンツを現地の言語に翻訳する課題にいつまでも悩まされることがあります。実際、テキストデータには多くの形式があり、それらを処理するにはさまざまなツールが必要になる場合があります。また、これらのツールはすべて同じ言語ペアをサポートしていない場合があるため、特定のドキュメントを中間形式に変換するか、手動翻訳に頼らざるを得ないこともあります。このような問題はすべて追加のコストを発生させ、一貫性のある自動翻訳ワークフローを構築することが不必要に複雑になってしまいます。 Amazon Translate は、こういった問題をシンプルで費用効果の高い方法で解決することを目指しています。Amazon Translate は、AWS コンソールまたは 1 回の API 呼び出しのいずれかを使用して、AWS のお客様が苦労することなくテキストを 55 の異なる言語と変異形に迅速かつ正確に翻訳できるようにします。 今年前半、Amazon Translate は、プレーンテキストと HTML ドキュメント用のバッチ翻訳を導入しました。本日、バッチ翻訳が Office Open XML 標準で定義されている Office ドキュメント、つまり、.docx、.xlsx、および .pptx ファイルもサポートするようになったことを発表します。 Office ドキュメント向けの Amazon Translate のご紹介 プロセスは非常に簡単です。ご想像のとおり、ソースドキュメントは Amazon Simple Storage Service (S3) バケットに保存する必要があります。20 メガバイトを超えるドキュメントや 100 万文字を超えるドキュメントは保存できません。 各バッチ翻訳ジョブは、単一のファイルタイプと単一のソース言語を処理します。したがって、S3 で論理的にドキュメントを整理し、各ファイルタイプと各言語に独自のプレフィックスを付けて保存することをお勧めします。 次に、AWS コンソールを使用するか、いずれかの AWS 言語 SDK で StartTextTranslationJob API を使用して、以下を渡して翻訳ジョブを起動できます。 S3 […]

Amazon CloudFront の新しいキャッシュポリシーとオリジンリクエストポリシーにより、CloudFront がリクエストデータを使用して、キャッシュキーとキャッシュミス時にオリジンに転送されるリクエストの両方に影響を与える方法をより詳細に制御できます。これにより CloudFront が実行するキャッシュの制御と効率を向上させながら、さらに柔軟性が高まります。これらの設定はすでに部分的には存在していましたが、キャッシュキーの設定はオリジン転送の設定から独立することになります。以前は転送されたデータのほとんどはキャッシュキーを自動的に変更していました。このポリシーにより、ほとんどのリクエスト要素をキャッシュキーに影響を与えることなくオリジンに転送できるようになります。ヘッダー、Cookie、およびクエリ文字列パラメータの任意の組み合わせを設定して、キャッシュキーとして考慮するよう含めたり、除外したり、必要に応じて転送したりできます。 基本的な設定の柔軟性の向上に加えて、これらのオプションは “ポリシー” を使用して設定されるようになりました。ポリシーでは、同様の設定の組み合わせを任意の数のディストリビューションに適用できます。これによりセットアップ時間が短縮され、複雑さが軽減されてチームは全体の設定にわたって一貫性を管理できます。

このブログシリーズでは、Commvaultを使用してSAPインスタンスを安全にバックアップおよびリカバリーするためのベストプラクティスを紹介します。現在、AWS上でSAPを稼働しているお客様は、SAPインスタンスのバックアップに様々なバックアップソリューションを利用できます。クラウドネイティブなAWSサービスを利用する場合もあれば、お客様の要件に基づいてCommvaultやNetBackupなどのエンタープライズバックアップソリューションを引き続き利用する場合もあります。

  発表内容 Amazon Fraud Detector が一般提供されました!🥳 2019 re:Invent での発表を逃したという皆さんのために説明すると、Amazon Fraud Detector は当初、2019 年 12 月 3 日にプレビューモードでリリースされました。その Amazon Fraud Detector が本日一般提供され、お客様にお試しいただけるようになります。 Amazon Fraud Detector とは Amazon Fraud Detector は、オンライン決済詐欺や偽のアカウントの作成など、不正行為の可能性があるオンライン活動を簡単に特定できるようにするフルマネージドサービスです。 毎年、オンライン詐欺のために世界中で数百億ドルの損害が出ていることをご存知ですか? オンラインビジネスを持つ企業は、偽のアカウントや盗まれたクレジットカードで行われた決済などの不正活動に絶えず目を光らせておく必要があります。  詐欺師を特定する試みのひとつは不正行為検出アプリの使用で、これらには機械学習 (ML) を使用するものもあります。 そこで登場するのが Amazon Fraud Detector です! これは、データ、ML、および Amazon の 20 年を超える不正検出の専門技術を用いて不正行為の可能性があるオンライン活動を自動的に識別するため、より多くの不正行為をより迅速に見つけることができます。Fraud Detector は ML に関する困難な作業のすべてを処理するため、ML 経験がなくてもほんの数クリックで不正検出モデルを作成することが可能です。 Fraud Detector の仕組み 「どんな仕組みになってるの?」と言われるかもしれません。🤷🏻‍♀️ よくぞ聞いてくださいました! では、これを […]