Amazon Web Services ブログ

Amazon Forecast がサポートする自動補完機能による、ターゲットおよび関連データセット内での欠落した値の管理

Amazon Forecast は、機械学習 (ML) を使用する完全マネージド型サービスです。このサービスでは、ML の経験を必要とせずに非常に正確な予想を生成できます。Forecast が利用可能なユースケースは多岐にわたります。たとえば、製品需要の見積り、サプライチェーンの最適化、人事計画、エネルギー需要の予測、クラウドインフラストラクチャの使用状況の算定などが考えられます。 Forecast では、プロビジョニングすべきサーバー、あるいは手動で構築すべき機械学習モデルなどは存在しません。また、お支払いは実際に使用した分のみであり、最低料金や前払い料金を求められることはありません。Forecast の使用には、予想すべき数値に関する履歴データと、その予想に影響を与える可能性のある関連データが必要がなだけです。この関連データとしては、価格、行事、天候など、時間的に変化するデータや、色、ジャンル、地域など分類に関するデータなどがあります。このサービスは、用意されたデータに基づき、機械学習モデルのトレーニングとデプロイを自動的に行います。また、予想結果を取得するためのカスタム API も利用できます。 現実世界で予想を実施する際に一般的に見られる事象として、生データにおける値の欠落が挙げられます。履歴 (あるいは時系列の) データから値が欠落しているということは、すべての時点において対応した値が利用可能とは限らない、ということを意味します。値が欠落するには、多くの理由があります。たとえば、特定の時点でトランザクションが発生しなかったり装置にエラーがある場合、あるいは、測定自体が適切に実施されなかった場合などに、値の欠落が生じます。 Forecast では、関連あるいはターゲットの時系列データセット、および履歴上や予想期間における、欠落データ (既存の NaN も含みます) の自動補完機能をサポートしています。関連時系列 (RTS) データには、通常、プロモーションや価格もしくは在庫切れなどの、ターゲットの数値 (製品需要) と相関性がある情報が含まれています。これらにより、予想結果の精度が向上することが期待できます。欠落した値に関しては、value、median、min、max、zero、mean、および nan (対象が時系列の場合のみ) といった各種のロジックを、特定のユースケースに合わせ適用できます。Forecast では、CreatePredictor API の FeaturizationConfig により、これらの機能を提供しています。 今回の記事では、Forecast の GitHub レポジトリ からサンプルノートブックを入手して、関連がある、あるいはターゲットの時系列 (TTS) データセットに対し、欠落した値の補完機能を適用していきます。 Forecast における欠落した値の処理 時系列上で値が欠落しているということは、結局、多くの理由により、それ以降の処理のために対応した値が利用不可能になるということを意味します。製品セールスを表している時系列データが欠落していることは、その製品が販売不可能な状態にあると解釈できます。この状況としては、製品が存在しない期間 (リリース前や非推奨となった後など) 、もしくは、製品は存在するものの販売できない期間 (部分的な在庫切れ) などが挙げられます。また、ある期間にセールスデータが記録されなかった場合も、値の欠落が生じます。 「(not available for sale (販売中止)」というユースケースでは、一般的にターゲットの値が zero となりますが、そこで失われたはずの値 (nan) […]

Read More

新規 – 第 2 世代 AMD EPYC™ プロセッサを搭載した Amazon EC2 C5a インスタンス

過去 18 か月間において、当社は、お客様に汎用およびメモリ集約型のワークロードを実行するための追加の選択肢を提供するため、AMD を搭載した M5a と R5a/M5ad と R5ad、および T3a インスタンスをリリースしました。AWS Nitro System 上に構築されたこれらのインスタンスは、カスタムの第 1 世代 AMD EPYC™ プロセッサを搭載しています。これらのインスタンスは、同等の EC2 M5、R5、および T3 インスタンスよりも 10% 低い料金で利用可能で、コストとパフォーマンスに基づいてインスタンスミックスのバランスをとるためのオプションを提供します。 本日より、最大 3.3 GHz の周波数で動作する、第 2 世代 AMD EPYC™ プロセッサを搭載したコンピューティング最適化 C5a インスタンスの一般提供が開始されます。C5a インスタンスは、Amazon EC2 のコンピューティング最適化 (C5) インスタンスファミリーのバリアントであり、同等のインスタンスよりも 10% 低いコストで高性能な処理を提供します。C5a インスタンスは、バッチ処理、分散分析、データ変換、ログ分析、ウェブアプリケーションなど、コンピューティングを多用する幅広いワークロードに最適です。 現在、C5a インスタンスは、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、欧州 (フランクフルト)、アジアパシフィック (シドニー)、およびアジアパシフィック (シンガポール) リージョンにおいて、オンデマンド、スポット、およびリザーブドインスタンス、または Savings […]

Read More

Slack などのお客様が、リアルタイムコミュニケーションのために Amazon Chime SDKを選択しています

Amazon Chimeは、ミーティングやビデオ会議を行うためのサービスです。開発者は、Amazon Chime SDKを使うことで、Amazon Chimeと同じコミュニケーションインフラストラクチャを利用して、音声、ビデオ、画面共有などの機能をアプリケーションに直接追加できます。re:Invent 2019でAmazon Chime SDKが発表されて以来、多くのお客様がこのSDKを使用して音声やビデオを自社のビジネスプロセスに組み込んできました。例えば、オンラインコンサルティング、オンライン診療、不動産のオンライン内見会といったユースケースにこのSDKを使用しているお客様がいます。このようなお客様にとって、ビデオ映像は、単にビデオ会議で使われるものではなく、自社のアプリケーションコンテキストに深く組み込まれる重要な機能となっています。最近、Slack社は リアルタイムコミュニケーションを強化するため、Slackコールの機能要素として Amazon Chime SDKを選択し、今週ロールアウトを開始しました。

Read More

Perforce Helix Core を AWS 上に構築する (Part3)

イントロダクション 3回にわたるAWSでのPerforce構築シリーズもこれで最後になりました。 Part1ではAWS 上で Perforce Helix Core を構築することの利点と技術的ポイントを俯瞰しました。 前回のPart2では AWS CloudFormation を用いてPerforceサーバーを構築する方法を解説しました。 今回のPart3では、Part2の手順7、CloudFormationの設定において「Enable Replica」をYesにしてReplica Serverの構築を有効にした場合のReplica ServerのSetup手順を紹介します。 Part2の手順で、Master Serverのみの構築を希望した場合は、こちらの手順は必要ありません。 もちろん、もう一度前回の記事の手順を最初からやり直して、Replica構築を有効にして、本記事の手順を実行していただくこともできます。 さて、実際の Replica server の構築手順ですが、これはAWS特有というわけではなく、Perforceの通常の構築手順に従って手動でコマンドを実行して行くというものになります。 それでは実際に手順を見ていきましょう! 事前準備 こちらのPart2の手順を実行していることが前提になります。実行されていない方はまずは前回の記事の手順を実行し、その際に必ず「手順7」の「Enable Replica」をYesにして有効にします。 こちらを参考にして東京リージョンで任意の名前のS3バケットを用意しておいてください。S3バケットの名前は全世界で一意の名前にする必要があります。 例えば次のようなS3バケットの名称にすると他のバケット名との衝突を避けることができます。 (例) perforce-test-[自分の名前]-[日付] など Replica Serverをセットアップする Replicaの動作を定義するには、Perforceのコマンドである“p4 configure set”コマンドを使用して、Master serverのdb.configファイルに構成情報を入力する必要があります。Replicaを作るにはまず最初にMaster serverを設定します。Master serverの設定が、後でReplica serverに複製されます。 Mater Server側で設定を行う まずは、Master Serverにsshログインします。下記では適宜、自分のssh keyとEIPアドレスに置き換えてください。 $ ssh -i ~/.ssh/general-key.pem p4admin@18.180.250.162 前回Part2でp4adminユーザーをサーバー側に作成していない場合は作成します。作成済みの場合はスキップして次に進みます。下記のコマンドを実行するとviが起動しますので内容を確認して、「:wq」をタイプして保存します。 [p4admin@master ~]$ p4 […]

Read More

AWS上でどのようにゼロトラストアーキテクチャを考えていくか

厳しい規制への対応やリスク回避を考慮事項として擁するお客様は、レガシーアプリケーションのリファクタリングや新しいアプリケーションのデプロイに際し、ゼロトラストアーキテクチャに関心を向けることがあります。このブログでは、お客様がお客様のアプリケーションを評価し、ゼロトラストの原則とAmazon Web Services (AWS)を利用して安全でスケーラブルなアーキテクチャを構築するための手助けを行います。 ゼロトラストとは? ゼロトラストセキュリティとは、アプリケーションのコンポーネントやマイクロサービスが互いに分離しており、どのコンポーネントやマイクロサービスも他のコンポーネントやマイクロサービスを信頼していないというモデルです。これは、あらゆるソースからの入力を潜在的に悪意のあるものとみなすように設計されたセキュリティの考え方です。基礎となる内部ネットワーク・ファブリックを信頼しないことから始まり、さらにすべてのマイクロサービスにおける入力と出力の評価におよびます。加えて、個々のコンポーネント、マイクロサービス、またはアイデンティティの侵害から保護するために、多層防御アプローチを設計することも含まれます。 (訳者注:ゼロトラストは特定の製品やソリューションを指すものではなく多層的なセキュリティ手法を踏まえた概念として、現在アメリカ国立技術標準研究所(NIST)においても、SP800-207(本blog執筆時点においてはドラフト)として定義化が進められています。) 伝統的なネットワークセキュリティの設計は、セキュリティの境界に依拠します。境界内のすべてのものは信頼され、境界外のものは信頼できないものとみなされます。ゼロトラストネットワークは、ビジネスデータや機密リソースへの意図しないアクセスのリスクを低減するために、リアルタイムですべてのアクションとリソースを評価します。 ゼロトラストの原則を用いたAWS上での設計 ゼロトラストアーキテクチャをよりよく理解するために、脅威モデリングにより、従来のアーキテクチャやクラウドネイティブアーキテクチャとを比較してみましょう。脅威モデリングは、ユーザーはすべての潜在的な攻撃の可能性を評価してリスクを定義し、管理策を決定するための試みです。脅威モデルの一つであるSTRIDEでは、以下のようなカテゴリの脅威を特定しています。 ユーザーIDのなりすまし(Spoofing) データの改ざん(Tempering) ソースの否認(Repudiation) 情報漏洩(Information Disclosure) サービスの拒否(Denial of Service) 特権の昇格(Elevation of Privilege) AWSのベストプラクティスアーキテクチャ AWSでは、AWS上でWell-Architectedなアプリケーションを設計するための基礎となるツールを提供しています。AWS Well-Architected Frameworkは、AWSのベストプラクティスとワークロードを比較し、安定的かつ効率的なシステムを構築するためのガイダンスを得るための戦略を紹介しています。Well-Architected Frameworkには、セキュリティを含む5つの明確な柱が含まれています。このフレームワークを基に、ゼロトラストをAWSアーキテクチャに適用した例としてWebアプリケーションを考えてみましょう。 図1: Webサイトホスティングの例 表現されているアーキテクチャは、セキュリティを考慮したWell architectedの一例です。システムは、以下のサービスを活用して一般的な攻撃ベクターから保護されています。 Elastic Load Balancing (ELB)/Application Load Balancer (ALB)による負荷分散により、複数のアベイラビリティゾーンとAmazon Elastic Compute Cloud (Amazon EC2) Auto Scalingグループに負荷を分散し、サービスの冗長化と疎結合を実現します。 AWSのSecurity Groupを利用した仮想ファイアウォールでは、インスタンスにセキュリティを移動させ、Webサーバとアプリケーションサーバの両方にステートフルなホストレベルのファイアウォールを提供します。 Amazon Route 53を利用したDNS(Domain Name System)はDNSサービスを提供し、ドメイン管理を簡素化します。 Amazon CloudFrontによるエッジキャッシングにより、顧客へのレイテンシが減少します。  AWS Web […]

Read More

【開催報告】ISV/SaaS事業社向けAWS研修 : 今日から一緒にはじめよう!IT基礎知識 & AWS超入門セミナー

こんにちは!アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの加治(@Anorlondo448)です。 6/5, 6/12, 6/17, 6/25の4回に渡って、ISV/SaaS事業社向けAWS研修の第1弾となる「今日から一緒にはじめよう!IT基礎知識 & AWS超入門セミナー」を開催しました!こちらの開催報告と合わせてセミナーの内容の紹介や、今後開催される予定の研修内容について紹介したいと思います。 ISV/SaaS事業社向けAWS研修とは? 「SaaSと言えばAWS!」をスローガンに、複数回に渡ってISV/SaaS事業者様に向けてのAWS研修を実施します。 AWSでSaaSとして事業を展開されているお客様、これから構築を検討されているお客様が「SaaS on AWS」でさらに価値のあるサービスを提供できるようにサポートしていきます! まずは第1弾、6月は超入門編として「今日から一緒にはじめよう!IT基礎知識 & AWS超入門セミナー」を開催しました。 7,8月にはAWSの初級ハンズオンを企画中です。是非同僚お誘いあわせの上ご参加くださいませ!この6〜8月のセミナーは職種を問わず、AWSを今後ご利用される可能性のある方全てに向けたセミナーとなっておりますので、エンジニア職以外のマーケティング担当の方や営業担当の方もご参加頂けるとAWSについてご理解頂けると思います。 9月以降はエンジニア職の方に向けた中級〜上級ハンズオンを実施予定です。こちらはAWS上でスケーラブルなWebアプリを構築するハンズオンや、Container/Serverless/Mobileに特化したハンズオンを実施する予定です。 全てを受講していただくことをお勧めしますが、必ずしも全てを受講頂く必要はございません。 ご希望に合わせてコンテンツを選択頂ければと思います。 第1弾はWebサービス入門とAWS超入門 前半のWebサービス超入門はこれからクラウドを学んでいく方のために、Webサービスの概要や、基礎的な知識、発生する課題、クラウドの魅力について、Webサービスを支える基盤の目線から解説しています。もしかしたら参加者の中にはデータセンターやサーバラックを見たことが無い、という方もいたかもしれません。実際にこれらを知らなくても、クラウドがなぜ生まれたのか、クラウドが解決できる課題についてご理解頂けるようにイメージしてもらえる内容にしております。 後半のAWS超入門は、AWSがどのように生まれたのか?どのように進化しているのか?という点から、様々な業界で実際にAWSを利用してサービスを提供されている事例、AWSのサービスの紹介など、AWSをこれから知っていただくための第一歩の内容となっております。また今後どのようにAWSを活用していけばよいのか?どのように学んでいけばよいのか?わからない場合にどうすればよいのか?など、具体的な次の一歩についても紹介しております。 当日の模様 6月の4回開催でトータル626名の方にご参加いただきました。セミナー中には多くの質問も頂き、またSNS上(#SaaSonAWS)でも多くの投稿がありました^^ オンライン開催では中々皆様の顔が見えにくいところではありますが、今後のセミナーをより良いものにしていきたいと考えておりますので、バンバンFeedbackを頂ければと思います! たくさんのご質問をいただき皆様からの強い興味や熱い想いを感じることができました!回答を行ったISV/SaaS SAチームも大変大盛り上がりでした! 参加されたお客様の声 “難しい内容をわかりやすく説明していただき、技術担当ではない自分でもAWSを身近に感じることができました。” – 株式会社ゼンリンデータコム 人事部 副部長 藤田 綾子様 – “AWSでどんな事が出来るのか、可能性があるのかを説明していただき、 導入後も機能の成長、技術的な支援(コミュニティなど含む)が充実し安心して進めれると感じました。 是非、導入検討時には選定対象のサービスにします。ありがとう御座いました。” – 大興電子通信株式会社様 – “デモの実演や実際の構築例の話、AWSの勉強方法などイメージが掴みやすく、 有益に感じました。質疑応答時間とチャットで質問できることが一番面白かったです。 今後、初級・中級〜と進んでいくハンズオンがあるらしいので今から楽しみです” – 株式会社スカラコミュニケーションズ様 –   第2弾はAWS初級ハンズオン! 次回は7,8月に「AWS初級ハンズオン」を予定しております。 ハンズオンとなっておりますが、エンジニア職以外の方も対象とし、AWS上で簡単なアプリケーションを構築しながらAWSの楽しさを体感していただくことを目的としております。 こちらも複数回開催される予定ですので、ご都合の合う日程にて参加頂ければと思います!   […]

Read More

ユーティリティにおけるAWS IoTを用いた分析・可視化(北海道ガス株式会社の事例)

電気ガス水道などの公共事業において、設備をIoT化しクラウドと連携する動きは、日々加速しています。 ユーティリティ設備においてクラウドに繋がることによるメリットとしては、主に以下のようなものが挙げられます。 省人化によるコスト削減 点検、保守など、人が行っている作業の自動化・半自動化することによって、コスト削減が図られるケースがあります。例としては、保守が必要なタイミングをシステムが判断することで、施設への訪問回数の削減を行ったり、設備のリモート操作を可能にすることにより、訪問自体を無くすことが挙げられます。 新たな付加価値を利用者に提供 ガスの使用量などの情報を紙ではなく、電子化し、スマートフォンやPC上でいつでも確認できるようにしたり、ユーザーの利用傾向をインテリジェントに分析し、最適なプランや利用料を下げる方法があります。 この投稿では、一つの事例として、北海道ガス株式会社(以下、北ガス(読み方:キタガス))様の例を取り上げます。北ガス様は、AWS IoTのサービスを活用することで、大規模なインフラ構築の投資不要で、高速にPoCを実施しています。北ガス様の抱える課題と、その課題解決のためにどのようにAWS IoT のサービスを活用しているかについて、技術的な視点でご紹介したいとおもいます。 エネルギーサービス事業における課題 北ガス様は、北海道エリア内にて都市ガス事業・電力事業を主なビジネスとして手がける総合エネルギーサービス事業者です。持続可能な社会を支え、北海道に最適なエネルギー社会を創造するべく、ガス、電気、熱、再生可能エネルギーの最適利用と、デジタル技術の高度活用を通じて「持続性」「環境性」「経済性」に優れた新たなエネルギーシステムの構築を目指しています。近年では、デマンドサイドのエネルギーマネジメントによる省CO2・省エネルギーの推進を図るとともに、電気・冷温水を供給するエネルギーセンターを構築し、特定エリア内におけるエネルギーマネジメントを行うCommunity Energy Management System (CEMS)を導入・運用するなど、エネルギーに関わる広範なサービス事業を展開しています。 総合エネルギーサービス事業の展開にあたり、業務用分野においては、お客さまのガスや電気の使用量実績を把握するだけではなく、ボイラーや空調機器、暖房機器等、お客さまが実際に機器をどのように使い、室内環境がどのように変化したのかを把握するデマンドサイド(需要家側)のデータ収集が求められていました。 業務用機器を含むエネルギーシステムは、機器単体の性能・効率向上だけではなく、エネルギーシステム全体として、需要家側の最適利用や省エネを図る必要があり、こうした運用は需要家側に任されております。しかし、積雪寒冷地の北海道では、季節によってエネルギー負荷が大きく変化するため、需要家側で最適な運用ができていないケースが散見されていました。 お客さまの最適運用・省エネを支援するため、機器データや室内環境データを把握することは重要な取り組みと位置付けておりましたが、測定した様々なデータをクラウドにどのように集め、蓄積し、可視化するかに関しては、知見に乏しく、多くの課題がありました。 アーキテクチャの検討 この件に限らず、データ分析や機械学習のワークロードを進めるうえでは、過去の大量のデータが必要となる場合が多くあります。一方で、これからIoT化を進めるケースでは、過去のデータが存在しないケースがほとんどです。さらに、エネルギーサービスなどで分析に使える実データを集めるためには、季節変化等も考慮する必要があるため、データ収集には長い期間が必要となります。 今回のケースにおいても、最初に着手するべき事項として、データを集めて蓄積する部分に焦点を絞り、データ収集・分析基盤のアーキテクチャ設計と構築をすすめました。設計議論における観点は以下のようなところです。 保守・運用にかかる作業を最小化したい。コストを抑え、短期間でPoCを完了させ、次のステップへ進みたい。 蓄積したデータに対して、今後様々な活用が可能な状態にしたい。例えば機械学習やBIツール等を使う可能性を視野に入れる。(具体的な活用方法はこれから考えたい。) デバイスの設置場所は、Wi-Fiなどのインターネット環境が無い場合を想定している。 これらのポイントを考慮したうえで、以下のようなアーキテクチャを設計しました。 ハードウェア・通信環境 このPoCでは、上述のとおり、データの蓄積を主眼としているため、新たなハードウェアの開発は行わず、市販のデバイスを組み合わせてハードウェア環境を構築しています。クラウドへの通信、およびエンドポイントにはSORACOMを用い、そこからAWS IoT Coreへすべてのデータを送信しています。1つのゲートウェイに接続されている複数のセンサー情報が、1つのJSONドキュメント形式でまとめられており、それが一定時間間隔で送られます。 SORACOMからIoT Coreへのデータ送信では、クラウドリソースアダプタであるSORACOM Funnelを利用しています。ゲートウェイからのデータは、SORACOM Funnelを介して、アクセスキー認証によるHTTPS通信によりIoT Coreへ送信しています。本構成では、SORACOM Platform 上で認証情報を管理することで、物理的なハッキング対策を講じるとともに、ゲートウェイからSORACOM Platformまでは閉域網で通信することで、セキュアなIoTシステムを構築しています。 IoT Coreに送られたデータは、IoT Coreのルールエンジンによって、AWS IoT Analyticsへと送信されます。ルールの設定は数クリックで可能であり、SORACOMからIoT Coreへ送られるすべてのメッセージをIoT Analyticsに送る設定を行いました。今回のPoCで作成したルールは1つのみですが、ルールを増やすことによって、例えば、IoTデバイスから届いたデータの値が一定値を越えた場合にE-mailなどでアラートを通知したり、アプリケーション用のデータベースを更新するなど、柔軟に拡張することが可能です。 さて、IoT Analyticsにデータが届くと、IoT Analyticsは内部で、送られてきたJSONをパースし後段の分析で利用可能な形式への変換を行います。ここでは、IoT Analyticsのパイプラインに Lambda Activity を追加し、データが一定量もしくは一定期間蓄積されたら自動的にLambdaを呼び出す設定を行いました。Lambda関数の中で、JSONオブジェクトから必要なデータのみを抽出し、1つのオブジェクトに含まれる複数のセンサーデータの情報を配列に変換し、データストアに保存するようにしました。 分析 IoT Analyticsでは、データソースおよびデータセットの保存先としてS3を選択しています。S3を選択することにより、将来的にAthenaやGlueなどの分析系のサービスや外部ツールを利用し、より高度な分析も行うことが可能になります。 […]

Read More

IoT@Loft #10 スマート工場(IIoT)に向けた課題と取り組み 〜見える化、予知保全、品質管理〜 vol.2

IoT@Loft の第10回目は「スマート工場(IIoT)に向けた課題と取り組み 〜見える化、予知保全、品質管理〜 vol.2」をテーマに、2回目となるオンライン開催を行いました。 工場のIoT 化は、予知保全、生産性向上、デバイス管理、設備の安全管理など多岐にわたり、収益向上やコスト削減を実現しています。今回、様々な分野で工場のスマート化にご尽力されているエンジニアの方々にご登壇頂き、現場の課題とそれに応えるソリューション事例などをご紹介頂きました。また、IoT@Loftでスマート工場をテーマにするのは今回が2回目となります。前回スマート工場をテーマに実施したIoT@Loftの情報や登壇者の方の資料はこちらにあります。さらにこれまでのイベントまとめ記事はこちらにありますので、合わせて確認してみてください。 この回では、目視検査を AI で自動化する取り組みについてシーシーエス様に、工場オペレーションを管理するアプリケーションについて丸紅情報システムズ様に、そして製缶ラインの高速機械をIoT化した取り組みについて東洋製罐様にお話いただきました。また、AWSからはスマートファクトリーを実現する AWS の IoT ソリューションについて紹介しました。

Read More

S3 バケット間で既存のオブジェクトをレプリケートする

 お客様は、そのビジネス要件またはエンタープライズポリシー上、既存の Amazon S3 オブジェクトの追加コピーを求められることがよくあります。Amazon S3 レプリケーションは、新しくアップロードされたオブジェクトを S3 バケット間でレプリケートするために広く使われていますが、S3 バケット間で既存のオブジェクトを多数レプリケートする最も簡単な方法をまだご存知ではないお客様が数多くいらっしゃいます。この記事では、Amazon S3 レプリケーションを使用して既存のオブジェクトのクロスリージョンレプリケーションをトリガーする方法を説明します。 Amazon S3 レプリケーションは、オブジェクトをある Amazon S3 バケットから別のバケットにコピーするための、低コストで柔軟なマネージド型ソリューションです。Amazon S3 レプリケーションでは、Amazon S3 Cross-Region Replication (CRR) を使って、異なる AWS リージョンをまたいで S3 オブジェクトを自動的にレプリケートするルールを設定できます。または、Amazon S3 Same-Region Replication (SRR) を使用して、同じ AWS リージョン内のバケット間でオブジェクトをレプリケートするルールを設定できます。 お客様は、AWS サポートに連絡してこの機能をソースバケットに追加することにより、同じ AWS リージョン内または異なる AWS リージョン間の別のバケットに既存のオブジェクトをコピーできます。ソースバケットで既存のオブジェクトのレプリケーションのサポートを有効にすると、お客様は、新しくアップロードされたオブジェクトに加えて、既存のすべてのオブジェクトに対して S3 レプリケーションを使用できるようになります。レプリケーションプロセスが完了すると、お客様はすべてのオブジェクトが含まれる 2 つのバケットを持つことができ、新しくアップロードされたオブジェクトは宛先バケットにレプリケートされます。 既存のオブジェクトのレプリケーションは、既存の S3 レプリケーション機能を拡張したものであり、同じ機能がすべて含まれます。これには、メタデータ (オブジェクトの作成日時など) を保持しながらオブジェクトをレプリケートしたり、オブジェクトを異なるストレージクラスにレプリケートしたり、異なる所有権でオブジェクトのコピーを保持したりする機能が含まれます。Amazon S3 Replication Time Control […]

Read More

Okta Universal Directory と AWS 間のシングルサインオン

 AWS クラウドを採用している企業は、ID を効果的に管理したいと考えています。ID を一元的に管理することで、ポリシーの適用、アクセス許可の管理が容易になり、複数の ID サイロ間でユーザーとユーザー許可をレプリケートする必要がなくなるため、オーバーヘッドを削減できます。一意の ID を使用すると、ユーザーである私たち全員のアクセスも簡素化されます。私たちは皆、複数のシステムにアクセスできます。また、複数のパスワードを覚えておくのに苦労しています。ユーザー名とパスワードの単一の組み合わせを使用して複数のシステムに接続できれば、日々のセキュリティと生産性が向上します。あるシステムの ID を別の信頼できるシステムで管理されている ID にリンクできることを「ID フェデレーション」といいます。これは、シングルサインオンのサブセットです。ID フェデレーションは、セキュリティアサーションマークアップランゲージ (SAML)、OAuth、OpenID などの業界標準のおかげで可能になりました。 最近、AWS Single Sign-On が進化したことを発表しました。これにより、AWS ID を Azure Active Directory ID とリンクできるようになりました。進化はそこで止まりませんでした。今日、AWS Single Sign-On と Okta Universal Directory の統合を発表します。 この記事では、システム管理者向けのエクスペリエンスを紹介してから、ユーザー向けのシングルサインオンエクスペリエンスをご紹介します。 まず、私がすでに Okta Universal Directory を使って従業員 ID を管理している企業の管理者であるとします。次に、ユーザーのために、その既存の ID を使用して、AWS 環境へシンプルで難なくアクセスできるようにしたいと考えています。ほとんどの企業と同じように、私は複数の AWS アカウントを管理しています。シングルサインオンソリューションだけでなく、AWS アカウントへのアクセスを一元管理したいと考えています。Okta グループとユーザーメンバーシップを手動で複製したり、複数の ID システム (Okta Universal Directory […]

Read More