データ保持ポリシーへのコンプライアンスを強化するために、個々の Amazon Elastic Block Store (Amazon EBS) スナップショットをロックできるようになりました。ロックされたスナップショットは、ロックの有効期限が切れるか、またはロックが解除されるまで削除できないため、意図しない削除や、ランサムウェア攻撃などの悪意のある削除から、重要なバックアップを安全に維持できます。 ロックの必要性 AWS のお客様は、バックアップ、ディザスタリカバリ、データ移行、コンプライアンスのために EBS スナップショットを使用しています。金融サービスやヘルスケア分野のお客様は多くの場合、所定の保持期間にわたって特定のコンプライアンス要件を満たす必要があるほか、スナップショットが真に Write Once Read Many (WORM) であるようにする必要もあります。これらの要件を満たすために、お客様は、複数の AWS アカウントを使用し、それらの間に一方向の「エアギャップ」を備えたソリューションを実装しました。 EBS スナップショットロック 新しい EBS スナップショットロック機能は、カスタムソリューションを必要とせずに、保持とコンプライアンスの要件を満たすのに役立ちます。1 日から約 100 年の範囲で設定できるロック期間を使用して、新規および既存の EBS スナップショットをロックできます。スナップショットは指定された期間にわたってロックされ、削除することはできません。 次の 2 つのロックモードが用意されています。 [ガバナンス] – このモードは、すべてのユーザーによる削除からスナップショットを保護します。ただし、適切な IAM 許可がある場合は、ロック期間の延長または短縮、ロックの削除、[ガバナンス] モードから [コンプライアンス] モードへのモード変更が可能です。 [コンプライアンス] – このモードは、ルートユーザーおよびすべての IAM ユーザーによるアクションからスナップショットを保護します。最大 72 時間のクーリングオフ期間が経過した後は、ロック期間が経過するまでスナップショットとロックのいずれも削除できず、モードを変更することもできません。適切な IAM 許可がある場合、ロック期間を延長することはできますが、短縮することはできません。 どちらのモードでも、スナップショットを共有またはコピーすることはできます。これらは、低コストの Amazon EBS Snapshots Archive 層にアーカイブできます。また、既にアーカイブされたスナップショットにロックを適用できます。 スナップショットロックの使用 EBS コンソールからスナップショット (Snap-Monthly-2023-09) を選択し、 [アクション] メニューの [スナップショットの設定] から [スナップショットロックを管理] を選択します。 これは月次スナップショットであり、私はこれを 1 年間ロックしたいと考えています。 [ガバナンス] モードを選択し、期間を選択してから、 [ロックの設定を保存] をクリックします。 このスナップショットを削除しようとすると、次のように削除が失敗します。 次に、 [コンプライアンス] モードを使用して、年次スナップショットの 1 つを 5 年間ロックしたいと思います。 考えが変わった場合に備えて、クーリングオフ期間を 24 時間に設定します。おそらく、スナップショットを 5 年間保持することを確定する前に、スナップショットに対して何らかの監査や最終日付の検証を実行する必要があるでしょう。 EBS スナップショットのロックを確立および制御するために、プログラムで新しい API 関数を使用できます。 LockSnapshot – ガバナンスモードまたはコンプライアンスモードでスナップショットをロックするか、または既にロックされているスナップショットの設定を変更します。 UnlockSnapshot – ガバナンスモードのスナップショット、またはコンプライアンスモードに設定されているが、クーリングオフ期間内のスナップショットのロックを解除します。 DescribeLockedSnapshots – ロックの状態に基づくオプションのフィルタリングを使用して、スナップショットのロックステータスに関する情報を取得します。 これらの機能を使用するには、適切な許可 ( ec2:lockSnapshot 、 ec2:UnlockSnapshot 、 ec2:DescribeLockedSnapshots ) が IAM ユーザーに付与されている必要があります。 知っておくべきこと この新機能に関して留意すべき点がいくつかあります。 AWS Backup – AWS Backup は、作成したスナップショットの保持を独立して管理します。これらをロックすることは推奨されていません。 料金 – この機能の使用には追加料金はかかりません。スナップショットおよびアーカイブされたスナップショットのストレージの通常料金はお支払いいただきます。 リージョン – EBS スナップショットロックは、すべての商用 AWS リージョンでご利用いただけます。 KMS キーの保持 – EBS ボリュームとスナップショットの暗号化にカスタマーマネージド AWS Key Management Service (AWS KMS) キーを使用している場合は、スナップショットの存続期間中、キーが有効であり続けるようにする必要があります。 – Jeff ; 原文は こちら です。

本記事では、私たちがロードマップを公開している自動車会社であると想像してみましょう。私たちには世界中のユーザーがいて、車載エンターテイメントシステムにどのような機能が提供されたかを定期的にチェックしています。 ここでは、プロダクトマネージャーがログインしてロードマップを更新し、ロードマップページに反映させるための管理ページを構築します。 ロードマップページは世界中の多くの読者が閲覧し、更新頻度が低いため、Incremental Static Regeneration (ISR) を用いた Static Site Generator (SSG) の最適な候補になります。 本記事では、「 Deploy a Next.js 13 app with authentication to AWS Amplify 」を基に開発し、プロジェクトの初期化、Amazon Cognito 認証の実装、Amplify Hosting へのデプロイを行います。 GraphQL API のデプロイ プロジェクトのルートディレクトリで以下のコマンドを実行し、データを保存する GraphQL API を追加します。 amplify add api Amplify CLI のプロンプトには以下のように答えます。 ? Select from one of the below mentioned services: (Use arrow keys) ❯ GraphQL REST ? Here is the GraphQL API that we will create. Select a setting to edit or continue (Use arrow keys) Name: testamplify Authorization modes: API key (default, expiration time: 7 days from now) Conflict detection (required for DataStore): Disabled ❯ Continue ? Choose a schema template: Single object with fields (e.g., “Todo” with ID, name, description) One-to-many relationship (e.g., “Blogs” with “Posts” and “Comments”) ❯ Blank Schema ? Do you want to edit the schema now? (Y/n) › Y 次に、 schema.graphql の内容を以下のように書き換えます。 type Feature @model @auth(rules: [{ allow: owner }, { allow: public, operations: [read] }]) { id: ID! title: String! released: Boolean! description: String internalDoc: String } 最後に、以下のコマンドを実行し、API をデプロイします。 amplify push 次に、プロダクトマネージャがロードマップを作成、更新、削除するための管理画面を作成します。 pages/admin.js ファイルを作成し、以下のコードを追加して、このシリーズの 最初の投稿 で行ったように、Amplify の withAuthenticator コンポーネントを使用し、Cognito で認証を行うページを作成します。 // pages/admin.js import { Button, Divider, Flex, Heading, View, withAuthenticator, } from "@aws-amplify/ui-react"; import { Auth } from "aws-amplify"; import Link from "next/link"; import React, { useState } from "react"; function Admin() { // define state to be used later const [activeFeature, setActiveFeature] = useState(undefined); return ( <View padding="2rem"> <Flex justifyContent={"space-between"}> <Link href={"/admin"}> <Heading level={2}>AmpliCar Roadmap Admin</Heading> </Link> <Flex alignItems={"center"}> <Button type="button" onClick={() => Auth.signOut()}> Sign out </Button> </Flex> </Flex> <Divider marginTop={"medium"} marginBottom={"xxl"} /> <Flex></Flex> </View> ); } export default withAuthenticator(Admin); ここでは、管理ページ用の React コンポーネント Admin を作成します。 aws-amplify/ui-react パッケージの withAuthenticator コンポーネントを使用して、認証機能をコンポーネントに追加します。 また、このコンポーネントは Amplify UI の Button 、 Divider 、 Flex 、 Heading 、 View コンポーネントをインポートして使用し、サインアウトボタン、ディバイダー、後で使用するレイアウト要素を含むトップナビゲーションバーをレンダリングします。 サインアウトボタンがクリックされると、 Auth.signOut() メソッドが呼び出され、ユーザーがサインアウトします。 最後に、状態を管理するための React の useState フックを使って、 activeFeature と setActiveFeature で状態を追加します。 ブラウザで http://localhost:3000/admin にアクセスすると以下のような画面が表示されます。 アカウントを作成してサインインすると、ヘッダーにサインアウトボタンが表示されます。 ロードマップの機能を作成・更新するためのフォームを作成します。 プロジェクトのルートディレクトリに components ディレクトリを作成し、 FeatureForm.js 作成し、以下のコードに置き換えます。 // components/FeatureForm.js import { Button, Flex, Heading, SwitchField, Text, TextField, View, } from "@aws-amplify/ui-react"; import { API } from "aws-amplify"; import React, { useEffect, useState } from "react"; import { createFeature, updateFeature } from "../src/graphql/mutations"; function FeatureForm({ feature = null, setActiveFeature }) { const [id, setId] = useState(undefined); const [title, setTitle] = useState(""); const [description, setDescription] = useState(""); const [isReleased, setReleased] = useState(false); useEffect(() => { if (feature) { setId(feature.id); setTitle(feature.title); setDescription(feature.description); setReleased(feature.released); } }, [feature]); function resetFormFields() { setId(undefined); setTitle(""); setDescription(""); setReleased(false); } async function handleSaveFeature() { try { await API.graphql({ authMode: "AMAZON_COGNITO_USER_POOLS", query: feature ? updateFeature : createFeature, variables: { input: { id: feature ? id : undefined, title, description, released: isReleased }, }, }); feature && setActiveFeature(undefined); resetFormFields(); } catch ({ errors }) { console.error(...errors); throw new Error(errors[0].message); } } return ( <View> <Heading marginBottom="medium" level={5}> {feature ? "Edit" : "New"} Feature </Heading> <Flex direction={"column"} basis={"max-content"}> <TextField value={title} label="Title" errorMessage="There is an error" name="title" onChange={(e) => setTitle(e.target.value)} /> <TextField value={description} name="description" label="Description" errorMessage="There is an error" onChange={(e) => setDescription(e.target.value)} /> <SwitchField isChecked={isReleased} isDisabled={false} label="Released?" labelPosition="start" onChange={() => setReleased(!isReleased)} /> <Flex marginTop="large"> <Button onClick={() => { setActiveFeature(undefined); resetFormFields(); }} > Cancel </Button> <Button onClick={() => handleSaveFeature()}>Save</Button> </Flex> </Flex> </View> ); } export default FeatureForm; このコードでは、 FeatureForm という React コンポーネントを定義します。 FeatureForm コンポーネントは、 feature props と setActiveFeature props を受け取ります。これらは、フォームフィールドにデータを入力し、保存された後にフォームをリセットするために使用されます。コンポーネントは useState フックを使用して、機能のタイトル、説明、リリース済みかどうかを含むフォームフィールドの状態を追跡します。 コンポーネントがレンダリングされると、 feature props が渡されたかどうかをチェックし、渡された場合は useEffect フックを使ってフォームフィールドに機能を入力します。そうでなければ、フォームフィールドは空のままです。 このコンポーネントには、機能のタイトル、説明、リリースステータスを入力するためのいくつかのフォームと、保存ボタンとキャンセルボタンがあります。 save ボタンがクリックされると、コンポーネントは API.graphql を介して createFeature mutation を発行し、その機能を GraphQL API を使用して保存します。コンポーネントが feature props でレンダリングされた場合、 updateFeature mutation を使用してデータベース内の既存の機能を更新します。 機能が保存された後、コンポーネントはフォームフィールドをリセットし、オプションで setActiveFeature コールバック props を呼び出して Admin コンポーネントの activeFeature をリセットします。 pages/admin の Admin コンポーネントを更新して FeatureForm コンポーネントを追加し、ロードマップ管理画面に表示されるようにします。また、機能を編集しているかどうかを追跡するステート変数を追加します。 // pages/admin.js import { Button, Divider, Flex, Heading, View, withAuthenticator, } from "@aws-amplify/ui-react"; import { Auth } from "aws-amplify"; import Link from "next/link"; import React, { useState } from "react"; import FeatureForm from "../components/FeatureForm"; function Admin() { const [activeFeature, setActiveFeature] = useState(undefined); return ( <View padding="2rem"> // ... <Divider marginTop={"medium"} marginBottom={"xxl"} /> <Flex> <FeatureForm feature={activeFeature} setActiveFeature**={setActiveFeature} /> </Flex> </View> ); } export default withAuthenticator(Admin); ページを更新すると、新機能フォームが表示されます。 次に、機能の一覧を表示し、編集や削除を可能にするテーブルを作成しましょう。 components ディレクトリに新しく FeaturesTable コンポーネントを作成し、以下のコードを貼り付けます。 // components/FeaturesTable.js import { Button, Table, TableBody, TableCell, TableHead, TableRow, View, } from "@aws-amplify/ui-react"; import { API, graphqlOperation } from "aws-amplify"; import React, { useEffect, useState } from "react"; import { deleteFeature } from "../src/graphql/mutations"; import { listFeatures } from "../src/graphql/queries"; function FeaturesTable({ initialFeatures = [], setActiveFeature }) { const [features, setFeatures] = useState(initialFeatures); useEffect(() => { const fetchFeatures = async () => { const result = await API.graphql(graphqlOperation(listFeatures)); setFeatures(result.data.listFeatures.items); }; fetchFeatures(); }, []); async function handleDeleteFeature(id) { try { await API.graphql({ authMode: "AMAZON_COGNITO_USER_POOLS", query: deleteFeature, variables: { input: { id, }, }, }); } catch ({ errors }) { console.error(...errors); } } if (features.length === 0) { return <View>No features</View>; } return ( <Table> <TableHead> <TableRow> <TableCell as="th">Feature</TableCell> <TableCell as="th">Released</TableCell> <TableCell></TableCell> </TableRow> </TableHead> <TableBody> {features.map((feature) => ( <TableRow key={feature.id}> <TableCell>{feature.title}</TableCell> <TableCell>{feature.released ? "Yes" : "No"}</TableCell> <TableCell> <Button size="small" onClick={() => setActiveFeature(feature)}> Edit </Button> <Button size="small" onClick={() => handleDeleteFeature(feature.id)} > Delete </Button> </TableCell> </TableRow> ))} </TableBody> </Table> ); } export default FeaturesTable; このコードでは、 FeaturesTable という React コンポーネントを定義し、機能のテーブルをレンダリングします。テーブルには、各機能のタイトルとリリース済みかどうかが表示され、各機能を編集および削除するためのボタンが用意されています。 このテーブルは、Amplify UI の Table 、 TableBody 、 TableCell 、 TableRow コンポーネントを使用してレンダリングされます。 FeaturesTable コンポーネントは、オプションで initialFeatures の配列と setActiveFeature 関数を props として受け取ります。 useState フックを使用して features ステート変数に features リストを格納し、 useEffect フックを使用してコンポーネントのマウント時に GraphQL API から features リストを取得します。 handleDeleteFeature 関数は、 deleteFeature mutation を呼び出して機能を削除するために使用します。 handleDeleteFeature 関数は、テーブル内の各機能の削除ボタンに props として渡され、ボタンがクリックされると、対応する機能が削除されます。 編集ボタンがクリックされると、クリックされた機能を引数として setActiveFeature 関数が呼び出されます。これにより、 Admin コンポーネントの activeFeature ステート変数が更新され、 FeatureForm コンポーネントが再レンダリングされます。これにより、ユーザーはフォームを使って選択した機能を編集できるようになります。 次に、 Pages/admin.js を更新して、 FeaturesTable コンポーネントを追加します。 // pages/admin.js import { // ... withAuthenticator, } from "@aws-amplify/ui-react"; import { Auth } from "aws-amplify"; import Link from "next/link"; import React, { useState } from "react"; import FeatureForm from "../components/FeatureForm"; import FeaturesTable from "../components/FeaturesTable"; function Admin() { const [activeFeature, setActiveFeature] = useState(undefined); return ( <View padding="2rem"> // ... <Divider marginTop={"medium"} marginBottom={"xxl"} /> <Flex> <FeatureForm feature={activeFeature} setActiveFeature={setActiveFeature} /> <FeaturesTable setActiveFeature={setActiveFeature} /> </Flex> </View> ); } export default withAuthenticator(Admin); このコンポーネントを追加してリフレッシュすると、まだ機能を追加していないため、No features と表示されるはずです。 Server-Side Rendering（SSR）によるユーザー体験の向上 優れたユーザー体験を提供するために、Server-Side Rendering (SSR) を使って機能を取得するように管理ページを更新しましょう。SSR を使うことで、データなしでページをレンダリングし、別のネットワークリクエストが完了し、データが入力されるのを待つよりも優れたユーザー体験を提供することが出来ます。 // pages/admin.js import { Button, Divider, Flex, Heading, View, withAuthenticator, } from "@aws-amplify/ui-react"; import { Auth, withSSRContext } from "aws-amplify"; import Link from "next/link"; import React, { useState } from "react"; import FeatureForm from "../components/FeatureForm"; import FeaturesTable from "../components/FeaturesTable"; import { listFeatures } from "../src/graphql/queries"; export async function getServerSideProps({ req }) { const SSR = withSSRContext({ req }); const response = await SSR.API.graphql({ query: listFeatures }); return { props: { initialFeatures: response.data.listFeatures.items, }, }; } function Admin({ initialFeatures }) { const [activeFeature, setActiveFeature] = useState(undefined); return ( <View padding="2rem"> // ... <Divider marginTop={"medium"} marginBottom={"xxl"} /> <Flex> <FeatureForm feature={activeFeature} setActiveFeature={setActiveFeature} /> <FeaturesTable initialFeatures={initialFeatures} setActiveFeature={setActiveFeature} /> </Flex> </View> ); } export default withAuthenticator(Admin); このコードでは、 getServerSideProps を使用して、 listFeatures query で Amplify API.graphql を呼び出し、サーバー上の React コンポーネントに注入される props オブジェクトで初期の機能を返します。 Admin コンポーネントは initialFeatures を受け取り、 FeaturesTable コンポーネントに渡します。 新機能フォームで、機能を追加してページをリフレッシュすると、右側のテーブルに表示されます。 リアルタイム更新によるユーザー体験の向上 これまで構築したものは動作しますが、プロダクトマネージャーが最新の機能を見るためにページを更新する必要があり、最高のユーザー体験を提供するものではありません。 以下のコードでは、この機能を実装するために Amplify の GraphQL Subscription を使ってデータをサブスクライブします。 // components/FeaturesTable.js import { Button, Table, TableBody, TableCell, TableHead, TableRow, View, } from "@aws-amplify/ui-react"; import { API, graphqlOperation } from "aws-amplify"; import React, { useEffect, useState } from "react"; import { deleteFeature } from "../src/graphql/mutations"; import { listFeatures } from "../src/graphql/queries"; import { onCreateFeature, onDeleteFeature, onUpdateFeature, } from "../src/graphql/subscriptions"; function FeaturesTable({ initialFeatures = [], setActiveFeature }) { const [features, setFeatures] = useState(initialFeatures); useEffect(() => { const fetchFeatures = async () => { const result = await API.graphql(graphqlOperation(listFeatures)); setFeatures(result.data.listFeatures.items); }; fetchFeatures(); const createSub = API.graphql(graphqlOperation(onCreateFeature)).subscribe({ next: ({ value }) => { setFeatures((features) => [...features, value.data.onCreateFeature]); }, }); const updateSub = API.graphql(graphqlOperation(onUpdateFeature)).subscribe({ next: ({ value }) => { setFeatures((features) => { const toUpdateIndex = features.findIndex( (item) => item.id === value.data.onUpdateFeature.id ); if (toUpdateIndex === -1) { return [...features, value.data.onUpdateFeature]; } return [ ...features.slice(0, toUpdateIndex), value.data.onUpdateFeature, ...features.slice(toUpdateIndex + 1), ]; }); }, }); const deleteSub = API.graphql(graphqlOperation(onDeleteFeature)).subscribe({ next: ({ value }) => { setFeatures((features) => { const toDeleteIndex = features.findIndex( (item) => item.id === value.data.onDeleteFeature.id ); return [ ...features.slice(0, toDeleteIndex), ...features.slice(toDeleteIndex + 1), ]; }); }, }); return () => { createSub.unsubscribe(); updateSub.unsubscribe(); deleteSub.unsubscribe(); }; }, []); // remainder of FeaturesTable component unmodified } export default FeaturesTable; ここでは、 createSub 、 updateSub 、 deleteSub Subscription を useEffect に追加し、AppSync から onCreateFeature 、 onUpdateFeature 、 onDeleteFeature のいずれかの Subscription に対してプッシュされたデータの変更をリッスンします。 それぞれのクエリに対して、subscribe に渡されたオブジェクトの次の関数を介して、アプリケーションを更新するロジックを実装しなければなりません。 createSub は、 setFeatures を呼び出し、Subscription 経由で受け取ったレコードを渡すことで、 features に新しいレコードを追加します。 updateSub は、変更されたレコードを検索し、features 内のレコードを Subscription から返されたバージョンに置き換えるコールバックを実装します。 deleteSub は、変更されたレコードを検索し、 features から削除するコールバックを実装します。 最後に、Subscription をクリーンアップするために、それぞれの Subscription の unsubscribe メソッドへの呼び出しを返します。 管理画面でアイテムを作成したり編集したりすると、機能リストがすぐに更新されることがわかります。 本記事では、プロダクトマネージャーがロードマップに機能を追加するための管理インターフェイスを構築しました。次の記事では、ユーザー向けのページを実装し、その機能に関連する内部ドキュメントを保存する機能を追加します。 本記事は「 Build a Product Roadmap with Next.js and Amplify 」を翻訳したものです。

AWS Resource Explorer を利用すると、 AWS リージョン 全体で、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Kinesis データストリーム、 Amazon DynamoDB テーブルなどのリソースを検索および検出できます。11月14日より、 組織 内のアカウント全体も検索できるようになりました。 わずか数分で、組織全体または特定の組織単位 (OU) のために Resource Explorer をオンにして設定し、シンプルな自由形式のテキストとフィルター検索を使用して、アカウントおよびリージョン全体で関連する AWS リソースを見つけることができます。 マルチアカウント検索は、 Resource Explorer コンソール で、もしくは 統合検索バー (すべての AWS コンソールページの上部にある検索バー) を通じて AWS マネジメントコンソール のあらゆる場所で、または AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、 AWS Chatbot を使用してご利用いただけます。このような方法により、リソースを迅速に見つけ、適切なアカウントおよびサービスに移動して、アクションを実行できます。 Well-Architected な態様で運用する場合は、ビジネスアプリケーションとデータを分離して管理するのに役立つよう、複数の AWS アカウントが使用されます。Resource Explorer を利用して、アカウントをまたいでリソースを探索し、大規模に使用する方法を簡素化できるようになりました。例えば、Resource Explorer は、運用コストの増加の調査、パフォーマンスの問題のトラブルシューティング、セキュリティアラートに基づく是正を行う際に、組織全体で影響を受けるリソースを特定するのに役立ちます。 これが実際にどのように機能するのかを見てみましょう。 マルチアカウント検索の設定 次の 4 つのステップで組織のためにマルチアカウント検索を設定できます。 AWS アカウント管理 のために 信頼されたアクセス を有効にします。 検索する組織または OU 内のすべてのアカウントで Resource Explorer を設定します。これは、 AWS Systems Manager Quick Setup を使用して 、数回クリックするだけで実行できます。オプションで、 AWS CloudFormation または使い慣れた他の管理ツールを使用できます。 必須ではありませんが、AWS アカウント管理用の 委任された管理者アカウント を作成することをお勧めします。その後、マルチアカウントの作成に必要なすべての許可を一元化するために、委任された管理者アカウントを使用して Resource Explorer のマルチアカウントビューを作成することをお勧めします。 最後に、マルチアカウントビューを作成して、組織全体の検索を開始できます。 マルチアカウントビューの作成 前述のリストの最初の 3 つのステップは既に実施しました。委任された管理者アカウントを使用して、 Resource Explorer コンソール に移動します。コンソールの [リソースを詳しく見る] セクションで [ビュー] を選択し、ビューを作成します。 ビューの名前を入力し、 [組織全体のリソースの可視化] を選択します。これにより、組織全体または特定の OU 内のアカウントにあるリソースを表示できるようになります。このビューでは、組織全体を選択します。 [リージョン] で、アグリゲーターインデックスがあるリージョンを選択します。アグリゲーターインデックスには、Resource Explorer がオンになっている他のすべてのリージョンにあるローカルインデックスのレプリケートされたコピーが含まれています。オプションで、このビューに含めるリソースを制限するためにフィルターを使用できます。すべてのリソースと、タグなどの追加のリソース属性を含めることを選択します。 その後、ビューの作成を完了します。ビューに対するアクセスを許可することで、Resource Explorer で誰がどのリソース情報にアクセスできるかを制御できるようになりました。 マルチアカウント検索の使用 新しいマルチアカウントビューを試すには、ナビゲーション ペインの [リソースを詳しく見る] セクションから [リソースの検索] を選択します。私のクエリでは、古いバージョンの Redis 用の Amazon ElastiCache リソースがあるかどうかを確認したいと考えています。 [クエリ] フィールドに elasticache:* redis3.2 と入力します。 結果には、これらのリソースが存在するさまざまな AWS アカウントおよびリージョンが表示されます。私のアカウントのリソースについては、最初の列にリンクが含まれており、これをクリックするとコンソールでそのリソースが開きます。他のアカウントのリソースについては、適切なアカウントとサービスでコンソールを使用して、詳細情報を取得したり、アクションを実行したりできます。 知っておくべきこと マルチアカウント検索は、次の AWS リージョンでご利用いただけます: [[ リージョン ]]。 マルチアカウント検索を含め、AWS Resource Explorer の利用に追加料金はかかりません。 組織内の他のアカウントとビューを共有するには、委任された管理者アカウントを使用して、組織内のリソース、リージョン、アカウントに関して必要な表示設定を備えたビューを作成してから、 AWS Resource Access Manager を利用してビューに対するアクセスを共有することをお勧めします。例えば、特定の OU のビューを作成し、その後にその OU 内のアカウントとビューを共有できます。 AWS Resource Explorer を利用して、組織内のアカウント全体およびリージョン全体で関連するリソースを検索して見つけましょう。 – Danilo 原文は こちら です。

地理空間アプリケーションは、インタラクティブな地図から位置情報サービスまで、私たちの日常生活に欠かせないものとなっています。このようなアプリケーションの需要が高まる中、開発者は信頼性の高い地理空間ソリューションを構築するための強力で安全なツールを必要としています。Amazon Web Services (AWS) は最先端のサービスを提供すしており、最近では Amazon Location Service の API キーと認証ヘルパーを発表し、地理空間アプリ開発者にエキサイティングな機会をもたらしました。本記事では、 API キー 、 Amazon Location Service Auth Helper Library 、 Amazon Location Service Data Types Converter Library を活用して、機能豊富な地理空間アプリケーションを構築する方法を紹介します。 Amazon Location Service の新しいリリース 技術的な詳細に入る前に、 Amazon Location Service の最新の機能拡張について簡単に説明します。Amazon Location Service は最近、開発者が Amazon Location Service API に安全にアクセスするための追加オプションを提供する API キーを発表しました。API キーを利用することで、地理空間データやサービスへのアクセスを制御しやすくなり、許可されたユーザーのみがアプリケーションとやり取りできるようになり、より幅広いアプリケーションやツールへのアクセスが可能になります。 さらに、 Amazon Location Service Auth Helper Library をリリースしました。これは、開発者の認証エクスペリエンスを合理化するための貴重なリソースです。このライブラリは、 Amazon Location Service の認証のユースケースを合理化するように設計されており、データの保護と開発者のスムーズな体験を保証します。 API キーは、API への認証とアクセス制御に使用される一意の識別子です。この機能を使用することで、特定のドメインや特定の Amazon Location Service リソースへのアクセスを制限するなど、きめ細かなレベルでアクセスを管理することができます。 この機能は、セキュリティを強化し、アプリケーションのパフォーマンスを向上させるために設計されています。Amazon Location Service API キーは、アプリケーションのユーザーに対して特定のアクションへの読み取り専用アクセスを可能にします。アプリケーションのフロントエンドにキーを埋め込むことで、他の認証方法に関連する複数の呼び出しを削除し、待ち時間を改善することができます。このアプローチは API の使用状況を監視し、クォータとキーのローテーションを使用して、リソースの消費を管理し、乱用を防ぐことを可能にします。API キー機能は Amazon Location Service Auth Help Library に統合され、プレースやルートの機能へのアクセス管理がより簡単になりました。 本記事では、API キーと新しい Auth Helper Library の機能をデモンストレーションし、地理空間アプリケーションの構築プロセスを紹介します。 APIキーの作成 API キーを作成する前に、 Amazon Location リソースを作成します。 マップ 、 プレース 、 ルート のガイドに従って、本記事で使用するリソースを作成します。Amazon Location リソースの作成中に、各リソースの API キーを設定するようプロンプトが表示されることに注意してください。API キーを作成してからリソースをリンクするので、この設定ステップは省略できます。 Amazon Location リソースを作成したら、API キーを作成します。今回は、マップ、プレース、ルート で使用できる 1 つの API キーを作成します。 Amazon Location コンソールに移動し、 API Keys を選択します。 ここで Create API key を選択します。 API キーに名前を付け、前のステップで作成したリソースを選択します。 次に、権限とその他の API キー設定オプションを定義します。 キーがアクセスできる読み取り専用の API アクションを定義することができます。今回のケースでは、 Amazon Location Service の主要な機能を利用できるように、マップ、プレース、ルート API 内の特定のリソースへのアクセスを許可します。これらのリソースには関連コストがかかるため、使用量の急増を監視するために課金アラートを設定し、定期的なキーローテーションプロセスの一環としてAPI キーの有効期限を設定することをお勧めします。 最後に、特定のドメインで使用するために API キーをロックダウンしたい場合は、キーが有効な URL を制限する Referer ドメインを設定することができます。 ここで、 Create API key を選択して API キーを作成します。 Show API key value を選択すると、API キーが表示されます。 これで API Key が作成できたので、アプリケーションで API キーを使い始めることが出来ます。これらのデモコードでは、API キーを変数としてハードコードしています。本番環境にデプロイする場合は、Referrer などのセキュリティ機能を使用することに加えて、アプリケーションの認証情報を保存・取得するために AWS Secrets Manager を使用することを推奨します。 API キーを使ったマップアプリケーションの構築 本記事では、地図と検索ボックスを含むシンプルなデモを構築します。人気のある MapLibre GL JS レンダリングライブラリを使って地図を表示することから始めます。MapLibre はスタイル URL の提供をサポートしているので、Auth Helper Library を使用する必要はなく、API エンドポイントを直接設定することができます。 まず index.html ファイルを作成し、 region と apiKey に利用するリージョンと API キーを、 mapName には前のステップで作成したマップリソースに置き換えて以下の内容を追加します。 <!-- index.html --> <!-- Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. --> <!-- SPDX-License-Identifier: MIT-0 --> <html> <head> <link href="https://unpkg.com/maplibre-gl@3/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <body> <!-- Map container --> <div id="map" /> <!-- JavaScript dependencies --> <script src="https://unpkg.com/maplibre-gl@3"></script> <script> const apiKey = "<Your API Key>"; // API key const region = "<Your Region>"; // Region const mapName = "<Your Map Resource>"; // Map name // URL for style descriptor const style = `https://maps.geo.${region}.amazonaws.com/maps/v0/maps/${mapName}/style-descriptor?key=${apiKey}`; // Initialize the map const map = new maplibregl.Map({ container: "map", style, center: [-123.1187, 49.2819], zoom: 11, }); map.addControl(new maplibregl.NavigationControl(), "top-left"); </script> </body> </html> これを index.html として保存し、ブラウザで開いてください。ブリティッシュコロンビア州バンクーバーの地図が表示されるはずです。 地図を表示できたら、次にアプリケーションに位置検索ウィジェットを追加します。 地図に位置情報検索ボックスを追加する 検索ボックスには、 Amazon Location Service プレースインデックス を使用します。プレースインデックスを使うと、ジオコーディング/リバースジオコーディングができます。この例では、 Amazon Location Service と MapLibre ジオコーダー を使用します。 コードスニペットをコピーする代わりにこのアプリケーションをクローンしたい場合は、このコードは amazon-location-sample-map-with-geocoder GitHubリポジトリで利用可能です。 アプリケーションを作成するために、 index.html ファイルに加えて 2 つのファイルを作成します。 まず、 index.html を編集してマップを削除し、依存関係をダウンロードします。 <!DOCTYPE html> <!-- Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. --> <!-- SPDX-License-Identifier: MIT-0 --> <html> <head> <meta charset="utf-8"> <title>Basic Map with Geocoder</title> <!-- Styles --> <link href="https://unpkg.com/maplibre-gl@3/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <body> <main> <div id="map"></div> </main> <!-- JavaScript dependencies --> <script src="https://unpkg.com/maplibre-gl@3"></script> <script src="https://unpkg.com/@aws/amazon-location-client@1/dist/amazonLocationClient.js"></script> <script src="https://unpkg.com/@aws/amazon-location-utilities-auth-helper@1/dist/amazonLocationAuthHelper.js"></script> <!-- Load the `maplibre-gl-geocoder` plugin. --> <script src="https://unpkg.com/@maplibre/maplibre-gl-geocoder@1/dist/maplibre-gl-geocoder.min.js"></script> <link rel="stylesheet" href="https://unpkg.com/@maplibre/maplibre-gl-geocoder/dist/maplibre-gl-geocoder.css" type="text/css" /> <!-- JavaScript for the app --> <script src="main.js"></script> </body> </html> 次に、 main.js という新しいファイルを作成し、以下のコードを貼り付けます。 region と apiKey に利用するリージョンと API キーを、 mapName には前のステップで作成したマップリソースに置き換えて以下の内容を追加します。 const { GetPlaceCommand, LocationClient, SearchPlaceIndexForSuggestionsCommand, SearchPlaceIndexForTextCommand } = amazonLocationClient; // Amazon Location Service Resources: const apiKey = "<Amazon Location API key>"; const mapName = "<Amazon Location Map resource name>"; const placeIndex = "<Amazon Location PlaceIndex resource name>"; const region = "<AWS Region, e.g., eu-central-1>"; // Add Geocoder control to the map via callbacks that are called by maplibre-gl-geocoder. // forwardGeocode: required for geocoding (Amazon Location SearchPlaceIndexForText API) // getSuggestions + searchByPlaceId: required for autosugget (Amazon Location SearchPlaceIndexForSuggestions + GetPlace APIs) async function addGeocoder(map, authHelper, client) { const amazonLocationGeocoderApi = { forwardGeocode: async (config) => { try { // Set up command to call SearchPlaceIndexForText API const { Results } = await client.send(new SearchPlaceIndexForTextCommand({ IndexName: placeIndex, Text: config.query })); // Convert the results to Carmen GeoJSON (<link>) to be returned to the MapLibre Geocoder const features = Results.map((result) => ({ type: 'Feature', geometry: { type: 'Point', coordinates: result.Place.Geometry.Point, }, place_name: result.Place.Label, properties: { id: result.Place.PlaceId, }, text: result.Place.Label, place_type: ['place'], center: result.Place.Geometry.Point, })); return { features }; } catch (error) { console.error(`Failed to forwardGeocode with error: ${error}`); } }, getSuggestions: async (config) => { try { // Set up a command to call SearchPlaceIndexForSuggestions API; const { Results } = await client.send(new SearchPlaceIndexForSuggestionsCommand({ IndexName: placeIndex, Text: config.query })); // Iterate over data.Results and return all suggestions and their place ids const suggestions = Results.map((result) => ({ text: result.Text, placeId: result.PlaceId, })); return { suggestions }; } catch (error) { console.error(`Failed to getSuggestions with error: ${error}`); } }, searchByPlaceId: async (config) => { try { // Set up command to call GetPlace API with a place Id of a selected suggestion const { Place } = await client.send(new GetPlaceCommand({ IndexName: placeIndex, PlaceId: config.query, })); const place = { type: 'Feature', geometry: { type: 'Point', coordinates: Place.Geometry.Point, }, place_name: Place.Label, text: Place.Label, center: Place.Geometry.Point, }; return { place }; } catch (error) { console.error(`Failed to searchByPlaceId with error: ${error}`); } }, }; // Add Geocoder control to the map map.addControl(new MaplibreGeocoder(amazonLocationGeocoderApi, { maplibregl, showResultsWhileTyping: true })); } // Initialize a map async function initializeMap() { const map = new maplibregl.Map({ container: 'map', // HTML element ID of map element center: [-123.1187, 49.2819], // Initial map centerpoint zoom: 16, // Initial map zoom style: `https://maps.geo.${region}.amazonaws.com/maps/v0/maps/${mapName}/style-descriptor?key=${apiKey}`, // Defines the appearance of the map and authenticates using an API key }); // Add navigation control to the top left of the map map.addControl(new maplibregl.NavigationControl(), 'top-left'); return map; } async function main() { // Create an authentication helper instance using an API key const authHelper = await amazonLocationAuthHelper.withAPIKey(apiKey); const client = new LocationClient({ region, ...authHelper.getLocationClientConfig(), // Provides configuration required to make requests to Amazon Location }); // Initialize map and add a geocoder to it. const map = await initializeMap(); addGeocoder(map, authHelper, client); } main(); すべてのファイルが作成されたら、 index.html をブラウザで開き、右上にある検索ボックスがある地図を見ることができます。 これでジオコーディングをテスト出来るようになりました。画像は、 Amazon Location Service プレースインデックスの自動補完と前方ジオコーディング機能を試してみたものです。 Auth Library を理解する さて、アプリケーションを作成しました。Amazon Location Service Auth Helper Library がどのように動作するのかを理解するために、コードを詳しく見ていきましょう。 最初に行うことは、認証方法を定義することです。これには Amazon Cognito Identity Pools 、もしくは API キーを使用します。 API キーの場合、次のように Auth メソッドを使用します。 const authHelper = await amazonLocationAuthHelper.withAPIKey(apiKey); Amazon Cognito Identity Pools を使用する場合、次のように使用します。 const authHelper = await withIdentityPoolId(identityPoolId); 次に、Amazon Location Service Client をインスタンス化する際に、Auth Helper を読み込みます。Auth Helper は、前のステップで設定した認証のタイプに基づいて、クライアントに追加のプロパティを含めます。 const client = new amazonLocationClient.LocationClient({ region, ...authHelper.getLocationClientConfig(), // Provides configuration required to make requests to Amazon Location }); 最後に、Amazon Location Service API を呼び出します。プレースインデックスを使って Seattle, WA を検索するとてもシンプルな例では、Auth Helper と Client を使って SearchPlaceIndexForText API を呼び出します。 <!-- index.html --> <!-- Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. --> <!-- SPDX-License-Identifier: MIT-0 --> <html> <head> </head> <body> <pre id="place_index_results" ></pre> <script src="https://unpkg.com/@aws/amazon-location-client@1/dist/amazonLocationClient.js"></script> <script src="https://unpkg.com/@aws/amazon-location-utilities-auth-helper@1/dist/amazonLocationAuthHelper.js"></script> <script> const Key = "<Amazon Location API key>"; // API key const region = "<Amazon Location PlaceIndex resource name>"; // Region const IndexName = "<AWS Region, e.g., eu-central-1>"; async function placeIndexSearch(){ const authHelper = await amazonLocationAuthHelper.withAPIKey(Key); const { LocationClient, SearchPlaceIndexForTextCommand } = amazonLocationClient; // Instantiate the Amazon Location Service Client using the Auth Helper configuration const client = new LocationClient({ region, ...authHelper.getLocationClientConfig() // Provides configuration required to make requests to Amazon Location using either API Keys or Cognito }); // Call the SearchPlaceIndexForText API using the Amazon Location client const data = await client.send(new SearchPlaceIndexForTextCommand({ IndexName, Text: "Seattle, WA", MaxResults: 1, })); document.getElementById("place_index_results").innerHTML = JSON.stringify(data['Results'], null, 4); } placeIndexSearch(Key) </script> </body> </html> この例では、結果は JSON としてブラウザに表示されます。 ご覧の通り、新しい Auth Helper は Amazon Location リソースの認可設定をより簡単にします。 Python での利用 JavaScript によるフロントエンドアプリケーションの構築に加えて、API キーは Amazon Location SDK がサポートするすべての言語でサポートされています。バックエンドアプリケーションで API キーを使用することで、アプリケーションをホストするインフラ上で IAM ロールや一時的な認証情報を設定するために必要なオーバーヘッドを削減することができます。例えば、次の例は、コマンドラインで住所を受け取り、API キーを使用してジオコーディングするシンプルな Python スクリプトです。単純な Python アプリケーションを作成するには、新しい Python ファイルを作成し、以下のコードを貼り付けます。 #Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. #SPDX-License-Identifier: MIT-0 import boto3from botocore import UNSIGNEDfrom botocore.config import Config client = boto3.client("location", region_name='<AWS Region, e.g., eu-central-1>', config=Config(signature_version=UNSIGNED)) text = input() response = client.search_place_index_for_text( IndexName='<Amazon Location PlaceIndex resource name>', Key='<Amazon Location API key>', MaxResults=1, Text=text) print(response['Results']) コードを実行する際、検索語を入力してください。この場合、ニューヨークを検索します。 Enter を押すと、Amazon Location Service プレースインデックスの検索結果が表示されます。 データ型変換ライブラリ Auth Helper Library に加えて、JavaScript 用の Amazon Location Utilities – データ型ライブラリもリリースしました。これらのライブラリは、Amazon Location Service API からの出力を一般的な GeoJSON データフォーマットに変換し、ジオフェンスの作成、プレースインデックス検索などのためにこれらのフォーマットからの入力を受け取ります。この例では、ユーザーからの入力を受け取り、 Amazon Location Service プレイスインデックスを検索し、結果を GeoJSON フォーマットで返す非常にシンプルなアプリを構築します。そして、この サンプルアプリケーション を使ってポイントを表示します。まず、新しいHTMLファイルを開き、リージョン、プレイスインデックス、API キーを先ほど作成した値に置き換えて、以下を貼り付けます。 <!-- Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. --> <!-- SPDX-License-Identifier: MIT-0 --> <html> <head> <link href="https://unpkg.com/maplibre-gl@3/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <pre id="jsonText" ></pre> <body> <div id="map" /> <script src="https://unpkg.com/maplibre-gl@3"></script> <script src="https://unpkg.com/@aws/amazon-location-utilities-auth-helper@1/dist/amazonLocationAuthHelper.js"></script> <script src="https://www.unpkg.com/@aws/amazon-location-utilities-datatypes@1/dist/amazonLocationDataConverter.js"></script> <script src="https://unpkg.com/@aws/amazon-location-client@1/dist/amazonLocationClient.js"></script> <script> async function initializeMap() { const key = "<Amazon Location API key>"; const mapName = "<Amazon Location Map resource name>"; const region = "<AWS Region, e.g., eu-central-1>"; const IndexName = "<Amazon Location PlaceIndex resource name>"; const searchTerm = prompt("Search for a Location"); // Create an authentication helper instance using credentials from Cognito const authHelper = await amazonLocationAuthHelper.withAPIKey(key); const client = new amazonLocationClient.LocationClient({ region, ...authHelper.getLocationClientConfig(), // Provides configuration required to make requests to Amazon Location }); const searchResults = await client.send( new amazonLocationClient.SearchPlaceIndexForTextCommand({ IndexName, Text: searchTerm, MaxResults: 1, }) ); // Initialize the map const map = new maplibregl.Map({ container: "map", // Set the map centerpoint based on the geojson coordinates center: featureCollection.features[0].geometry.coordinates, // Initial zoom level zoom: 14, style: `https://maps.geo.${region}.amazonaws.com/maps/v0/maps/${mapName}/style-descriptor?key=${key}`, }); // Add navigation controls map.addControl(new maplibregl.NavigationControl(), "top-left"); map.on("load", () => { // Convert search results into a GeoJSON FeatureCollection const featureCollection = amazonLocationDataConverter.placeToFeatureCollection(searchResults); // Add a data source containing GeoJSON produced from the Amazon Location Service プレースインデックス output. map.addSource("place-index-results", { type: "geojson", data: featureCollection, }); // Add a new layer to visualize the points. map.addLayer({ id: "place-index-results", type: "circle", source: "place-index-results", paint: { "circle-radius": 8, "circle-color": "#0080ff", }, }); map.on('click', 'place-index-results', (e) => { const coordinates = e.features[0].geometry.coordinates.slice(); const description = JSON.stringify(featureCollection, null, 4);; new maplibregl.Popup() .setLngLat(coordinates) .setHTML(description) .addTo(map); }); }); } initializeMap(); </script> </body> </html> HTML ページをロードすると、検索を入力するプロンプトが表示されます。お近くの市町村や、よく行かれるお店を検索してみてください。”OK” をクリックすると、地図とアイコンが表示されます。マーカーをクリックすると、データ型変換ライブラリが提供する GeoJSON 出力が表示されます。 また、データ型変換ライブラリをルーティングに使うことで、Amazon Location Service が提供するルートを開発者が簡単に地図上に描くことができる。この例は上記と非常に似ていますが、今回は先に作成したルート計算機を含みます。 まず、新しい HTML ファイルを開き、 region と CaluculatorName に利用するリージョンと計算機を、Key に先ほど作成した API キーの値に置き換えて、以下を貼り付けます。ルートを描くために DeparturePosition と DestinationPosition を設定します。 <!-- Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. --> <!-- SPDX-License-Identifier: MIT-0 --> <html> <head> <link href="https://unpkg.com/maplibre-gl/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <body> <div id="map" /> <script src="https://unpkg.com/maplibre-gl@3"></script> <script src="https://unpkg.com/@aws/amazon-location-utilities-auth-helper@1/dist/amazonLocationAuthHelper.js"></script> <script src="https://www.unpkg.com/@aws/amazon-location-utilities-datatypes@1/dist/amazonLocationDataConverter.js"></script> <script src="https://unpkg.com/@aws/amazon-location-client@1/dist/amazonLocationClient.js"></script> <script> async function initializeMap() { const key = "<Amazon Location API key>"; const mapName = "<Amazon Location Map resource name>"; const region = "<AWS Region, e.g., eu-central-1>"; const IndexName = "<Amazon Location PlaceIndex resource name>"; const CalculatorName = "<Amazon Location Route Calculator resource name>"; const DeparturePosition = "[Departure Longitude, Departure Latitude]" const DestinationPosition = "[Destination Longitude, Destination Latitude]" // Create an authentication helper instance using credentials from Cognito const authHelper = await amazonLocationAuthHelper.withAPIKey(key); const client = new amazonLocationClient.LocationClient({ region, ...authHelper.getLocationClientConfig(), // Provides configuration required to make requests to Amazon Location }); const route = await client.send( new amazonLocationClient.CalculateRouteCommand({ CalculatorName, DeparturePosition, DestinationPosition, IncludeLegGeometry: true, }) ); // Initialize the map const map = new maplibregl.Map({ container: "map", // Set the map centerpoint based on the geojson coordinates center: DeparturePosition, // Initial zoom level zoom: 11, style: `https://maps.geo.${region}.amazonaws.com/maps/v0/maps/${mapName}/style-descriptor?key=${key}`, }); // Add navigation controls map.addControl(new maplibregl.NavigationControl(), "top-left"); map.on("load", () => { // Convert Amazon Location Service route to GeoJSON const featureCollection = amazonLocationDataConverter.routeToFeatureCollection(route); // Add a data source containing GeoJSON produced from the Amazon Location Service プレースインデックス output. map.addSource("route", { type: "geojson", data: featureCollection, }); // Add a new layer to visualize the points. map.addLayer({ id: "route", type: "line", source: "route", layout: { "line-join": "round", "line-cap": "round", }, paint: { "line-color": "#00b0ff", "line-width": 8, }, }); }); } initializeMap(); </script> </body> </html> その他のデータ型変換については、GitHub の aws-geospatial/amazon-location-utilities-datatypes-js リポジトリで、これらのユーティリティの使い方や提供されているその他の変換の詳細をご覧ください。 クリーンアップ 以下のリンクを使用して、 マップ 、 プレースインデックス 、 ルート計算 リソースを削除します。本記事で作成した API キーを削除するには、 こちら の手順に従ってください。 まとめ 新しい Amazon Location Service Auth Helper Library は、Amazon Location Service API キーおよび Amazon Cognito Identity Pools とのシームレスな統合を提供することで、地理空間アプリケーションの構築を簡素化します。Auth Helper Library を使用することで、開発者はアプリケーションで Amazon Location Service マップ、プレース、ルートと簡単に連携することができます。 また、GeoJSON のような Amazon Location Service と互換性のある異なるデータ型間で変換する機能も開発者に提供しました。これらのユーティリティを使うことで、開発者は GeoJSON を受け取ってジオフェンスを作成したり、プレースインデックス、ジオフェンス、ルートから GeoJSON 出力を得たりすることができます。 これにより、地理空間アプリケーション用の MapLibre などの一般的なライブラリの開発が容易になります。 より多くのサンプルアプリケーションについては、GitHub にホストされている aws-geospatial リポジトリを訪問し、Amazon Location Service が提供する機能をインタラクティブに見るためには location.aws.com デモサイトをチェックしてください。 本記事は「 Build a Geospatial Application with Amazon Location Service API Keys 」を翻訳したものです。 著者について Zach Elliott Zach Elliott は、AWS で Amazon Location Service にフォーカスしたソリューションアーキテクトとして働いています。彼は、お客様が AWS 上で地理空間ソリューションを構築するのを支援することに情熱を注いでいます。彼はまた、AWS の IoT Subject Matter Expert コミュニティの一員でもあり、顧客がユニークな IoT ベースのソリューションを開発するのを支援するのが大好きです。 Anand Vijayan Anand Vijayan は AWS で Amazon Location Service にフォーカスしたシニア・プロダクト・マネージャーとして働いている。地理空間テクノロジーに興奮し、クラウドのパワーを活用して顧客が複雑な問題を大規模に解決できるよう支援することに喜びを感じています。彼は熱心な天文学者であり、あらゆる宇宙に強い関心を持っています。 Seth Fitzsimmons Seth は Amazon Location Service をサポートするプリンシパルエンジニアです。余暇には、太平洋岸北西部の川や山で水遊びをしています。 Oren Weiss Oren Weiss は Amazon Web Service でソリューションアーキテクトとして働いている。それ以前は、Amazon Location Service を含む複数のチームでソフトウェア開発マネージャーを務めていた。お客様が AWS 上で革新的でスケーラブルかつコスト効率の高いソリューションを構築できるよう支援することに情熱を注いでいます。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

テキストによる指示から様々なタスクを高精度に行えるのは生成系 AI の特徴の一つです。メールのドラフトを作成したり、アイデアについて意見を求めたり、ちょっとした資料に使うイラストを作成するのは生成系 AI の代表的なユースケースです。 PartyRock は生成系 AI の様々なユースケースをアプリケーションとして実現し、共有を可能にする AWS の新しいサービスです。テキストによる指示と画面操作のみで生成系 AI を組み込んだアプリケーションを作り、共有することができます。次の画面ショットは、私が作成したテキストから資料に使うクリップアートを生成するアプリケーションです。 PartyRock は作ったアプリケーションの共有ができると書きましたが、 こちらのリンク から実際に利用いただくことができます。 PartyRock の背後ではもちろん Amazon Bedrock が使用されています。 Amazon Bedrock では複数の基盤モデルが選択でき、 PartyRock はそれらを組み合わせるインターフェースを提供します。 PartyRock を利用するのに AWS アカウントやクレジットカードは必要ありません。エンジニアの方はもちろん、プログラミングの経験がない方でも簡単かつ無料で使うことができます。 1. PartyRock でアプリケーションを作る partyrock.aws にアクセスしましょう。画面右上の “Sign in” からログインをします。 PartyRock ではソーシャルログインが可能です。お好きな方法でアカウントの作成・認証を行ってください。 ログインするとトップページに戻ってきます。 “Build your own app” を押しましょう。 App builder が立ち上がります。どんなアプリケーションを作りたいか入力し、 “Generate app” を押します。 ( 日本語への対応は明言されていませんが、試したところある程度解釈できるようです ) 。ゼロベースで作成したい場合は “Start from an empty app” を押します。ここでは「入力されたテキストからプレゼン資料で使えるクリップアートを生成するアプリケーション」と入力しました。 アプリケーションが出来上がりました。要望に沿いある程度自動的に作成してくれます。 input にテキストを入れると Generated Image に画像が作成され、 Prompt に代替テキストが出力されました。日本語で作成しましたが、おおむね意図に沿った内容になっていると思います。 もちろん、自動作成されたアプリケーションを編集したいこともあるでしょう。次のセクションでは PartyRock のアプリケーションをカスタマイズする方法をご紹介します。 2. PartyRock のアプリケーションをカスタマイズする Edit のボタンを押すことでカスタマイズができます。 PartyRock のアプリケーションは、ウィジェットを組み合わせるように作成します。各ウィジェットには、①プロンプトやモデルなどの詳細設定をするための Edit ボタン、②大きさを調整する角が付属しています。ウィジェットは、次の図 ③ のように “+Add Widget” のメニューか空きスペースの “Create Widget” のテキストを押すことで作成できます。 ウィジェットの種類は次の通りです User Input : ユーザーのテキスト入力を受け付ける。必ず 1 つは必要。 Static Text : 事前入力されたテキストを表示する。アプリケーションの説明文を書くときなどに使用。 Text Generation : テキストを生成する。 Image Generation : 画像を生成する。 Chatbot : チャットボットとの対話を行う。 ウィジェット同士を連携させるにはどうしたらよいでしょうか ? 例えば、 “User Input” をもとに “Image Generation” をしたいなどです。その際は、ウィジェットの右上にある Edit ボタンを押すことでウィジェットの編集メニューを開き、プロンプトの編集ボックスで “@” をつけることで他ボックスの入力を参照してプロンプトを作成できます。 公開時点では、テキストモデルについてモデルの設定ができます。後述する通り、高性能なモデルほど多くのクレジットを消費します ( 後述しますが、クレジット = 課金額ではないためご安心ください ) 。たとえば、下図では Cohere Command より Claude が 3 倍のクレジットを使用することになります ( 画面は執筆時点のものです ) 。 このように、様々なウィジェットを組み合わせながらアプリケーションを作ることができます。 3. PartyRock でアプリケーションを公開する アプリケーションを作ったら誰かに使ってほしいものです。 “Make public and Share” を押すことでアプリケーションの公開リンクを取得することができます。リンクを共有することで Bedrock してもらうことができます。 ぜひいろいろなアプリケーションを作ってみてください！ PartyRock する際の注意事項 最後に、 PartyRock を利用する際の注意事項を記載しておきます。 オプトアウトポリシー PartyRock へ入力するデータはデフォルトで PartyRock の開発と改善、またサービスを運用するためのモニタリングに利用されます。これを許容しない場合、 My Apps の画面 からオプトアウトができます。詳細は FAQ を参照ください。 クレジット PartyRock は無料で使えますが無限に使えるわけではありません。アカウントごとクレジットが割り当てられており、入出力したトークンの量に応じ消費されていきます。現状クレジットを回復する手段は提供されていないのでご注意ください。一方で、安心頂きたいのは公開したアプリが使われてもクレジットは消費されません。自分自身が使った場合のみ消費されます。 おわりに PartyRock により、プログラミング不要で生成系 AI を用いたアプリケーションを作成し他の人に提供できるようになりました。 AWS では AI/ML のユースケースを発見する “ ML Enablement Workshop ” の資料をすでに無料で公開しており、  PartyRock と組み合わせることで簡単なユースケースであれば発見から検証までを迅速に行うことができるようになりました。 PartyRock は今後使えるモデルやウィジェットが増えていくと “ Build AI apps with PartyRock and Amazon Bedrock ” にてアナウンスされています。生成系 AI によるサービスや業務の改革をより一層進めていくために役立てていただければ幸いです。 著者プロフィール 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械学習領域のデベロッパーリレーションを担当しており、「機械学習をするなら AWS 」と感じて頂くべくコンテンツの作成とフィードバックの収集による AWS サービスの改善を行っています。

データ量とユーザー数が増えるにつれて、アプリケーションのパフォーマンスと応答時間を改善する一方で、データベースのコストを最適化しなければならないという課題に直面することがよくあります。大量のデータとスループットを持つインターネット規模のアプリケーションには、マイクロ秒単位のレイテンシーをサポートできる基盤となるデータアーキテクチャが必要です。アプリケーションのパフォーマンスを向上させることで、お客様は応答時間を短縮し、外部および内部のユーザーにより良いサービスを提供できるようになります。インメモリキャッシュは、アプリケーションのパフォーマンスを向上させると同時に、お客様が費用対効果の高い方法でビジネスを成長させ、市場を拡大できるようにします。 データベースに分散結果セットキャッシュを追加することは、アプリケーションのパフォーマンスを向上させ、コストを削減するための一般的な方法です。 Grab、Wiz、DBS Bank は、 Amazon ElastiCache for Redis をプライマリデータソースと組み合わせて使用し、リアルタイムアプリケーションのパフォーマンスニーズをコスト効率よく実現している多くのお客様の一例です。ElastiCacheはフルマネージド型のRedis互換のサービスで、最新のアプリケーションにリアルタイムで最適化されたパフォーマンスを提供します。ElastiCacheは、マイクロ秒の応答時間で毎秒数億オペレーションまでスケールし、エンタープライズグレードのセキュリティと信頼性を提供します。お客様はElastiCacheを、アプリケーションやデータベースのパフォーマンスを高速化するため、あるいはデータの耐久性を必要としないユースケース（例えばセッションストア、ゲームリーダーボード、ストリーミング、データ分析、ML推論用のフィーチャストアなど）のプライマリデータストアとして使用しています。このブログ記事では、Amazon ElastiCache をクエリキャッシュとして利用することでリレーショナルデータベースのコストを最適化する方法を解説します。ここで使用されたデータは、インスタンスタイプdb.r6g.xlargeの Amazon RDS for MySQL バージョン8.0.28で実行したベンチマークテストに基づいています。ベンチマークテストでは、Amazon ElastiCacheでクエリ結果をキャッシュしています。 Amazon ElastiCache for Redis Amazon ElastiCache は AWS が提供する目的別キャッシュサービスです。 ElastiCache はプライマリデータソースを補完し、わずかなコストで全体的なパフォーマンスを最適化し、迅速なスケーリングを可能にします。 ElastiCache は、次のような機能を備えたフルマネージド型の AWS サービスです。 非常に高速 — ミリ秒未満の応答時間でインメモリキャッシュとして機能します。 ワークロードのニーズに合わせて、中断することなく垂直方向と水平方向の両方に拡張できます。 エンジンのマイナーバージョンアップを含む、ハードウェアとソフトウェアの管理をフルマネージドで行えます。 サービス中断時の自動フェイルオーバーや自動インスタンス復旧など、マルチ AZ 機能により高い可用性を実現しています。 さまざまなワークロードに対応する自動スケーリング機能を備え、データ階層化やリザーブドインスタンスタイプもサポートしています。 オープンソースの Redis と互換性があります。 Amazon ElastiCache によるAmazon RDS for MySQLのコスト最適化 Oracle、SQL Server、Amazon RDS などのリレーショナルデータベースにキャッシュソリューションとして ElastiCache を実装すると、アプリケーションのパフォーマンスを向上させ、コストを削減することができます。 ElastiCache を RDS for MySQL と組み合わせて使用することにより、RDS for MySQL を単独で利用した場合と比較して、コストを最大 55% 節約し、読み取りパフォーマンスを最大 80 倍高速化することができます。 ElastiCache は結果セットをキャッシュし、データベース I/O をオフロードすることで、コストを削減し、データベースとアプリケーションの両方のパフォーマンスを向上させることができます。 プライマリデータソースの前にキャッシュレイヤーを追加する方が、データベースインスタンスのキャパシティを大きくするよりも費用対効果が高くなります。 1 つの ElastiCache ノードは 1 秒あたり 250,000 件を超えるリクエストを処理できます。 同じ結果セットを返す共通のデータベースクエリを使用する読み取り負荷の高いワークロードでは、クエリ結果をキャッシュすることで大きなメリットが得られます。 一方、すべてのデータベースワークロードでキャッシュサービスを追加してもメリットがあるわけではありません。ほとんどのトランザクションが挿入または更新である書き込み負荷の高いデータベースは適していません。ストアドプロシージャやトリガーによるカスケードアップデートのようなデータベースレベルの処理を必要とするアプリケーションも、キャッシュの恩恵を受けません。 ElastiCache は、以下のようなアプリケーションによく適合します。 大量のスループットを処理する必要があるアプリケーション 短い間隔でトラフィックピークが増加するようなアプリケーション データベース更新の前にメモリ内の大量のデータをリアルタイムで処理して統合するアプリケーション 即時のユーザー応答をサポートする必要があるアプリケーション ElastiCache + プライマリデータソース ElastiCache は、MySQL、Oracle、PostgreSQL、SQL Server などのリレーショナルデータベースや、 Amazon DynamoDB や Amazon DocumentDB (with MongoDB compatibility) などの NoSQL データベース、 Amazon Simple Storage Service (Amazon S3)で使用できます。また、マイクロサービス間のようなデータベース層でなくても使用できます。 図 1 — Amazon ElastiCache により、様々なデータソースをキャッシュ ElastiCache により、リードレプリカの使用量を削減し、コストを節約する 下の図では、RDS for MySQLリードレプリカをElastiCache クラスターの読み取りキャパシティに置き換えました。分散された ElastiCache クラスターを追加する方が、リードレプリカを追加するよりもコストがかかりません。同等のレベルの読み込みキャパシティを低コストで実現でき、パフォーマンスも向上します。キャッシュは専用のメモリ、ネットワーク、CPU を提供するため、レイテンシーが大幅に改善し、スループットが大幅に向上します。 ここでデータベースの全てのデータをキャッシュに複製しているわけではないことを覚えておく必要があります。 キャッシュする必要があるのはクエリの結果だけなので、データベースを完全に複製する必要はありません。 図 2 — Amazon ElastiCache を利用して、RDS レプリカの必要量を減らす キャッシュ — アプリケーション実装戦略 以下は、データをキャッシュするためにアプリケーション実装戦略です。 レイジーロードキャッシュ レイジーロード 戦略は、レイジーポピュレーションまたはキャッシュアサイド戦略とも呼ばれ、お客様に最もよく利用されているキャッシュ戦略です。 基本的な考え方は、アプリケーションが実際にオブジェクトを要求したときにのみキャッシュにデータを入力することです。 全体的なアプリケーションフローは次のようになります。 例えば最新のニュース記事の上位10件など、アプリケーションがクエリを受け取ります。 アプリケーションはキャッシュをチェックし、オブジェクトがキャッシュ内にあるかどうかを確認します。 その場合 (キャッシュヒット)、キャッシュされたオブジェクトが返され、コールフローが終了します。 そうでない場合 (キャッシュミス)、データベースにオブジェクトを問い合わせます。 データベースからロードされたデータは、次回のためにキャッシュに入力され、クエリの結果としてオブジェクトが返されます。 図 3 — レイジーロードまたはキャッシュアサイド戦略 ライトスルーキャッシュ 一貫性を必要とするワークロードでは、ソースデータストア内のデータが変更されたときに、 ライトスルー 戦略を使用してキャッシュを更新できます。 ライトスルーでは、ソースデータストアの更新時に変更を検出しキャッシュを更新するメカニズムか、データが変更されたときにお客様がキャッシュとソースの両方に二重書き込みプロセスを実装することが必要です。 ライトスルーを実装するクライアントアプリケーションはデータベースを更新し、書き込みが成功するとデータベースからデータを読み取り、新しいクエリ結果を同期的にキャッシュします。 図 4 — ライトスルー戦略 アプリケーションは Redis クライアント API を介して ElastiCache で構成されるキャッシュレイヤーを呼び出します。 レイジーロード戦略はデータをキャッシュに読み込むのに役立ちますが、その主な目的は、データが存在する場合にプライマリデータソースにアクセスせずキャッシュからデータを読み取ることです。 ライトスルー戦略はデータをデータベースと同期させるのに役立ちますが、一般的にはレイジーローディング戦略とライトスルー戦略の両方を実装し、データが存在する場合はキャッシュから読み取り、キャッシュに書き込んでデータを最新の状態に保ちます。 ElastiCache for Redis のキャッシュ戦略の詳細については、 こちら を参照してください。 RDS for MySQL + ElastiCache – Better Together の例 読み取りと書き込みの比率が80:20で、読み取られたデータの 80% がキャッシュされている場合 キャッシュのパフォーマンス上の利点、コスト上の利点、アプリケーション実装戦略について説明したところで、コスト削減とパフォーマンス向上の例を見てみましょう。 30,000 クエリ/秒 (QPS) のスループットを実現する必要があるとしましょう。 この要件を満たすには、RDS for MySQL のリードレプリカを利用する方法と、RDS + ElastiCache を利用する方法があります。 ElastiCache を利用せずに RDS だけを利用する場合、スループット要件を満たすには RDSの リードレプリカが 4 つ必要になり、そのコストは 1 か月あたり 1,740 USD ( db.r6g.xlarge )になります。 RDS + ElastiCache を使用する場合、リードレプリカを排除し、代わりに 1 つの ElastiCache ノードとそのリードレプリカノードで同じスループットを実現できます。 RDSのリードレプリカの代わりに ElastiCache を利用すると、1 か月あたり 780 USD の費用がかかります。 ElastiCache と RDS のコストは、リードレプリカに RDS だけを使用する場合と比べて 55% のコスト削減につながります。 以下の表は、使用するノードとそのコストの詳細を示しています。 メトリクス RDS プライマリのみ RDS プライマリ + リードレプリカ RDS プライマリ + 4 リードレプリカ RDS プライマリ + 2 ElastiCache node 平均待機時間 200 ミリ秒 80 ミリ秒 80 ミリ秒 1 ミリ秒 平均読取QPS 8,000 QPS 16,000 QPS 30,000 QPS 32,000 QPS コスト $/月 348 $/月 696 $/月 1,740 $/月 780 $/月 使用ノード 1 read/write db.r6g.xlarge 1 writer 1 reader = 2x db.r6g.xlarge 1 writer 4 reader = 5x db.r6g.xlarge 1x db.r6g.xlarge + 2x cache.m6g.xlarge RDS for MySQLの設定とデータベースサイズ: データセットサイズ：~80GB ストレージ：300GB RDS ノード：MySQL version 8.0.28, db.r6g.xlarge テストSQL： SELECT firstname, lastname, from_airport FROM booking WHERE passenger_id = <passenger id> より高いスループットでのコスト削減 – 100% のデータをキャッシュし、さらなるコスト削減を行う キャッシュを実装すると、アプリケーションのスループット要件が高ければ高いほど、コスト削減効果も大きくなります。 以下の例では、キャッシュが完全にウォームアップされる (つまり、読み取られるすべてのデータが ElastiCache によって処理される)と、読み取り容量は 250,000 QPS に達します。RDS だけでは、このスループットをサポートするコストは 87% 高くなります。 スループットの高い、読み取り量の多いアプリケーションにキャッシュを実装することで、コストを大幅に削減できます。 メトリクス 1 RDS + 9 RDS read replicas 1 RDS + 1 RDS read replica + 1 ElastiCache + 1 EC read replica 平均待機時間 80 ms 9 ms 平均読取QPS 250,000 250,000 コスト $/月 7,840 $/月 784 $ (RDS) + 432 $ (EC) /月 使用ノード 10 x db.r6g.xlarge 2 x db.r6g.xlarge + 2 x cache.m6g.xlarge 結論 RDS などのプライマリリレーショナルデータベースに ElastiCache を実装することで得られるコスト削減は、アプリケーションに必要な読み取りスループットに比例します。 必要な読み取りスループットが高ければ高いほど、コスト削減量も大きくなります。 これは、スループットが増加するにつれて、リレーショナルデータベースのスケーリングにかかるコストが高くなるためです。 一方、各 ElastiCache ノードは 1 秒あたり最大 400,000 件(*1)のクエリのスループットをサポートできます。 ElastiCache をアプリケーションアーキテクチャに追加することで、パフォーマンスを向上させ、コストを削減できます。 (*1 訳注：Amazon ElastiCache for Redis 7.1の登場により、さらに最大スループットが向上しました。例えばr7g.4xlargeを用いたテストではRedis 7.0と比較してスループットが100%以上向上し、1 秒あたり1,000,000 件以上のリクエストを処理しました。詳細は こちら のブログをご覧下さい) Amazon ElastiCache を使い始めるには、 入門ガイド 、 自習型学習コース 、または オンデマンド学習パス を参照してください。 Amazon ElastiCache 製品ページにアクセスして、その他のリソースを検索したり、詳細を確認したりすることもできます。 より詳細なガイダンスについては、AWS アカウントチームに連絡して Amazon ElastiCache スペシャリストによる詳細なセッションをスケジュールしてください。 このブログで説明されているキャッシュ戦略を実装するサンプルコードを Github リポジトリ からダウンロードすることもできます。 本記事は、Sashi Varanasi, Steven Hancz, Roberto Luna Rojas らの「 Optimize cost and boost performance of RDS for MySQL using Amazon ElastiCache for Redis 」を翻訳したものです。翻訳は ソリューションアーキテクトの 堤 勇人が担当しました。

セキュリティはAWS にとって、また多くのお客様にとって最優先事項となります。 AWS では、2021年3月に 日本の政府調達におけるクラウドサービスの評価制度である「政府情報システムのためのセキュリティ評価制度（Information system Security Management and Assessment Program: ISMAP（以下、ISMAPと表記）」に登録されました。本制度において最初から登録されたクラウドサービス事業者のうちの一つとなります。そして、このたび、2023年に登録された内容を踏まえたISMAP Customer Packageの更新版が掲載されました。 ISMAP Customer Packageの入手は、AWS マネジメントコンソール上のAWS Artifactから行います。AWS Artifactの”View reports” より、”ISMAP Customer Package”　を検索すると日本語版および英語版が表示されますので、Artifact NDA に合意の上、ダウンロードしてください。 また、今回の発行にともない、ISMAPに関して特にいただくお問い合わせをご紹介いたします。 ISMAPに関してよくあるお問い合わせ：AWSの〇〇というサービスはISMAPに登録されていますか まず、お答えとしては、 ISMAPに登録された”サービス”は”Amazon Web Services”です。 ISMAPに関連して頂くお問い合わせとして、”AWSの〇〇というサービスはISMAPに登録されているか”といったお問い合わせがあります。ISMAPにおける定義において、私たちが登録しているサービスは”Amazon Web Services”というサービスであり、 ISMAP Portal に掲載されています。クラウドサービス事業者によっては、複数のサービスをISMAPのサービスとして登録しているケースがありますが、何らかの形で同質性に違いがある場合、別のサービスとして登録することが必要になります。AWSのサービスにおける同質性の考え方は こちらのBlog をご参照ください。 一方、監査を行うタイミングにおいて適切な運用機関に基づく証跡を確認した対象範囲として、”AWSのサービス”を登録時に掲載しています。制度上、どの程度の粒度として対象範囲を記述するかはクラウドサービス事業者に依存するものとなりますが、同質性を担保できるうえでは登録されたサービスにおける機能一覧といった位置づけに近いものとなり、以後のアップデートも機能の追加に近しいものとなります。制度の性質上、新しく発表されたAWSのサービスが直ちに対象範囲に反映されることは困難ですが、原則として新たに登録されたAWSのサービスにおいても、同等の水準のセキュリティとして運用を行っています。継続的な統制はSOC等の様々なコンプライアンスプログラムによっても評価することが可能です。 調達等において、”〇〇というサービスがクラウドサービス事業者の対象範囲にない”場合は、上記の理解を前提に、そもそもISMAPが対象としているサービスなのか（ISMAP Portalのサービスリストに掲載されるレベルなのか）、そのうえで評価対象がどのような水準で運用されているかを確認する、というステップになります。 ISMAPに関してよくあるお問い合わせ：AWS上で提供される他のサービスに対する責任共有モデルはどう考えたらよいか AWSが提供している様々なサービスの中では、AWSが単独で提供するものではなく、他のサービス事業者が提供しているものや、AWS上でソフトウェア等が提供され、お客様が利用するケースがあります。具体的には、 AWS Market place でお客様が利用可能な様々なサービス、 VMware Cloud on AWS などの他の事業者が提供するサービス、 基盤モデル やOSSのテンプレートやソリューション等が該当します。このような場合、責任共有モデルに基づきAWSが提供する範囲と他の事業者、お客様が有する責任の範囲は異なることにご留意ください。また、OSSのテンプレートや基盤モデル、ソフトウェアパッケージなど、クラウドサービスという定義に該当しない多様なケースが存在することにもご留意ください。 ISMAP Customer Package は、日本語および英語にて提供されます。AWS のお客様、政府調達に関わる関係者の皆様、今後の様々なコンプライアンスの推進を行う上でISMAPの理解を深めたい様々なお客様、ISMAP に登録を考えておられるAPN パートナーの皆様は、ISMAP Customer Package を通じて責任共有モデルおよびISMAP に基づくAWS とお客様自身の責任範囲の理解が容易になります。さらにはISMAP に限らずAWSのコンプライアンスを理解したいお客様に対しても様々な情報を提供するものとなりますので、ご活用いただければ幸いです。 このブログの著者 松本　照吾（Matsumoto, Shogo） セキュリティ アシュアランス本部 本部長

はじめに コンタクトセンターのスーパーバイザー、マネージャー、コンプライアンス、ワークフォースアナリストなどは、Amazon Connect コンソールのリアルタイムメトリックスダッシュボードを使用して、エージェント、キュー、ルーティングプロファイルのパフォーマンスを含む、コンタクトセンターのリアルタイムパフォーマンスを監視します。 さらに、 以前のブログ記事 で述べたように、今日の組織は、地域・業界、またビジネスニーズによって異なる、プライバシーや規制の課題に直面しています。こうしたプライバシー規制に準拠するために、コンタクトセンターの管理者は、コンタクトセンター内で使用される機密リソース、特にリアルタイムメトリクスに対して、最小アクセス権限の実装を求められることが頻繁にあります。 コンタクトセンターでは、多くの場合、個別の事業部門または組織毎のアクセスコントロールが必要です。 タグベースのアプローチ は、コンタクトセンターのこのような動的なアクセスコントロールの要望をサポートするための柔軟性とスケーラビリティを提供します。 このブログ記事では、架空の会社 Octank 社の管理者が、ライブモニタリングやエージェントへの割り込みなど、エージェント、キュー、ルーティングプロファイルのリアルタイムメトリクスへのユーザーアクセスを制限する方法について説明します。Octank 社が運用を継続し、ビジネス上の意思決定を行う中で、より細かいアクセスコントロールの要件も変化します。3 つの段階のそれぞれについて、より細かいアクセスコントロールの要件を満たすためのタグベースのアクセスコントロールの柔軟性を実証します。 ソリューション概要 各段階でのソリューションのデプロイには、次の手順が含まれます。 リソースタグを使用してエージェント、キュー、ルーティングプロファイルを設定します コンタクトセンターのさまざまなペルソナを表す、アクセスコントロールタグを使用したセキュリティプロファイルを設定します コンタクトセンターのペルソナのユーザーを設定し、セキュリティプロファイルに関連付けます 次の図は、Amazon Connect のタグベースのアクセスコントロールを示しています。リソースには リソースタグ が付けられています。セキュリティプロファイルにはアクセスコントロールタグが設定されます。これらのセキュリティプロファイルがユーザーに割り当てられると、そのユーザーのリソース、データ、およびメトリクスへのアクセスが アクセスコントロールタグ に基づいて制限されるようになります。アクセスコントロールタグが「LOB: Credit」のセキュリティプロファイルは、「LOB: Credit」のリソースタグでタグ付けされたリソース (Agent1) のみアクセスを許可します。アクセスコントロールタグが「LOB: Banking」のセキュリティプロファイルは、「LOB: Banking」のリソースタグでタグ付けされたリソース (Agent2) のみアクセスを許可します。 前提条件 このチュートリアルは、以下のリソースを理解し、アクセスできることを前提としています。 関連する以前のブログ記事「 リソースタグによる Amazon Connect のより細かいアクセスコントロールの実現 」 Amazon Connect の管理者アクセス権を持つ AWS アカウント 作成 済みの Amazon Connect インスタンス 管理者権限 (Admin) の セキュリティプロファイル を持つ Amazon Connect ユーザー AWS リソースのタグ付け に関する基本的な知識 チュートリアル シナリオとペルソナ Octank 社は、コンタクトセンターを運営する架空の金融サービス会社です ユーザーペルソナには、エージェント、スーパーバイザー、コンタクトセンターマネージャー、管理者が含まれます エージェント : 顧客からの電話等の問い合わせに応答・対応します スーパーバイザー : エージェントのグループを監視し、必要に応じて指導します コンタクトセンターマネージャー : コンタクトセンターとその従業員の日常業務を監督します コンタクトセンター管理者 : コンタクトセンターのセットアップと設定を管理します セキュリティプロファイルの管理は管理者のみ可能です ペルソナごとに最小限のサンプルユーザーが含まれ、ルーティングプロファイルとキューは 1 対 1 で対応しています 最小権限アクセスコントロール :各ペルソナは、最も近い境界内にあるリソースへのリアルタイムレポート、ライブモニタリング、およびバージインアクセスのみにアクセスできます 各段階は独立して実装できます 段階 1 Octank 社には、 クレジット と バンキング という 2 つの事業部門 (LOB) があります。各 LOB にはエージェント、スーパーバイザー、コンタクトセンターマネージャーがいます。Octank 社は、Credit LOB の担当者がバンキング LOB のエージェント、キュー、ルーティングプロファイルのリアルタイムメトリクスを見ることができないようにする必要があります。逆もまた同様です。例えば クレジット LOB のコンタクトセンターマネージャーは、クレジット LOB 内のエージェント、キュー、ルーティングプロファイルのみをリアルタイムメトリクスで見ることができます。コンタクトセンター全体の管理者は両方の LOB にアクセスできます。 アクセスコントロールの粒度は LOB に基づいているため、2 つの LOB ( LOB: Credit と LOB: Banking ) を表すリソースタグとアクセスコントロールタグを作成します。 手順 1: キュー、ルーティングプロファイル、エージェントおよびそのリソースタグの設定 キューの名前 リソースタグ (キー:値のペア) Credit LOB: Credit Banking LOB: Banking ルーティングプロファイルの名前 リソースタグ Credit LOB: Credit Banking LOB: Banking エージェントのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル リソースタグ MJackson Mateo Jackson Agent(default) Credit LOB: Credit RRoe Richard Roe Agent(default) Banking LOB: Banking 手順 2: アクセスコントロールタグとセキュリティプロファイルの設定 コンタクトセンター管理者は、デフォルトの Admin セキュリティプロファイルを使用します。 管理者のログイン 名 姓 セキュリティプロファイル ルーティングプロファイル NWolf Nikki Wolf Admin(default) Basic Routing Profile コンタクトセンターマネージャー向けに、 ManagerCredit と ManagerBanking の 2 つのセキュリティプロファイルを作成し、アクセスコントロールタグを使用してアクセスをそれぞれの LOB に制限します。リアルタイムレポート向けに、各セキュリティプロファイルには、ユーザー、ルーティングプロファイル、キューを表示する権限と、リアルタイムメトリクス、リアルタイムモニタリング、リアルタイムコンタクト割り込みの権限が必要です。 セキュリティプロファイル名 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ ManagerCredit ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Credit ManagerBanking ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Banking スーパーバイザー向けに、 SupervisorCredit と SupervisorBanking の 2 つのセキュリティプロファイルを作成し、アクセスコントロールタグを使用してアクセスをそれぞれの LOB に制限します。リアルタイムレポート向けに、各セキュリティプロファイルには、ユーザ、ルーティングプロファイル、キューを表示する権限と、リアルタイムメトリクス、リアルタイムモニタリング、リアルタイムコンタクト割り込みの権限が必要です。 セキュリティプロファイル名 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ SupervisorCredit ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Credit SupervisorBanking ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Banking ここまでの手順で 4 つの異なるペルソナを表す合計 4 つのセキュリティプロファイルを作成しました。管理者はデフォルトの Admin セキュリティプロファイルを使用しました。 手順 3: コンタクトセンターマネージャーの設定とセキュリティプロファイルの紐づけ 構成をテストおよび検証するために、コンタクトセンターマネージャーのユーザーを 2 つ作成します。各ユーザーを、前の手順で作成した適切なセキュリティプロファイルに関連付けます。 マネージャーのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル MRivera Martha Rivera ManagerCredit Basic Routing Profile ADesai Arnav Desai ManagerBanking Basic Routing Profile 次に、2 人のスーパーバイザーユーザーを作成して構成をテストおよび検証します。各ユーザーを、前の手順で作成した適切なセキュリティプロファイルに関連付けます。 スーパーバイザーのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル JStiles John Stiles SupervisorCredit Basic Routing Profile LJuan Li Juan SupervisorBanking Basic Routing Profile 手順 4: テストと検証 より細かいアクセスコントロールを確認する手順は以下の通りです。 ブラウザのシークレットモードを利用して、Amazon Connect 管理コンソールに作成した管理者アカウント NWolf でサインインします ナビゲーションメニューの 分析 と 最適化 からリアルタイムメトリクスを選択します キューを選択して、前のステップで設定したすべてのキューのリアルタイムメトリクスを確認できることを確認します リアルタイムメトリクスページに戻ります。 ルーティングプロファイル を選択し、前の手順で設定したルーティングプロファイルがすべて表示されていることを確認します リアルタイムメトリクスページに戻ります。 エージェント を選択し、前のステップで設定したすべてのエージェントのリアルタイムメトリクスを確認できることを確認します 前の段階の手順で設定した 2 つのマネージャーのユーザー名と 2 つのスーパーバイザーのユーザー名を使用して、シークレットウィンドウで各ユーザーで Amazon Connect コンソールにログインします 各ユーザー名で以下を確認します 前述の検証ステップ 2 から 5 に従って、LOB (クレジットまたはバンキング) 内のキュー、エージェント、ルーティングプロファイルのみを確認できることを確認します すべてのエージェントのライブ会話またはライブチャットを リアルタイムで監視 できることを確認します 監視しているライブ会話で、エージェントとの 会話に割り込める ことを確認します 段階 2 ビジネスが成長し、Octank 社は英語とスペイン語の 2 つの言語で顧客をサポートすることにしました。Octank 社は米国とアルゼンチンに拠点を置いています。彼らは、米国に拠点を置くチームを使用して英語の顧客をサポートし、アルゼンチンに拠点を置くチームを使用してスペイン語の顧客をサポートするというビジネス上の決定をしました。LOB ごとに、米国とアルゼンチンのチームにはエージェントとスーパーバイザーがいます。コンタクトセンターのマネージャーは、LOB 内およびすべての国のチームを引き続き管理します。ただし、Octank 社では、各国のチームがエージェント、キュー、ルーティングプロファイルを含むリアルタイムのレポートをその国でのみ閲覧できるようにすることを義務付けています。段階 1 からの LOB レベルの制限は引き続き適用されます。 アクセスコントロールの粒度は LOB と国に基づいているため、2 つの LOB と 2 つの国 ( LOB: Credit 、 LOB: Banking 、 Country: UnitedStates 、 Country: Argentina ) を表すリソースタグとアクセスコントロールタグを作成します。 手順 1: キュー、ルーティングプロファイル、エージェントおよびそのリソースタグの設定 キューの名前 リソースタグ リソースタグ CreditUS LOB: Credit Country: UnitedStates CreditArgentina LOB: Credit Country: Argentina BankingUS LOB: Banking Country: UnitedStates BankingArgentina LOB: Banking Country: Argentina ルーティングプロファイルの名前 リソースタグ リソースタグ CreditUS LOB: Credit Country: UnitedStates CreditArgentina LOB: Credit Country: Argentina BankingUS LOB: Banking Country: UnitedStates BankingArgentina LOB: Banking Country: Argentina エージェントのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル リソースタグ リソースタグ MJackson Mateo Jackson Agent(default) CreditUS LOB: Credit Country: UnitedStates JSouza Jorge Souza Agent(default) CreditArgentina LOB: Credit Country: Argentina RRoe Richard Roe Agent(default) BankingUS LOB: Banking Country: UnitedStates MMajor Mary Major Agent(default) BankingArgentina LOB: Banking Country: Argentina 各リソースに 2 つのリソースタグが使用されていることに注意してください。これは、LOB と国、 2 段階のアクセスコントロールの粒度の要件に対応するためです。 手順 2: アクセスコントロールタグとセキュリティプロファイルの設定 コンタクトセンター管理者は、デフォルトの Admin セキュリティプロファイルを使用します。 管理者のログイン 名 姓 セキュリティプロファイル ルーティングプロファイル NWolf Nikki Wolf Admin(default) Basic Routing Profile コンタクトセンターマネージャー向けに、 ManagerCredit と ManagerBanking の 2 つのセキュリティプロファイルを作成し、アクセスコントロールタグを使用してアクセスをそれぞれの LOB に制限します。リアルタイムレポート向けに、各セキュリティプロファイルには、ユーザー、ルーティングプロファイル、キューを表示する権限と、リアルタイムメトリクス、リアルタイムモニタリング、リアルタイムコンタクト割り込みの権限が必要です。 セキュリティプロファイル名 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ ManagerCredit ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Credit ManagerBanking ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Banking スーパーバイザー向けに、 SupervisorCreditUS 、 SupervisorCreditArgentina 、 SupervisorBankingUS と SupervisorBankingArgentina の 4 つのセキュリティプロファイルを作成し、アクセスをそれぞれの LOB に制限します。リアルタイムレポート向けに、各セキュリティプロファイルには、ユーザ、ルーティングプロファイル、キューを表示する権限と、リアルタイムメトリクス、リアルタイムモニタリング、リアルタイムコンタクト割り込みの権限が必要です。 セキュリティプロファイル名 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ SupervisorCreditUS ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Credit, Country:UnitedStates SupervisorCreditArgentina ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Credit, Country:Argentina SupervisorBankingUS ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Banking, Country:UnitedStates SupervisorBankingArgentina ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Banking, Country:Argentina このステージでは、6 つの異なるペルソナを表す合計 6 つのセキュリティプロファイルを作成しました。管理者はデフォルトの Admin セキュリティプロファイルを使用しました。 リソースタグとアクセスタグを追加する必要があるのは、粒度が要求される場合のみであることに注意してください。この場合、アクセス要件が変わらなかったため、管理者は前の段階と同じセキュリティプロファイルを使用できました。スーパーバイザーは国内でのより細かいアクセスコントロールを必要としていたため、4 つのスーパーバイザーセキュリティプロファイルでは 2 つのアクセスコントロールタグが使用されています。 手順 3: コンタクトセンターマネージャーの設定とセキュリティプロファイルの紐づけ 構成をテストおよび検証するために、コンタクトセンターマネージャーのユーザーを 2 つ作成します。各ユーザーを、前の手順で作成した適切なセキュリティプロファイルに関連付けます。 マネージャーのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル MRivera Martha Rivera ManagerCredit Basic Routing Profile ADesai Arnav Desai ManagerBanking Basic Routing Profile 次に、4 人のスーパーバイザーユーザーを作成して構成をテストおよび検証します。各ユーザーを、前の手順で作成した適切なセキュリティプロファイルに関連付けます。 スーパーバイザーのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル JStiles John Stiles SupervisorCreditUS Basic Routing Profile PCandella Pat Candella SupervisorCreditArgentina Basic Routing Profile LJuan Li Juan SupervisorBankingUS Basic Routing Profile TWhitlock Terry Whitlock SupervisorBankingArgentina Basic Routing Profile 手順 4: テストと検証 より細かいアクセスコントロールを確認する手順は以下の通りです。 ブラウザのシークレットモードを利用して、Amazon Connect 管理コンソールに作成した管理者アカウント NWolf でサインインします ナビゲーションメニューの 分析 と 最適化 からリアルタイムメトリクスを選択します キューを選択して、前のステップで設定したすべてのキューのリアルタイムメトリクスを確認できることを確認します リアルタイムメトリクスページに戻ります。 ルーティングプロファイル を選択し、前の手順で設定したルーティングプロファイルがすべて表示されていることを確認します リアルタイムメトリクスページに戻ります。 エージェント を選択し、前のステップで設定したすべてのエージェントのリアルタイムメトリクスを確認できることを確認します 前の段階の手順で設定した 2 つのマネージャーのユーザー名と 2 つのスーパーバイザーのユーザー名を使用して、シークレットウィンドウで各ユーザーで Amazon Connect コンソールにログインします 各ユーザー名で以下を確認します 前述の検証ステップ 2 から 5 に従って、LOB (クレジットまたはバンキング) 内のキュー、エージェント、ルーティングプロファイルのみを確認できることを確認します すべてのエージェントのライブ会話またはライブチャットを リアルタイムで監視 できることを確認します 監視しているライブ会話で、エージェントとの 会話に割り込める ことを確認します 段階 2 のシナリオの代替策：国レベルの粒度ではなく、2 つの LOB の Octank 社のスーパーバイザーは、グループ内のエージェントのみを確認する必要があります。2 番目のリソースタグは、スーパーバイザー名 ( Group:JStiles ) に変更できます。エージェント、キュー、ルーティングプロファイルに、所属するグループに基づいてリソースタグを割り当てることができます。Octank 社では、スーパーバイザーのセキュリティプロファイルの数はスーパーバイザーのグループの数と同じになります。各スーパーバイザーのセキュリティプロファイルには 2 つのアクセスタグ (LOB と Group) があります。 段階 3 Octank 社のバンキング LOB は、フィリピンを拠点とするビジネスプロセスアウトソーサー (BPO) と契約します。この BPO は、銀行顧客を扱う幅広い専門知識を持ち、より高いサービスレベルを提供します。今後、バンキング LOB は BPO を利用してスペイン語の銀行業務に関する問い合わせを処理することになりました。BPO は、BPO 内のエージェント、キュー、ルーティングプロファイルに関するリアルタイムレポートのみを表示できます。内部チームは BPO のリソースにアクセスできません。BPO メトリクスにアクセスできるのは、管理者とバンキング LOB のコンタクトセンターマネージャーだけです。LOB レベルと国レベルの制限は引き続き適用されます。 アクセスコントロールの粒度は、 LOB 、国、およびエージェントが社内の Octank チームに属しているか、 BPO に属しているかに基づきます。このシナリオでは、国をカプセル化し、エージェントが社内か BPO かを示す複合タグ CenterType の使用方法を示します。加えてその情報を表すリソースタグとアクセスコントロールタグである、 LOB: Credit 、 LOB: Banking 、 CenterType:UnitedStates_Internal 、 CenterType: Argentina_Internal 、 CenterType: Philippiness_BPO を作成します。CenterType タグに指定できる値の数は国の場所の数の 2 倍ですが、ステージ 3 のシナリオを表すのに必要な組み合わせは 3 つだけです。 手順 1: キュー、ルーティングプロファイル、エージェントおよびそのリソースタグの設定 キューの名前 リソースタグ リソースタグ CreditUS LOB: Credit CenterType: UnitedStates_Internal CreditArgentina LOB: Credit CenterType: Argentina_Internal BankingUS LOB: Banking CenterType: UnitedStates_Internal BankingArgentina LOB: Banking CenterType: Philippines_BPO ルーティングプロファイルの名前 リソースタグ リソースタグ CreditUS LOB: Credit CenterType: UnitedStates_Internal CreditArgentina LOB: Credit CenterType: Argentina_Internal BankingUS LOB: Banking CenterType: UnitedStates_Internal BankingBPO LOB: Banking CenterType: Philippines_BPO エージェントのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル リソースタグ リソースタグ MJackson Mateo Jackson Agent(default) CreditUS LOB: Credit CenterType: UnitedStates_Internal JSouza Jorge Souza Agent(default) CreditArgentina LOB: Credit CenterType: Argentina_Internal RRoe Richard Roe Agent(default) BankingUS LOB: Banking CenterType: UnitedStates_Internal PSantos Paulo Santos Agent(default) BankingBPO LOB: Banking CenterType: Philippines_BPO 手順 2: アクセスコントロールタグとセキュリティプロファイルの設定 コンタクトセンター管理者は、デフォルトの Admin セキュリティプロファイルを使用します。 管理者のログイン 名 姓 セキュリティプロファイル ルーティングプロファイル NWolf Nikki Wolf Admin(default) Basic Routing Profile コンタクトセンターマネージャー向けに、 ManagerCredit と ManagerBanking の 2 つのセキュリティプロファイルを作成し、アクセスコントロールタグを使用してアクセスをそれぞれの LOB に制限します。リアルタイムレポート向けに、各セキュリティプロファイルには、ユーザー、ルーティングプロファイル、キューを表示する権限と、リアルタイムメトリクス、リアルタイムモニタリング、リアルタイムコンタクト割り込みの権限が必要です。 セキュリティプロファイル名 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ ManagerCredit ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Credit ManagerBanking ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Banking スーパーバイザー向けに、 SupervisorCreditUSInternal 、 SupervisorCreditArgentinaInternal 、 SupervisorBankingUSInternal と SupervisorBankingPhilippinesBPO の 4 つのセキュリティプロファイルを作成し、アクセスをそれぞれの LOB およびコンタクトセンターの種別の組み合わせで制限します。リアルタイムレポート向けに、各セキュリティプロファイルには、ユーザ、ルーティングプロファイル、キューを表示する権限と、リアルタイムメトリクス、リアルタイムモニタリング、リアルタイムコンタクト割り込みの権限が必要です。 セキュリティプロファイル名 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ SupervisorCreditUSInternal ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Credit, CenterType:United States_Internal SupervisorCreditArgentinaInternal ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Credit, CenterType:Argentina_Internal SupervisorBankingUSInternal ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Banking, CenterType:United States_Internal SupervisorBankingPhilippinesBPO ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Banking, CenterType:Philippines_BPO この段階では、6 つの異なるペルソナを表す合計 6 つのセキュリティプロファイルを作成しました。管理者はデフォルトの Admin セキュリティプロファイルを使用しました。 リソースタグとアクセスタグを追加する必要があるのは、粒度が要求される場合のみであることに注意してください。この場合、アクセス要件が変わらなかったため、管理者は前の段階と同じセキュリティプロファイルを使用できました。スーパーバイザーは国内および担当するエージェントのより細かいアクセスコントロールを必要としていたため、4 つのスーパーバイザーセキュリティプロファイルでは 2 つのアクセスコントロールタグが使用されています。アクセスコントロールのうちの1 つ (CenterType) は複合タグです。 手順 3: コンタクトセンターマネージャーの設定とセキュリティプロファイルの紐づけ 構成をテストおよび検証するために、コンタクトセンターマネージャーのユーザーを 2 つ作成します。各ユーザーを、前の手順で作成した適切なセキュリティプロファイルに関連付けます。 マネージャーのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル MRivera Martha Rivera ManagerCredit Basic Routing Profile ADesai Arnav Desai ManagerBanking Basic Routing Profile 次に、4 人のスーパーバイザーユーザーを作成して構成をテストおよび検証します。各ユーザーを、前の手順で作成した適切なセキュリティプロファイルに関連付けます。 スーパーバイザーのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル JStiles John Stiles SupervisorCreditUSInternal Basic Routing Profile PCandella Pat Candella SupervisorCreditArgentinaInternal Basic Routing Profile LJuan Li Juan SupervisorBankingUSInternal Basic Routing Profile TWhitlock Terry Whitlock SupervisorBankingPhilippinesBPO Basic Routing Profile 手順 4: テストと検証 より細かいアクセスコントロールを確認する手順は以下の通りです。 ブラウザのシークレットモードを利用して、Amazon Connect 管理コンソールに作成した管理者アカウント NWolf でサインインします ナビゲーションメニューの 分析 と 最適化 からリアルタイムメトリクスを選択します キューを選択して、前のステップで設定したすべてのキューのリアルタイムメトリクスを確認できることを確認します リアルタイムメトリクスページに戻ります。 ルーティングプロファイル を選択し、前の手順で設定したルーティングプロファイルがすべて表示されていることを確認します リアルタイムメトリクスページに戻ります。 エージェント を選択し、前のステップで設定したすべてのエージェントのリアルタイムメトリクスを確認できることを確認します 前の段階の手順で設定した 2 つのマネージャーのユーザー名と 2 つのスーパーバイザーのユーザー名を使用して、シークレットウィンドウで各ユーザーで Amazon Connect コンソールにログインします 各ユーザー名で以下を確認します 前述の検証ステップ 2 から 5 に従って、LOB (クレジットまたはバンキング) 内のキュー、エージェント、ルーティングプロファイルのみを確認できることを確認します すべてのエージェントのライブ会話またはライブチャットを リアルタイムで監視 できることを確認します 監視しているライブ会話で、エージェントとの 会話に割り込める ことを確認します クリーンアップ Amazon Connect 管理コンソールにログインし、このブログの手順で作成したセキュリティプロファイルと ユーザーを削除 します このブログのハンズオンの為に Amazon Connect インスタンスをセットアップした場合は、Amazon Connect AWS コンソールにアクセスして Amazon Connect インスタンスを削除 できます 結論 このブログ記事では、Amazon Connect のリソースタグとアクセスコントロールタグを使用して、リアルタイムメトリクス、リアルタイムライブモニタリング、リアルタイムコンタクト割り込みについて Amazon Connect リソースへのより細かいアクセスコントロールを行う方法について説明しました。この方法によって、Amazon Connect インスタンスの稼働中に要件が変化した場合でも、チーム、ロール、その他の基準で複数のグループを作成し、さまざまな Amazon Connect リソースに対してより複雑なアクセスコントロールの条件を設定することができます。 著者について Prashant Desai は AWS プロフェッショナルサービスのシニアコンサルタントです。彼は大規模なコンタクトセンターの設計とクラウドへの移行の経験があります。Prashant は、顧客体験をシンプルで革新的にする方法を常に模索しています。 Parind Poi は AWS プロフェッショナルサービスのシニアプラクティスリーダーです。彼は AWS のカスタマーエクスペリエンス (CX) に関する深い専門知識を持ち、専門業務をリードしています。Parind は、お客様がクラウド上でカスタマーエンゲージメントワークロードを最新化できるよう支援することに情熱を注いでいます。 Elaine は、Amazon Connect に特化した AWS シニアソリューションアーキテクトであり、20 年以上にわたって電話とコンタクトセンターの専門知識を持っています。また、次世代のクラウド基盤のビルダーを育成する Amazon Future Engineer Class Chat プログラムの熱心なサポーターです。 Mike Simpson は、Amazon Connect の技術担当シニアプロダクトマネージャーです。彼は、Amazon Connect のお客様の業務を向上させるための Amazon Connect 分析ソリューションの構築を支援しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

AWS re:Invent 2023 直前セッションガイド – モニタリングとオブザーバビリティ、および運用管理について 11 月 27 日から 12 月 1 日までラスベガスで開催されるクラウドコンピューティングカンファレンス、AWS re: Invent 2023 で皆様にお会いできることをとても楽しみにしています。re: Invent に初めて行かれる方も、そうではない方も、AWS re: Invent の熱量と様々な機会にはきっと驚かされることでしょう。 AWS Cloud Operations トラックは、AWS クラウド運用を構成するソリューション分野 (モニタリングとオブザーバビリティ、運用管理、 コンプライアンスと監査 、 クラウドガバナンス ) を対象とする合計 96 のセッションで構成されています。AWS Cloud Operations トラックでは、豊富な洞察、ベストプラクティス、楽しい Kiosk を通じて、クラウドスキルを新たな高みに引き上げることができます。 このブログでは、組織がダウンタイムを最小限に抑え、信頼性の高い運用を維持し、コストを削減するのに役立つクラウド運用内の2つのソリューション分野である、 モニタリングとオブザーバビリティ と 運用管理 に焦点を当てます。AWS でのモニタリングとオブザーバビリティは、オンプレミス、ハイブリッド、コンテナ化、マルチクラウド、オープンソースを問わず、最新のアプリケーション、ワークロード、インフラストラクチャからの洞察を得るために、ログ、メトリクス、トレースを取り込み、コンテキスト化、視覚化、分析するエンドツーエンドのソリューションを提供します。AWS での一元化された運用管理は、マルチクラウド、ハイブリッド、またはオンプレミス環境にわたる日常業務のための豊富なツールセットを提供します。パッチ管理からインシデント管理まで、運用管理は、お客様が一元化されたハブからアプリケーションを大規模に運用できるようにすると同時に、AIOps やその他の機能によりアプリケーションの可用性を向上させます。 AWS Village の Cloud Ops Kiosk セッションへの参加に加えて、Venetian Expo のAWS Village にあるクラウドオペレーションとオブザーバビリティの Kiosk にもぜひお越しください（ マップ ）。ルーレットを回して賞品を獲得し、AWS の専門家に会い、楽しい VR 体験をして、クラウド運用の未来について学びましょう。 オブザーバビリティと運用管理について詳しく知りたい方は、以下の Kiosk とセッションをご覧ください。 セッションカタログ にある以下のセッションをお気に入りに追加してください。 実施されるセッション ビジネスのニーズや関心に応じて、他にも多くのセッションから選択できます。モニタリングとオブザーバビリティ関連で、ぜひご覧いただきたいセッションは次の通りになります。 Monitoring and Observability COP339 | AWS のオブザーバビリティと運用の最新情報 (What’s new with AWS observability and operations) – ブレイクアウトセッション クラウドで運用しているのか、運用を移行しているのかに関わらず、AWS は複数の環境にわたるアプリケーションとインフラストラクチャの管理と洞察の提供を支援します。このセッションに参加して、クラウド運用の向上と最適化に役立つ最新のイノベーションについて学びましょう。AWS IT 管理ツールとオブザーバビリティソリューションのデモで、最新のローンチを詳しく見てみましょう。 COP343 | 耐障害性を高めるためのオブザーバビリティの構築 (Building observability to increase resiliency) – ブレイクアウトセッション 耐障害性のあるシステムが計画どおりに動作することを証明するには、オブザーバビリティを効果的に使用することが不可欠です。オブザーバビリティを適切に適用することで、顧客に影響を与える前に問題の兆候を早期に発見し、影響を軽減するために迅速に対応できます。このセッションでは、オブザーバビリティのベストプラクティスを利用してAWSでの耐久性(レジリエンス)を改善する方法を学びます。現実世界の障害モードを深く掘り下げ、計測器とオブザーバビリティツールの適切な組み合わせを使用して問題を迅速に解決する方法をご覧ください。このセッションには、Amazon CloudWatch や AWS X-Ray などの AWS サービスを使用したこれらのテクニックとプラクティスのデモが含まれます。 COP319 | コンテナのオブザーバビリティのベストプラクティス (Best practices for container observability) – ブレイクアウトセッション コンテナ化されたアプリケーションや環境のペースの速い世界では、最適なパフォーマンス、信頼性、ユーザーエクスペリエンスを確保するためには、包括的なオブザーバビリティを実現することが不可欠です。このセッションに参加して、コンテナのオブザーバビリティのベストプラクティスを掘り下げてみましょう。AWS オブザーバビリティを利用して、Amazon EKS と Amazon ECS 環境を効果的にモニタリング、分析、トラブルシューティングする方法をご覧ください。コンテナ化されたワークロードに関する洞察を得ながら、エージェントの手動管理を排除し、リソース割り当てを最適化するのに役立つベストプラクティスについて説明します。 COP322 | アプリケーションオブザーバビリティの実装(Implementing application observability) – ブレイクアウトセッション オブザーバビリティは、問題を迅速に診断し、より早く問題を解決するのに役立ちます。このセッションでは、Amazon CloudWatch を使用してアプリケーションのすべてのレイヤーにオブザーバビリティを実装する方法を学びます。これにより、ユーザーからバックエンドシステムに至るまで、アプリケーションのパフォーマンスを理解できます。 COP325 | 効果的なオブザーバビリティ戦略の構築(Building an effective observability strategy) – ブレイクアウトセッション オブザーバビリティの成熟度を高め、顧客に満足してもらうためには、戦略を立てることが重要です。このセッションでは、オブザーバビリティが重要である理由、何をどのように観察すべきか、そしてどのオブザーバビリティ指標がビジネス成果を最もサポートできるかを探ります。Amazon CloudWatch や AWS X-Ray などのサービスを使用して、さまざまなテクニックやプラクティスを深く掘り下げてみましょう。 COP326 | Amazon CloudWatch Logs から実用的な洞察を得る(Get actionable insights from Amazon CloudWatch Logs) – ブレイクアウトセッション Amazon CloudWatch Logs の価値を最大限に引き出していますか?このセッションに参加して、適切なインサイトを得るために最適化を行い、CloudWatch Logs をさらに活用してください。CloudWatch Logs の最新機能を使用してオブザーバビリティ体制を改善する方法をご覧ください。データにコンテキストを追加して、すでに取り込んだログの使い方を学びましょう。機械学習によるパターン検出から、EMF の高解像度機能、リアルタイムのインタラクティブ分析まで、ログから実用的な洞察を得る方法をご覧ください。 COP306 | Amazon CloudWatch と AWS X-Ray を実際に使ってみる (Hands-on experience with Amazon CloudWatch and AWS X-Ray) – ワークショップ 企業のアジリティ、顧客満足度、ビジネスの成長は、優れたオブザーバビリティの設定にかかっています。高性能で信頼性の高いアプリケーションを構築するために、AWS ではさまざまな AWS オブザーバビリティサービスとソリューションを提供しています。このワークショップでは、Amazon CloudWatch と AWS X-Ray を使用して AWS サービスをモニタリングする方法、最も一般的なユースケースを実際に体験する方法、利用可能な最新機能について学び、実装する方法を学びます。参加するにはラップトップを持参する必要があります。 COP309 | Amazon CloudWatch によるエンドユーザーエクスペリエンスのモニタリング (Monitor end user experience with Amazon CloudWatch) – ビルダーズセッション AWS デジタルエクスペリエンスモニタリングは、アプリケーションパフォーマンスモニタリングをエンドユーザーとフロントエンドエクスペリエンスにまで拡張することで、すべてのユーザータッチポイントにおけるアプリケーションパフォーマンスの外部からの視点で顧客体験を向上させます。このようなユーザーエクスペリエンスデータは全体像を完成させ、組織がフロントエンドのパフォーマンス、ユーザー行動、APIをリリース速度、運用率、コンバージョンなどの実用的なKPIに変えるのに役立ちます。このビルダー向けセッションでは、ISP と AWS からのデータを使用し、バックエンドのインフラストラクチャとデバイス、およびユーザーメトリクスから洞察を得て、実際のユーザーと仮想のユーザーの、アクティビティと振る舞いの両方を監視することで、アプリケーションの動作について学びます。参加するにはラップトップを持参する必要があります。 COP401 | コンテナのオブザーバビリティのためのコーディング (Coding for container observability) – コードトーク このセッションに参加して、OpenTelemetry SDK と AWS Distro for OpenTelemetry (ADOT) Collector を使用してさまざまな環境から信号を収集する方法について学びましょう。また、負荷の高いコンテナ環境で堅牢で可用性の高い ADOT パイプラインを設計して、大規模な運用をサポートする方法についても説明します。 一元的な運用管理 COP320 | 運用の一元化 (Centralize your operations) – ブレイクアウトセッション クラウドへの移行またはクラウドでの運用のプロセスのどの段階にあっても、AWS は、AWS、オンプレミス、ハイブリッド環境、エッジでのアプリケーションの管理と運用に使用できる一元化された運用管理ソリューションを提供します。このセッションでは、AWS Systems Manager を使用して、パッチ適用やリソースの変更などのプロアクティブなプロセスを自動化し、何百ものランブックを使用して問題を解決する方法を学びます。自動化を使用すると、サービスの中断を最小限に抑え、時間のかかるプロセスを簡素化し、繰り返しの多いタスクを回避してオペレーション効率を高めることが容易になります。 COP325 | 効果的なオブザーバビリティ戦略の構築(Building an effective observability strategy) – Breakout Session オブザーバビリティの成熟度を高め、顧客に満足してもらうためには、戦略を立てることが重要です。このセッションでは、オブザーバビリティが重要である理由、何をどのように観察すべきか、そしてどのオブザーバビリティ指標がビジネス成果を最もサポートできるかを探ります。Amazon CloudWatch や AWS X-Ray などのサービスを使用して、さまざまなテクニックやプラクティスを深く掘り下げてみましょう。 COP314 | All things patch:AWS、オンプレミス、その他のクラウドでのパッチ適用を管理 (All things patch: Manage patching on AWS, on premises and on other clouds) – チョークトーク このチョークトークでは、AWS Systems Manager を使用して、AWS 組織内の AWS アカウントと AWS リージョン全体で、大規模なパッチ処理を迅速に有効化する方法をご紹介します。他のクラウド環境の Amazon EC2 インスタンス、エッジデバイス、オンプレミスサーバー、仮想マシン (VM) のパッチ処理を管理する方法を学びます。最後に、Amazon Athena と Amazon QuickSight を使用してパッチコンプライアンスレポートをセットアップし、パッチコンプライアンスを作成する方法を見てみましょう。 COP316 | インシデントマネージャーによるインシデント対応の自動化 (Automating incident response with Incident Manager) – チョークトーク このチョークトークでは、インシデントに備える方法と、Amazon CloudWatch アラームまたは Amazon EventBridge イベントによって重大な問題が検出されたときに自動的にアクションを実行する方法を学びます。また、AWS での数十年にわたるインシデント対応と分析の経験に基づいて、インシデント後の分析を実行する方法についても検討してください。 COP330 | AIOpsで業務を加速 (Accelerate your operations with AIOps) – チョークトーク アプリケーションの運用時間を減らし、イノベーションにより多くの時間を費やしたいですか?このチョークトークでは、AIOps（IT運用のための人工知能）がどのようにオペレーションワークフローを簡素化および自動化し、最も重要なときに混乱を解消するのに役立つかを学びます。また、Amazon CloudWatch と Amazon DevOps Guru を使用して AWS での AIOps のベストプラクティスについて学び、それらを使用して時間を節約する方法についても学びます。 COP403 | 効率性の向上:インシデント修復の自動化 (Efficiency unleashed: Automating incident remediation) – コードトーク AWS Well-Architected Framework が推奨する設計原則である、操作をコードとして実行することで、組織は運用をより効率的に実行し、ヒューマンエラーを制限し、予測可能な結果を達成できます。このコードトークでは、操作をコードとして実装する方法を学びます。また、AWS Systems Manager の機能である自動化を使用して、AWS Config および Amazon CloudWatch のアラームとインシデントにあるコンプライアンス違反リソースの修復を自動化する方法についても説明します。 Cloud Ops セッションの種類: re: Invent では、イノベーショントークや EXPO の Kiosk などのさまざまなセッションを通じて、AWS クラウドの運用についてさらに学び、対象分野の専門家 (SME) と交流することができます。 ブレイクアウトセッションは、1 人以上のスピーカーが多数の聴衆にコンテンツを発表することで構成されます。ワークショップは、参加者が少人数のグループで AWS を使用して問題の解決策を構築するインタラクティブなセッションです。チョークトークは双方向に対話する形式で、AWS の専門家による短い講義から始まり、その後に 45 ～ 50 分のホワイトボードと Q&A セッションが続きます。ビルダーズセッションは、1 人の AWS エキスパートが主導する小グループセッションで、参加者がフォローアップして AWS エキスパートと一緒に実験や構築を行う短いデモンストレーションから始まります。Re: Invent 2023 で開催される AWS クラウドオペレーションで、今年の AWS クラウドオペレーションに関するすべての学習機会をぜひ活用してください。 本記事は、Tiffany Chen, Winnie Chen らの「 Know Before You Go – AWS re:Invent 2023 Monitoring and Observability, and Centralized Operations Management | AWS Cloud Operations & Migrations Blog 」を翻訳したものです。翻訳は ソリューションアーキテクトの 伊藤が担当しました。

AWS Amplify JavaScript Library の v6 の一般公開を発表できることを嬉しく思います。このリリースには、コミュニティから要望の多かった改善点や機能が多数含まれています。このリリースでは、バンドルサイズが大幅に縮小され、TypeScript のカバレッジと型サポートが強化され、セキュアランタイムトークンのサポートが強化され、Next.js App Router と Server Actions が完全にサポートされます。 より速いアプリのロード時間とより小さいバンドルサイズ スピードは贅沢品ではなく、必需品です。そのため、依存関係の削減、 Tree shaking 機能の向上、アーキテクチャの最適化に投資してきました。バンドルが小さいほどアプリケーションの読み込みが速くなり、高速ブロードバンド接続でも接続が不安定でも、ユーザーの関心と満足度を維持できます。これらの変更により、Amplify は最も一般的に使用されるフレームワークとビルドツールに最適化されました。 create-react-app を使用して新しい React アプリを構築し、カテゴリ内のすべての API のバンドルサイズを比較すると、v5 と比較してバンドルサイズが次のように減少していることがわかります。 Auth: 55kb to 32kb (42%) Storage: 38kb to 21kb (45%) Analytics (Pinpoint): 31kb to 18kb (42%) Notifications and Analytics: 39kb to 23kb (41%) API REST & GraphQL: 91kb to 38kb (58%) 注意: バンドルサイズ数値は、gzip 圧縮した最終的なバンドルサイズを計測したものです。削減後の結果は Amplify JavaScript v6.0.2 を使用しており、削減前の結果は、軽量クライアントが導入された Amplify JavaScript v5.3.4 を使用しています。これらの改善以前の例として、グラフには Amplify JavaScript v5.2.4 の生成結果も合わせて表記しています。 Amplify JS v6 では、機能単位の API 導入とツリーシェイク機能の改善により、アプリにインポートした API のみがバンドルサイズに影響し、未使用の機能は Tree Shake から除外されます。例えば、アプリで Auth パッケージのいくつかの API のみを使い ( signInWithRedirect , signOut , fetchAuthSession 、 getCurrentUser ) ストレージでは ( uploadData , downloadData )のみを使った場合、v6 ライブラリでは v5 ライブラリと比較して 59% のバンドルサイズを削減します（77kb→31kb）。 TypeScript エクスペリエンスの向上 TypeScript は、大規模で複雑なプロジェクトを管理しやすくする型安全性を提供しており、多くのチームの開発ワークフローに欠かせないものとなっています。Amplify の JavaScript Library における全ての公開 API に、使いやすく直感的な型が追加されました。これらの TypeScript 機能強化により、テキストエディタのシンタックスハイライトとコード補完がより充実したものになります。型チェックは、アプリを実行する前にいくつかのバグを特定するのに役立ちます。 それでは、新しい GenerateClient API を使用して、AWS AppSync API から製品をクエリする方法を見てみましょう。この例では、 GenerateClient API を使用して mutation を実行し、アプリ内の To Do を更新します。graphql API に対して型を設定する必要がなくなったことに気付くかもしれません。データ項目は自動的に推論されるようになっています。 我々は、ログインしているユーザーに対してはもっと良い型定義が必要だというフィードバックをいただきました。そこで、完全な user オブジェクトを返す新しい getCurrentUser API を作成しました。これを使って、 signInDetails の下にある loginId を取得してみましょう。 Next.js の App Router, API routes, そして middleware のサポート Amplify JavaScript Library は、新しい Next.js アダプター により Next.js 機能をすべてサポートするようになりました。これにより、サーバーサイドレンダリングや、App Router で React Server Components を使用したり、middleware で API ルートを使用して認証されたユーザーのみへのアクセスを制御したりすることができます。Amplify JavaScript v6 を使用すると、任意の Next.js ランタイムで Amplify を実行し、任意のレンダリングオプション (SSR、ISR、または静的出力) を使用できます。 Next.js アダプターを使用すると、「Amplify サーバーコンテキスト」内で Amplify Library を実行できます。これにより、クラウドで Amplify Library の各機能を安全に使用できます。Amplify の機能の実行が終了した場合、コンテキストは完全に破棄され、クロスリクエスト汚染を排除することで、アプリのセキュリティ体制を強化します。 Next.js の App Router と Pages Router を使用するシナリオをいくつか見てみましょう。 前提条件 Next.js アダプターを含む最新の Amplify Library をインストールして開始します。 npm i aws-amplify @aws-amplify/adapter-nextjs Amplify getting started guide をまだ読んでいない場合、まずはこのガイドを読んでください。 このチュートリアルの終了までに、GraphQL API と auth API のセットアップをしておく必要があります。 App Router 最初のシナリオでは、Next.js の App Router を利用することを想像しましょう。我々は、サーバーコンポーネント のうち 1 つを AWS AppSync API と接続し、いくつかのデータを一覧します。 まず、 serverClient 関数を含む新しいユーティリティファイルを作成して、サーバー側で Amplify API と通信できるようにします。 // utils/server-utils.ts import { cookies } from "next/headers"; import { generateServerClientUsingCookies } from "@aws-amplify/adapter-nextjs/api"; import config from "../../amplifyconfiguration.json"; export const serverClient = generateServerClientUsingCookies({ config, cookies, }); GenerateServerClientUsingCookie 関数は、動的レンダリング機能を備えた Next.js サーバーコンポーネントで使用できる API を生成します。これにより、サーバー側の Amplify API に安全にアクセスできるようになります。 serverClient 関数はエクスポートされ、API を呼び出すユーティリティ関数として使用できます。 page.tsx ファイルにこの関数をインポートし、それを使用して ToDo アプリ用のデータを一覧表示します。 // page.tsx import { serverClient } from "@/utils/server-utils"; import * as query from "@/graphql/queries"; export default async function Home() { const { data, errors } = await serverClient.graphql({ query: query.listTodos, }); if(errors){ // handle errors } return ( <div> {data.listTodos.items.map((post) => { return ( <li key={post.id}> <div>Name: {post.name}</div> <span>Description: {post.description}</span> </li> ); })} </div> ); ユーザーが投稿を削除できるように、削除機能を追加してみましょう。 // page.tsx import * as mutations from "@/graphql/mutations"; import { serverClient } from "@/utils/server-utils"; ... async function deletePost(formData: FormData) { "use server"; const id = formData.get("postId")?.toString(); if (id) { const { errors } = await serverClient.graphql({ query: mutations.deleteTodo, variables: { input: { id, }, }, }); if (errors) { // handle errors } } } この削除アクションは、 Server Actions を使用して postID を取得し、それを削除します。これにより、サーバー上でフォームを送信し、ID を取得して入力変数に渡すことができます。 TypeScript の正しい推論を行うために、型生成に言及する必要があります。これには、 src フォルダーに生成される api.ts ファイルと、 graphql フォルダーにある mutations ファイルが含まれます。これを行うには、ルートフォルダで amplify add code コマンドを実行します。 Pages Router もし、Next.js の Pages Router を使う場合は、 createServerRunner 関数と generateServerClientUsingReqRes 関数を使い、サーバー上でクエリを実行する必要があります。 まず、2 つの関数を含む utils ファイルを作成することから始めましょう。 runWithAmplifyServerContext 関数は、Amplify API をサーバー上で独立して実行するために使用されます。 serverGraphQLClient middleware, API routes, getServerSideProps もしくは getStaticProps で GraphQL API と通信するために使用されます // utils/server-utils.ts import { createServerRunner } from "@aws-amplify/adapter-nextjs"; import config from "../../amplifyconfiguration.json"; import { generateServerClientUsingReqRes } from "@aws-amplify/adapter-nextjs/api"; export const { runWithAmplifyServerContext } = createServerRunner({ config, }); export const serverGraphQLClient = generateServerClientUsingReqRes({ config, }); それでは、 GetServerSideProps を使ってこれがどのように機能するのかを見てみましょう。サインインしているユーザーの情報を取得するシナリオを想定します。 // index.tsx import { runWithAmplifyServerContext } from "@/utils/server-utils"; import { getCurrentUser } from "@aws-amplify/auth/server"; export const getServerSideProps: GetServerSideProps = async ({ req, res }) => { const currentUser = await runWithAmplifyServerContext({ nextServerContext: { request: req, response: res }, operation: async (contextSpec) => getCurrentUser(contextSpec), }); return { props: { currentUser } }; }; 上記のように、クライアント側で getCurrentUser を使用してサインインしたユーザー情報を取得できます。ただし、インポートパスが "aws-amplify/auth/server" という少し異なるバージョンを使用して、サーバー側でもこれと同じ情報を取得できます。このサーバーバージョンの GetCurrentUser では、 contextSpec を渡す必要があります。 別のシナリオでは、 ServerGraphQLClient 関数を使ってタスクのリストを取得することもできます。 // index.tsx import { listTodos } from "@/graphql/queries"; import { runWithAmplifyServerContext, serverGraphQLClient, } from "@/utils/server-utils"; export const getServerSideProps: GetServerSideProps = async ({ req, res }) => { const todoList = await runWithAmplifyServerContext({ nextServerContext: { request: req, response: res }, operation: (contextSpec) => serverGraphQLClient.graphql(contextSpec, { query: listTodos, }), }); return { props: { todoList } }; }; ServerGraphQLClient は ContextSpec を取り込む graphql API を使用します。ここでは、todo のリストを gql 形式で渡すこともできます。 Middleware Amplify は Next.js の middleware もサポートするようになりました。ミドルウェア内の RunWithAmplifyServerContext を使用して、Amplify API を操作することができます。 ユーザーが認証されていないときはいつでも login ルートにリダイレクトしたいアプリを作ってみましょう。以下は App Router を使った例です。まず、 utils フォルダーに新しい server-utils ファイルを作成します。 // utils/server-utils.ts import { createServerRunner } from "@aws-amplify/adapter-nextjs"; import config from "../../amplifyconfiguration.json"; export const { runWithAmplifyServerContext } = createServerRunner({ config, }); これにより、middleware で使用する RunWithAmplifyServerContext 関数 が作成されます。 // middleware.ts import { runWithAmplifyServerContext } from "@/utils/server-utils"; // The fetchAuthSession is pulled as the server version from aws-amplify/auth/server import { fetchAuthSession } from "aws-amplify/auth/server"; import { NextRequest, NextResponse } from "next/server"; export async function middleware(request: NextRequest) { const response = NextResponse.next(); // The runWithAmplifyServerContext will run the operation below // in an isolated matter. const authenticated = await runWithAmplifyServerContext({ nextServerContext: { request, response }, operation: async (contextSpec) => { try { // The fetch will grab the session cookies const session = await fetchAuthSession(contextSpec, {}); return session.tokens !== undefined; } catch (error) { console.log(error); return false; } }, }); // If user is authenticated then the route request will continue on if (authenticated) { return response; } // If user is not authenticated they are redirected to the /login page return NextResponse.redirect(new URL("/login", request.url)); } // This config will match all routes accept /login, /api, _next/static, /_next/image // favicon.ico export const config = { matcher: [ /* * Match all request paths except for the ones starting with: * - api (API routes) * - _next/static (static files) * - _next/image (image optimization files) * - favicon.ico (favicon file) */ "/((?!api|_next/static|_next/image|favicon.ico|login).*)", ], }; 新しい FetchAuthSession API を使用していることがわかります。これにより、トークンを取得してユーザーがログインしているかどうかを確認できます。ユーザーがサインインしていない場合は、 login ページにリダイレクトされます。 Amplify JavaScript v6 をお試しください Amplify community からのリクエストに応えて、このリリースを提供できることを嬉しく思います。バンドルサイズを最適化することで、Amplify はユーザーの接続環境に関係なく、すべてのユーザーに高速な読み込みを提供することを目指しています。TypeScript サポートの改善により、コーディングエクスペリエンスが向上し、エラーが減少します。Next.js インテグレーションでは、利用可能なすべての Next.js ランタイムを使用できます。 皆さんがこれらの新機能を使って何を構築するのか楽しみです！JS v6 のすべての機能を確認するには、 Amplify JavaScript documentation をご覧ください。 本記事は Building fast Next.js apps using TypeScript and AWS Amplify JavaScript v6 を翻訳したものです。翻訳はソリューションアーキテクトの 髙柴元 が担当致しました。

Amazon Comprehend を使用すると、機械学習の専門家でなくても、テキストからインサイトを引き出すことができます。Comprehend では、組み込みモデルを使用して入力文書の構文を分析し、エンティティ、イベント、キーフレーズ、個人を特定できる情報 (PII)、および特定のエンティティ (ブランドや製品など) に関連付けられた全体的なセンチメントまたは複数のセンチメントを見つけることができます。 11月9日、有害なコンテンツを検出する機能が追加されました。この新機能は、エンドユーザー向けにより安全な環境を構築するのに役立ちます。例えば、毒性検出を使用して、コメントなどの外部からの投稿を受け付けるアプリケーションの安全性を向上させることができます。生成系 AI を使用する際、毒性検出を使用して、入力プロンプトと大規模言語モデル (LLM) からの出力応答を確認できます。 毒性検出は、 AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK で使用できます。AWS CLI と AWS SDK を使った例で、これがどのように機能するかを見て、LLM の使用状況を確認しましょう。 AWS CLI で Amazon Comprehend Amazon Comprehend Toxicity Detection を使用する AWS CLI の新しい detect-toxic-content サブコマンドは、テキストに含まれる毒性を検出します。出力には、ラベルのリスト (入力内のテキストセグメントごとに 1 つ) が含まれます。各テキストセグメントに対して、複数のラベルと 1 つのスコア (0～1) を含むリストが表示されます。 例えば、次の AWS CLI コマンドは 1 つのテキストセグメントを分析し、1 つの Labels セクションと全体的な Toxicity スコア (0～1) が返されます。 aws comprehend detect-toxic-content --language-code en --text-segments Text="'Good morning, it\'s a beautiful day.'" { "ResultList": [ { "Labels": [ { "Name": "PROFANITY", "Score": 0.00039999998989515007 }, { "Name": "HATE_SPEECH", "Score": 0.01510000042617321 }, { "Name": "INSULT", "Score": 0.004699999932199717 }, { "Name": "GRAPHIC", "Score": 9.999999747378752e-05 }, { "Name": "HARASSMENT_OR_ABUSE", "Score": 0.0006000000284984708 }, { "Name": "SEXUAL", "Score": 0.03889999911189079 }, { "Name": "VIOLENCE_OR_THREAT", "Score": 0.016899999231100082 } ], "Toxicity": 0.012299999594688416 } ] } 予想通り、すべてのスコアは 0 に近く、このテキストで毒性は検出されませんでした。 入力をファイルとして渡すには、AWS CLI --generate-cli-skeleton オプションを使用して、 detect-toxic-content コマンドで使用される JSON 構文のスケルトンを生成します。 aws comprehend detect-toxic-content --generate-cli-skeleton { "TextSegments": [ { "Text": "" } ], "LanguageCode": "en" } ここで、出力をファイルに書き込み、3 つのテキストセグメントを追加します (有毒なコンテンツで何が起こるかを示すために使用されるテキストは示しません)。今回は、さまざまなレベルの有害なコンテンツが見つかりました。各 Labels セクションは、対応する入力テキストセグメントに関連付けられています。 aws comprehend detect-toxic-content --cli-input-json file://input.json { "ResultList": [ { "Labels": [ { "Name": "PROFANITY", "Score": 0.03020000085234642 }, { "Name": "HATE_SPEECH", "Score": 0.12549999356269836 }, { "Name": "INSULT", "Score": 0.0738999992609024 }, { "Name": "GRAPHIC", "Score": 0.024399999529123306 }, { "Name": "HARASSMENT_OR_ABUSE", "Score": 0.09510000050067902 }, { "Name": "SEXUAL", "Score": 0.023900000378489494 }, { "Name": "VIOLENCE_OR_THREAT", "Score": 0.15549999475479126 } ], "Toxicity": 0.06650000065565109 }, { "Labels": [ { "Name": "PROFANITY", "Score": 0.03400000184774399 }, { "Name": "HATE_SPEECH", "Score": 0.2676999866962433 }, { "Name": "INSULT", "Score": 0.1981000006198883 }, { "Name": "GRAPHIC", "Score": 0.03139999881386757 }, { "Name": "HARASSMENT_OR_ABUSE", "Score": 0.1777999997138977 }, { "Name": "SEXUAL", "Score": 0.013000000268220901 }, { "Name": "VIOLENCE_OR_THREAT", "Score": 0.8395000100135803 } ], "Toxicity": 0.41280001401901245 }, { "Labels": [ { "Name": "PROFANITY", "Score": 0.9997000098228455 }, { "Name": "HATE_SPEECH", "Score": 0.39469999074935913 }, { "Name": "INSULT", "Score": 0.9265999794006348 }, { "Name": "GRAPHIC", "Score": 0.04650000110268593 }, { "Name": "HARASSMENT_OR_ABUSE", "Score": 0.4203999936580658 }, { "Name": "SEXUAL", "Score": 0.3353999853134155 }, { "Name": "VIOLENCE_OR_THREAT", "Score": 0.12409999966621399 } ], "Toxicity": 0.8180999755859375 } ] } AWS SDK での Amazon Comprehend Toxicity Detection の使用 AWS CLI の場合と同様に、AWS SDK を使用してアプリケーション内の毒性をプログラムで検出できます。次の Python スクリプトは、 AWS SDK for Python (Boto3) を使用してテキストセグメント内の毒性を検出し、スコアが指定しきい値を超える場合はラベルを出力します。コードでは、2 番目と 3 番目のテキストセグメントの内容を編集して *** で置き換えています。 import boto3 comprehend = boto3.client('comprehend') THRESHOLD = 0.2 response = comprehend.detect_toxic_content( TextSegments=[ { "Text": "You can go through the door go, he's waiting for you on the right." }, { "Text": "***" }, { "Text": "***" } ], LanguageCode='en' ) result_list = response['ResultList'] for i, result in enumerate(result_list): labels = result['Labels'] detected = [ l for l in labels if l['Score'] > THRESHOLD ] if len(detected) > 0: print("Text segment {}".format(i + 1)) for d in detected: print("{} score {:.2f}".format(d['Name'], d['Score'])) Python スクリプトを実行します。出力には、2 番目と 3 番目のテキストセグメントで検出されたラベルとスコアが含まれます。最初のテキストセグメントでは毒性は検出されません。 Text segment 2 HATE_SPEECH score 0.27 VIOLENCE_OR_THREAT score 0.84 Text segment 3 PROFANITY score 1.00 HATE_SPEECH score 0.39 INSULT score 0.93 HARASSMENT_OR_ABUSE score 0.42 SEXUAL score 0.34 LLM での Amazon Comprehend Toxicity Detection の使用 このブログ記事 で説明されているように、 Amazon SageMaker JumpStart を使用して Mistral 7B をデプロイしました。 モデルの応答に毒性が含まれるのを避けるため、次の 3 つの関数を含む Python スクリプトを構築しました。 query_endpoint は、SageMaker JumpStart によってデプロイされたエンドポイントを使用して Mistral 7B モデルを呼び出します。 check_toxicity は Comprehend を使用してテキスト内の毒性を検出し、検出されたラベルのリストを返します。 avoid_toxicity は、検出されたラベルのリストを入力として受け取り、毒性を避けるために行うべきことを説明するメッセージを返します。 LLM へのクエリは、入力プロンプトで毒性が検出されかった場合にのみ実行されます。LLM からの応答は、出力に毒性が検出されなかった場合にのみ出力されます。毒性が検出された場合、スクリプトは入力プロンプトの修正方法に関する提案を提供します。 Python スクリプトのコードを以下に示します。 import json import boto3 comprehend = boto3.client('comprehend') sagemaker_runtime = boto3.client("runtime.sagemaker") ENDPOINT_NAME = "<REPLACE_WITH_YOUR_SAGEMAKER_JUMPSTART_ENDPOINT>" THRESHOLD = 0.2 def query_endpoint(prompt): payload = { "inputs": prompt, "parameters": { "max_new_tokens": 68, "no_repeat_ngram_size": 3, }, } response = sagemaker_runtime.invoke_endpoint( EndpointName=ENDPOINT_NAME, ContentType="application/json", Body=json.dumps(payload).encode("utf-8") ) model_predictions = json.loads(response["Body"].read()) generated_text = model_predictions[0]["generated_text"] return generated_text def check_toxicity(text): response = comprehend.detect_toxic_content( TextSegments=[ { "Text": text } ], LanguageCode='en' ) labels = response['ResultList'][0]['Labels'] detected = [ l['Name'] for l in labels if l['Score'] > THRESHOLD ] return detected def avoid_toxicity(detected): formatted = [ d.lower().replace("_", " ") for d in detected ] message = ( "次の有害なコンテンツを避けてください:" + ", ".join(formatted) + ".\n" ) return message prompt = "ウェブサイトは 10 のシンプルなステップで構築できます。" detected_labels = check_toxicity(prompt) if len(detected_labels) > 0: # 入力プロンプトで毒性が検出された場合 print("プロンプトを修正してください。") print(avoid_toxicity(detected_labels)) else: response = query_endpoint(prompt) detected_labels = check_toxicity(response) if len(detected_labels) > 0: # 出力で毒性が検出された場合 print("改善されたプロンプト:") prompt = avoid_toxicity(detected_labels) + prompt print(prompt) else: print(response) スクリプトのサンプルプロンプトでは毒性を含む応答は得られませんが、応答に毒性が含まれる場合にチェックして修正する自動プロセスを設定できることを知っておくと安心です。 利用可能なリージョンと料金 Amazon Comprehend Toxicity Detection は、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (シドニー) の AWS リージョン で使用できます。 毒性検出を使用する場合、長期間のコミットメントはありません。支払いは、入力文字数の 100 文字単位 (1 単位 = 100 文字) で行い、リクエストあたりの最低料金は 3 単位 (300 文字) です。詳細については、 Amazon Comprehend の料金表を参照してください。 毒性検出を活用してオンラインコミュニティの安全性を向上させ、アプリケーションへの LLM の採用を簡素化してください。 – Danilo 原文は こちら です。

こんにちは、カスタマーソリューションマネージャー (CSM) の服部です。 前編 の記事でEBA (Experience-Based Acceleration) がどんなものか全体イメージをつかんでいただけたと思いますので、後編ではEBAの最後の3日間でおこなうビルド＆デプロイについて詳しくお話させていただきます。ここまでの5週間で準備してきたものをこの3日間で形にする際に、どういったタイムスケジュールでどのようにビルド＆デプロイを行っていくのかについて理解していただければと思います。 ５週間にわたりファシリテーションを担当するチームと開発作業を担当するチームに分かれて準備を進めてきた最後の6週目にデモを作成する３日間が設定されています。この３日間は参加者が一同に会して作業に集中する期間になりますので、普段の業務から離れてビルド＆デプロイに集中していただくことになります。詳細なタイムテーブルは以下に記載しています。朝会と作業、昼会と作業のセットを５回繰り返すタイムテーブルで進めていきます。通常のスプリントは２週間ですが、EBAではそれを３日間に凝縮して実施する形になります。このスプリントの中で最小限のプロダクトを完成させて、最後にエクゼクティブに対してデモを実施してフィードバックをもらいます。   このスプリント経験を通して実際のモダナイゼーション開発の流れを経験していただくことになります。 次に参加者の体制ですが、これまでの準備期間と同じように大きく分けてファシリテートを行うコマンドセンターと実際に開発を行う開発チームの２つのチーム体制で３日間のタイムスケジュールを進めていただきます。チーム分けに際してどういった方をアサインすべきかについて以下にひとつのサンプルを記載しています。コマンドセンターは、メンバー間の調整役を担っていただきメンバー間の連携を強化していただきますので、プロジェクト管理の経験者、進捗管理、問題解決の経験が豊富な方で開発チームからエスカレーションされた事項に対して、判断を下せる権限のある方がアサインされると良いです。また、アジャイル開発は未経験の場合でもウォーターフォールのプロジェクトマネジメント経験が豊富でこの機会にチャレンジしたいマインドがある方がアサインされても問題ありません。作業チームに関しては、作業をしていただく方がアサインされますので、AWSの基本スキルが必要で対象のインフラ、アプリが理解できてることが必須になります。 EBAのAWS支援領域ですが、このプログラムはあくまで伴走支援のため主体はお客様になります。AWSはアドバイスやレビューをしますが何か作るということはしません。トレーニングや座学ではありませんので、前述のように参加メンバーには必要なスキルが定義されています。 モダナイゼーションEBA実施に適しているお客様には２つのパターンがあります。１つ目はAWSをすでに利用しているもののEC2がメインでマネージドサービスやサーバーレスなどクラウドネイティブなサービスを使ってまだアプリケーションを構築したことがない状況のお客様です。２つ目は対象がまだオンプレにあってクラウド移行時に合わせてモダナイズしたいと考えているが、経験がないのでAWSに伴走支援してほしいというお客様になります。この２つの状況に当てはまるお客様はEBAの効果が大きいので是非AWSへお問い合わせいただきEBAの実施をしていただきたいと思っております。 最後にEBAを実際に実施された 弥生株式会社様の事例を紹介させていただきます。 ご紹介するお客様は市場の変化に柔軟に対応できる製品開発サイクル実現のために組織を変革 (アジャイル開発対応) し、顧客の声をもとに改善できる製品設計 (マイクロサービス) をする必要性を感じておられましたが、いわゆるウォーターフォール型の開発に慣れていることで変化の激しいサービスを開発できる体制ができていない状態でした。お客様はAWS 利用経験のある技術者が多くいる状態で自力で変革できる可能性もありましたが、AWSがパイロット開発を約6週間短期集中支援する本EBAの実施を決定されて以下の開発スコープを３つ設定されました。 ・参加者全員が各自の役割を果たし実体験を得ること ・開発プロセスを確立させ動くものをデプロイできること ・スクラムによる開発スプリントを自分たちで回せるようになること また本番を想定した開発プロセスをまわして改善ポイントを見つけることをビルド＆デプロイ期間の目標としてEBAを実施いただいた結果、EBAを通して4回のスプリントを経験され、その中でアジャイル開発のプロセスを体験するのみならずマイクロサービスアーキテクチャなどの開発生産性を高める仕組みも導入してプロセスの改善も実施されました。3日間のビルド＆デプロイ期間でCI/CD Pipelineの構築も行ったことでEBA実施後にも活用できる経験もされました。 これらの経験を当初の課題を解決する足掛かりとしていただくことで、EBA実施の効果を最大化していただけるものと考えております。 こちらのお客様の事例は、“ 技術的負債との戦い、マイクロサービスとアジャイル開発への挑戦 ”に詳しく記載されておりますので是非ご覧ください。 まとめ 前後編に渡って「EBAとは何か」についてご説明させていただきました。EBAの概要、実施目的をご理解いただけましたでしょうか。経験不足などでモダナイゼーションの一歩を踏み出すのが難しい状況におられるお客様は、EBA実施を通して伴走支援させていただきますのでAWSへお問い合わせください。 著者 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM) 服部 昌克、宮本 雅勝 参考リンク モダナイゼーションを実践するEBA (前編) 技術的負債との戦い、マイクロサービスとアジャイル開発への挑戦 弥生×AWS×モダナイゼーション

こんにちは、カスタマーソリューションマネージャー (CSM) の宮本です。この記事では、モダナイゼーションを検討しているお客様向けに、AWSがご提供するEBA (Experience-Based Acceleration) というプログラムをご紹介します。 以前、 こちらの記事 で、モダナイゼーションとは何か、およびEBAの概要について言及しました。EBAに興味を持たれた方の中には「まだまだ具体的に何をするのかイメージがつかない」という方もいらっしゃると思います。 本記事では、前後編に渡り、より具体的にEBAの内容をご説明し、イメージをつかんでいただきたいと思います。 前編では、EBAの概要、スケジュールや期待される効果、目標設定についてご紹介します。 EBAの概要 EBAは、お客様のモダナイゼーションを加速させるModernization Accelerator (ModAx) というプログラムの一部です。ModAxでは、システムの評価とアーキテクチャ策定を行い、モダナイゼーション対象となるアプリケーションを見極め、実際にビルド＆デプロイを経験していただきます。このビルド＆デプロイを経験いただくプログラムが、EBAです。 なお、システムの評価とアーキテクチャ策定は、MODAというプログラムにて実施します。 MODAとEBAは共に、AWS ITトランスフォーメーションパッケージ for Cloud Nativeとしてご提供しております。詳細は こちらの記事 を参照ください。 また、EBAはモダナイゼーションに限らず、基盤構築やマイグレーションをテーマに実施する場合もありますが、本記事中で言及する”EBA”は、”モダナイゼーションをテーマとしたEBA”の事を指します。 EBAとは、お客様自身によるパイロット開発を伴走型で支援するプログラムです。 本格的なモダナイゼーションの実現に向け、お客様が行うパイロット開発を、約6週間で設定し、“2 pizza team”や“2-way door”という要素も取り入れながら、AWSが短期集中的に支援し、最小プロダクトを開発いただく経験を通して、今後のお客様の開発に役立てていただきます。 “2 pizza team”や、“2-way door”というのは、Amazonで用いられている考え方です。これらの用語は、関連記事である“ アプリケーションのモダナイゼーションを加速するEBA ”で触れていますので参照ください。 スケジュールや期待される効果 EBAは、5週間の準備期間と、6週目の3日間で実施するビルド＆デプロイで構成されています。準備期間では、EBAの目標、成功条件を定義、具体的なタスクを決定し、要件定義・設計・実装を進めていきます。最後の3日間では、参加者が一同に会し、集中的にビルド＆デプロイの作業を実施し、最小限のプロダクトを完成させ、アプリケーションのモダナイゼーションを実践していただきます。 自ら手を動かしてモダナイゼーションを実践し、ノウハウと成功体験を獲得すると同時に、何が不足しているかを把握し、課題を整理することで、今後、お客様が本格的に取り組んでいくモダナイゼーション計画の策定に役立てていただくことを期待しています。 EBAに参加いただく方は、ある程度AWSのサービスに精通している必要があります。 そのため、EBAを実施するうえで必要な知識、スキルが不足している場合、事前にAWSが提供するトレーニングを受講いただく事を推奨します。また、AWSチームによる勉強会を開催する事も可能です。EBAの準備期間に入る前に、必要最低限の知識、スキルを習得いただきます。 では、スキルも習得したところで、5週間の準備期間で何を実施するかを紹介します。 EBAではお客様とAWSとで複数のチームを構成します。 大きくは、ファシリテーションを担当するチームと、実作業を担当するチームに分かれます。ファシリテーション担当は1チームのみですが、作業担当チームは規模に応じて確定させます。ファシリテーション担当チーム、作業チームに対して、AWSチームがそれぞれサポートをさせていただきながら、EBAを進めていきます。 目標設定 最初に、EBAの目標を明確にします。EBAの期間は6週間と限られています。そのため、EBAを何のために実施するのか、何を達成すれば成功とするのか、という具体的な目標を設定し、それを達成するために準備期間で必要なタスクを進めていきます。 目標設定は、非常に重要なポイントであり、同時にお客様が悩まれるポイントです。 EBAに参加する全員が、何を達成すべきなのかを明確に理解できる目標を設定することが重要です。目標があいまいな場合、EBA参加者によって、何を達成するかの基準がずれる可能性があります。EBAでは、2つの観点で目標を設定します。1つは、EBAを実施すること自体の目標で、成功基準とも表現します。もう1つは、各作業チーム毎の目標です。 まず、重要なのはEBAを実施すること自体の目標 (成功基準) を設定することです。 EBA自体の目標設定のために、なぜEBAを実施することに決めたのか、EBA実施後にどうなりたいか、を改めて考えてみてください。アジャイル開発 (スクラム) を取り入れて開発/リリースのスピードを上げたいのか、AWSの構築スキルやサービス知識を習得して自社で開発する力を身に付けたいのか、異なる部門間の協業により組織の壁を取り除きたいのか、実施する理由や、目指すべき姿はさまざまだと思います。目指すべき姿に合わせた目標 (成功基準) を設定し、EBAにてそれを達成することで、ぜひ次のステップへと繋げていただきたいです。 その後、各作業チームの目標を設定します。 各作業チームが、具体的にEBA期間中に何をするのかを定義しましょう。例えば、「対象システムのプロトタイプを作成する」や、「スキルを向上させる」という目標を設定する場合、プロトタイプは、具体的にどの機能まで実装するかであったり、どのような基準でスキルが向上したことを示すか、という事を明確にし共通認識とすることが重要です。 また、現実的な目標に加えて、ストレッチ目標を設定することを推奨します。 「ストレッチ目標」とは、もう少し頑張れば、実現できる程度の難易度に設定された目標のことです。 皆さま、EBAの準備期間開始時のスキルや知識を前提に目標を立てられますが、実際に準備期間を進めていくと、スキルや知識を習得していき、準備期間中に最初に設定した目標を達成することも起こり得ます。最初の時点で、少し高めの目標を設定し、さらに「ストレッチ目標」を設定しましょう。 まとめ 前編ではEBAの概要、スケジュールや期待される効果、目標設定について説明しました。 後編では、最後の6週目の3日間で何を実施するのか、実施体制やEBAにてAWSが支援する事などについて紹介します。 参考リンク アプリケーションのモダナイゼーションを加速するEBA AWS ITトランスフォーメーションパッケージ 2023 ファミリー（ITX 2023） 著者 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM) 宮本 雅勝、服部 昌克

AWS re:Invent 2023 は、11 月 27 日から 12 月 1 日まで、ネバダ州ラスベガスで開催されます。これは、AWS が主催する 1 年で最も包括的なイベントであり、AWS について学び、スキルを磨くための最も早い方法です。 この記事では、関心のあるトピックを簡単に見つけられるように、モノのインターネット (IoT) セッションの専用トラックをキュレーションし、整理しました。IoT トラックには、自動車、産業、スマートホーム、ロケーションなどの重点分野があります。Innovation Talk と Breakout Session は、AWS のオピニオンリーダーによる講義形式で、多くの場合顧客スピーカーが出演し、他の企業の同僚から直接話を聞くことができます。Chalk Talk、Workshop、Builders’ Session は、よりインタラクティブで技術的で実践的な内容で、AWS の技術専門家が主導します。 また、 Expo 内の AWS Village、開発者ラウンジ、Industries Pavilion を訪れて、AWS IoT の専門家と会話を始めたり、IoT サービスを紹介するデモを見たりすることもできます。 Innovation Talk クラウドテクノロジーがビジネスの推進にどのように役立つかを深く掘り下げる AWS リーダーとのセッションは必見です。 AUT207-INT | クラウドにおける製造とモビリティの革新 HYB207-INT | Innovation Talk: 新興技術 IoT セッション: クロスインダストリー どの業界で働いていても、これらのセッションに参加すると、中核となる IoT サービス、発表、ユースケースについて学ぶことができます。 Breakout Session IOT211 | AWS IoT でビジネスを革新し、顧客体験を高める Chalk Talk IOT101 | Amazon Kinesis Video Streams でエッジにある多数の IP カメラを管理する IOT209 | IoT 接続: パフォーマンス、コスト、統合のバランス IOT301-R | すべての IoT ソリューションの安全な基盤を構築する方法 [再演あり] IOT307 | IoT ソリューションの負荷テストを効果的に行うための戦略 Workshop IOT205 | 生成系 AI と AWS IoT を使用して、絵を描く 2D ロボットを構築する IOT311 | IoT データの取り込みと視覚化のためのアーキテクチャパターンを構築 Builders’ Session IOT304-R | AWS IoT と AI/ML による自動動画モニタリングシステムを構築 [再演あり] IoT セッション: 自動車 これらのセッションに参加して、AWS IoT が安全な車両接続の確立と車両データの効果的な管理にどのように役立つかを学びましょう。 Breakout Session IOT204 | AWS IoT によるコネクテッドカープラットフォームの革新と最新化 Chalk Talk IOT210 | AWS IoT によるコネクテッドカーからのビッグデータワークロードの管理 IOT309-R | MQTT 5 で AWS IoT Core を使用したアプリケーションの革新 [再演あり] Workshop IOT305 | AWS IoT を使用して車両全体の EV バッテリーの異常を検出しよう IoT セッション: インダストリアル これらのセッションに参加して、エッジからクラウドまで優れた運用を実現する最新の産業用データアーキテクチャの設計に AWS IoT がどのように役立つかをご覧ください。 Breakout Session IOT206 | AWS での IoT による産業変革の加速 Chalk Talk IOT212 | AWS IoT SiteWise によるデータヒストリアンのモダナイゼーション IOT310-R | AWS でデジタルツインを 60 分で構築する方法をわかりやすく解説 [再演あり] Workshop IOT203-R | スマート製造のための自動異常検出 [再演あり] IoT セッション: スマートホーム これらのセッションに参加して、AWS IoT が Matter、Amazon Sidewalk、AI などの新しいテクノロジーや仕様を取り入れ、費用対効果が高く、将来を見据えたスマートホームソリューションを構築するのにどのように役立つかを学んでください。 Breakout Session IOT207 | AWS IoT を活用した次世代のスマートホームソリューション IOT213 | AWS IoT によるコネクテッドプロダクトとソリューションのスケーリング Chalk Talk IOT306-R | 生成系 AI を使用した AWS IoT GreenGrass コンポーネントの設計 [再演あり] Workshop IOT202 | 規格に準拠した安全なコネクテッド製品を AWS IoT で構築する IOT302-R | 新しいスマートホームユニバース: Matter規格でIoT製品を設計する [再演あり] IoT セッション: ロケーション これらのセッションに参加して、AWS IoT と Amazon Location Service を一緒に使用して、アセットトラッキング、モバイルエクスペリエンス、ルート最適化などの分野で機能を強化する方法を学びましょう。 Breakout Session IOT208 | 位置情報サービスによる顧客体験の最適化 Chalk Talk IOT308 | AWS IoT と Amazon Location Service でロジスティクストラッキングを最適化する Workshop IOT303 | ロケーションベースのサービスと Amazon Sidewalk を使用したアセットトラッキング Expo Expo では、楽しんだり、AWS の専門家と話したり、テクノロジーのデモを直接見たりすることができます。Expo エリアは広大で、誰もが楽しめるものが揃っています。時間をかけてできるだけ多くのことを見てください。ただし、IoT に注目したい場合は、次の推奨事項を確認してください。 AWS Village — 新技術キオスク 新しいテクノロジーキオスクを訪れて、IoT、ロボティクス、量子に関するデモをご覧ください。IoT デモは、AWS DeepRacer ハードウェアのカスタマイズされたバリエーションで、さまざまな接続テクノロジー (Cellular LTE/NB-IoT、Wi-Fi、LoRaWAN) を紹介し、Alexa、Amazon Sidewalk、Amazon Location Service との相互統合を紹介します。AWS DeepRacer IoT デモでは、さまざまな業界のエッジにおける AWS IoT の変革の可能性を探ります。組織が AWS IoT Greengrass を使用して、コネクテッドカー、スマートシティ、農業などのシナリオでエッジコンピューティングの力を引き出す方法を示しています。AWS IoT at the Edge が、インテリジェントでスケーラブルな機能をネットワークのエッジにもたらすことで、組織が物理世界とデジタル世界のギャップを埋めるのにどのように役立つかをご覧ください。 開発者ラウンジ — Open Source Auto: Vegas Edition 魅力的でインタラクティブな自動車運転のデモを体験してください。このデモでは、車両の状態の監視から車内体験の向上まで、ほぼすべてのユースケースで AWS がどのように車両データの価値を引き出すことができるかを紹介しています。リアルなタッチスクリーンダッシュボード、ステアリングホイール、ペダル、バケットシートを備えた自動車用コックピットの運転席に足を踏み入れます。シミュレーターを使用して、街灯、曲がり角、障害物、ライブトラフィックを備えた仮想都市景観の道路をナビゲートします。ステアリング、ブレーキ、加速中に、車両の CAN 信号やさまざまなセンサーデータをほぼリアルタイムで監視しながら、実行中のアプリケーションプロセスを把握できます。AWS IoT FleetWise、AWS IoT Core、AWS IoT Greengrass など、最新の AWS IoT サービスと機能がすべて実際に動作しているのがわかります。この魅力的なデモは、単なるシミュレーションではありません。コネクテッドカー技術の未来と、自動車の監視と分析の可能性を垣間見ることができます。 Industries Pavilion — 自動車 コネクテッドモビリティ — Connected Mobility Solution on AWS は、コネクテッドカーインフラストラクチャを開発、デプロイ、管理する際のわずらわしさ、時間、コストを削減するように設計された環境をお客様やパートナーに提供するプラットフォームエンジニアリングサービスです。AWS IoT Core などの AWS サービスや、専用の自動車サービスである AWS IoT FleetWise を使用して革新的なソリューションを構築する方法をご覧ください。 OCPP 準拠の大規模な EV 充電 — 化石燃料から電気自動車への移行は、正味ゼロ排出量を達成するための政府および商業公約の重要な要素です。チャージポイントオペレーター (CPO) は、定期的なリモートおよびオンサイトメンテナンス、ヘルスメトリックの収集、運用構成の管理を担当します。AWS IoT Core、Amazon Elastic Container Service、AWS Lambda などのサービスを使用して、EV 業界標準である OCPP に基づいて、スケーラブルで低レイテンシーの CPO ソリューションを構築する方法をご覧ください。お客様は、AWS のマネージドサービスによって、大規模な EV 料金の運用に関連する手間のかかる作業がどのように軽減されるかを学ぶことができます。 Industries Pavilion — 製造 スマート製造 | スマート製造による運用上の洞察の促進 — Amazon スマート製造のデモでは、目視検査、材料トレーサビリティ、状態ベースモニタリング、クラウド主導の自動化を実証する産業サービス (産業用 IoT と機械学習) とソリューション (産業データファブリック) 向けの AWS を紹介します。デモには、リニアトラック、ピックアンドプレースロボット、目視検査カメラが含まれています。これらは、AWS の産業用オートメーション機器を使用して、AWS Snowcone 上で稼働する産業用エッジを介して統合されます。 機械学習 | 機械学習による産業オペレーションの最適化 — このデモでは、お客様が異常な状態 (異常振動) を起こし、Amazon Monitron ワイヤレスセンサーが振動データを Monitron Gateway と AWS に送信するのを見ることができるモーターを取り上げます。Amazon Monitron アプリケーションを通じて、異常なモーター状態に関するアラートが届くのを確認でき、アクションを起こすのがいかに簡単かを知ることができます。さらに、品質検査とコンピュータービジョン (CV) がどのように品質検査を自動化できるかを紹介します。 生成系 AI | 製造業向けの生成系 AI アプリケーションの構築 — 産業企業は、革新的な新製品設計の開発、かつてないレベルの製造生産性の向上、サプライチェーンアプリケーションの最適化など、生成系 AI を活用してビジネスを変革する方法を模索しています。アマゾン ウェブ サービスにより、メーカーが基盤モデルを使用して生成的な AI ベースのアプリケーションを簡単に構築およびスケーリングできるようになった様子を示すデモをご覧ください。 まとめ re:Invent 2023 に皆様をお迎えし、最新のニュースやイノベーションを共有できるのを楽しみにしています。 re:Invent のウェブサイト で詳細を確認し、 フルセッションカタログ をご覧ください。近いうちにお会いしましょう！ この記事は Olivia Bias によって書かれた Get connected with AWS IoT at re:Invent 2023 の日本語訳です。この記事はソリューションアーキテクトの岡本晋太朗が翻訳しました。

この記事は Announcing remote cache support in Amazon ECR for BuildKit clients (記事公開日 : 2023 年 10 月 24 日) の翻訳です。 この機能は、 バージョン 25.0 のリリース 時に Docker によってプリインストールされ、サポートされる予定です。この機能は、Buildkit バージョン 0.12 以降ですでにリリースされており、現在は Finch バージョン 0.8 以降で利用可能です。 導入 Amazon Elastic Container Registry (Amazon ECR) は、お客様がコンテナイメージとアーティファクトを保存、共有、デプロイするために使用する、完全マネージドなコンテナレジストリです。Amazon ECR は、AWS 環境と非 AWS 環境の両方で、お客様のビルドとデプロイのパイプラインの一部として、数十万人のお客様によって使用されています。 お客様が Amazon ECR や他のレジストリで最も頻繁に作業するのは、コンテナイメージのパッケージ化とレジストリへの保存を担当するコンテナクライアントです。これらの多くのクライアントは、 BuildKit として知られる一般的なオープンソースのイメージビルドツールキットを使用しています。これには、 Docker (23.0 以降)、 Finch 、 Earthly などのクライアントが含まれます。ビルド時に、クライアントはコンテナイメージの各レイヤーを、イメージが完成するまで 1 つずつビルドします。 一部のレイヤーはビルド間であまり変更されないため、クライアントはビルドしたすべてのレイヤーのローカルコピーを保存し、その後のビルドでこのローカルキャッシュを再利用します。これは、毎回レイヤーを再ビルドするよりもはるかに高速です。 ただし、これはビルドランナーまたはワーカーが各ビルド実行ごとに同じコンピュート環境で実行される場合にのみ機能します。 GitHub Actions や GitLab CI Enterprise などの一般的な CI/CD プラットフォームは、ビルドごとに一時的なコンピュートを使用するため、ローカルキャッシュを構築および使用することができません。 ソリューションの概要 一時的なコンピュートツールでもキャッシュを使用できるようにするために、 BuildKit は 2020 年にリモートキャッシュをエクスポートする機能を導入しました。 これらのリモートキャッシュは、ローカルのレイヤーキャッシュと同様に機能します (つまり、レイヤーは格納され、スクラッチから再構築する代わりに使用されます) 。 唯一の違いは、ビルドされた各レイヤーがリモートレジストリに送信され、後続のビルドでローカルキャッシュにない場合に取得されることです。 AWS のお客様は、この機能を使用してイメージのビルドを速めることを望んでおり、 Amazon ECR でのサポートを求めていました。 ただし、これらのキャッシュを格納するために使用されるフォーマットは、 Open Containers Initiative (OCI) 形式ではありませんでした。 Amazon ECR は OCI 準拠のレジストリであるため、このリモートキャッシュフォーマットを Amazon ECR にプッシュすると、検証に失敗します。 BuildKit は最近バージョン 0.12 をリリースしました。このバージョンには、リモートビルドキャッシュを OCI 互換の方法で生成および保存できるソリューションを提供しています。これには Amazon ECR エンジニアからの貢献 が含まれています。これは、 BuildKit が Amazon ECR のように OCI 仕様を実装するレジストリでビルドキャッシュを保存および取得できることを意味します。このアップデートにより、ビルドおよびプッシュされたイメージとは別に、キャッシュイメージを Amazon ECR リポジトリにプッシュできるようになります。このキャッシュイメージは、後のビルドで参照でき、ノート PC からのプッシュか、 GitLab や GitHub Actions などのプラットフォーム上の本番 CI/CD ビルドからのプッシュかに関わらず、プッシュ時間を大幅に短縮することができます。 ウォークスルー Amazon ECRでのリモートキャッシュの使い方 これらの例では、 Docker を使用します。バージョン 25.0.0 以降を実行していることを確認してください。これには、 Amazon ECR やその他の OCI 互換レジストリで機能するために必要な変更が含まれている BuildKit 0.12 が含まれています。これらの例は、ローカルの開発環境で実行するか、 CI/CD プラットフォームのビルドスクリプトで使用できます。 例えば次のようにして、 CI/CD には Docker を使用してイメージをローカルでビルドし、その後ビルドしたイメージを Amazon ECR にプッシュするビルドステップをおこないます。 docker build -t <account-id>.dkr.ecr.<aws-region>.amazonaws.com/buildkit-test:image . docker push <account-id>.dkr.ecr.<aws-region>.amazonaws.com/buildkit-test:image Apache Configuration Amazon ECR にキャッシュを入力し、その後のビルドで使用するようにするには、ビルドコマンドに –cache-to および –cache-from オプションを追加します。 docker build -t <account-id>.dkr.ecr.<my-region>.amazonaws.com/buildkit-test:image \ --cache-to mode=max,image-manifest=true,oci-mediatypes=true,type=registry,ref=<account-id>.dkr.ecr.<my-region>.amazonaws.com/buildkit-test:cache \ --cache-from type=registry,ref=<account-id>.dkr.ecr.<my-region>.amazonaws.com/buildkit-test:cache . docker push <account-id>.dkr.ecr.<my-region>.amazonaws.com/buildkit-test:image Apache Configuration 一見多くの設定があるように見えますが、追加したことを順を追って見ていきましょう。 cache-to と cache-from という 2 つの新しいオプションセットがあります。 cache-to オプションは、 ref という引数のコンテキストキーで指定されたイメージ URI に基づいて、エクスポート先(または作成先)のリモートキャッシュを指定します。ここでのイメージ URI は、実際にビルドされているタグ付きイメージとは異なることに注意してください。必要に応じて、キャッシュの URI を Amazon ECR の別のリポジトリを指すように設定できますが、これは必須ではありません。 type という引数のコンテキストキーで指定された値 registry は、レジストリにプッシュするリモートキャッシュを作成していることを意味します。 Buildkit 0.12 で導入された新しいコンテキストキーは image-manifest です。このキーの値を true に設定すると、レジストリに OCI 互換バージョンのリモートキャッシュを保存できるようになりました。また、 image-manifest を使用するには oci-mediatypes を true に設定する必要があるため、それも設定しています。リモートキャッシュは ref のイメージ URI で暗黙的にプッシュされるため、ビルドステップに別の push コマンドを追加する必要はありません。 cache-from オプションは、Dockerfile で特定のビルドステップを実行する代わりに BuildKit が取得できるキャッシュの場所を指定します (ただし、そのレイヤーとそれ以前のレイヤーについて 何も変更されていない場合 )。この場合、cache-to で指定したキャッシュマニフェスト URI を持つ Amazon ECR リポジトリから取得されます。 要約すると、 cache-to はリモートキャッシュマニフェストをエクスポートし将来のビルドを高速化するための準備をするものであり、 cache-from はエクスポートされたリモートキャッシュマニフェストを利用して、現在のビルドを高速化します。キャッシュが最初に存在しない場合、 cache-from は諦めてキャッシュを使用しないため、新しいビルドステップに両方を同時に導入できます。この 1 つの変更により、レイヤーが変更されるたびに新しいビルドがリモートキャッシュを更新し、すべてのビルドが常に最新のキャッシュを使用します。 このビルドを実行して AWS コンソールに移動し、 Amazon ECR にプッシュされた内容を確認してみましょう。 イメージとキャッシュがあることがわかります。後続のビルドでは、 Dockerfile のキャッシングのベストプラクティス に従うビルドの場合、イメージのビルドステップがかなり速くなるはずです。 CI/CD ソリューションを最新バージョンの Docker または BuildKit にアップデートする方法については、 CI/CD プロバイダーのドキュメントを参照してください。代表的な CI/CD ソリューションのアップデート方法の例を紹介します。 GitLab CI の場合 GitLab Runner の docker image の tag を最新バージョンの dind に簡単に変更できるはずです。 GitHub Actions では、 setup-buildx-action を、バージョンが最新に設定されているか、バージョン文字列が 0.12 以降に設定されていることを確認してください。 Travis CI の場合は、 こちら から Travis インストレーションを更新できます。 CircleCI の場合、yml の setup_remote_docker にあるバージョンを、 こちら に示されているサポートされている最新のバージョンに変更できるはずです。 まとめ このブログ記事で説明したソリューションを使用すると、 Amazon ECR にリモートビルドキャッシュを保存することでコンテナのビルドを高速化できます。私たちの信条は、 AWS のお客様だけでなく、 OCI のようなオープンソースコミュニティや標準にも適したソリューションを提供することです。 Amazon ECR では、 BuildKit へのサポートの組み込みが、よりオープンで互換性のあるリモートキャッシュソリューションを実現したと考えています。今すぐ CI/CD のビルドパイプラインでリモートキャッシュをお試しいただき、高速で一貫したイメージビルド時間のメリットを体験してください！ 筆者 Matt Kang 翻訳はソリューションアーキテクトの瀧田 直斗が担当しました。原文は こちら です。

2023 年 10 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Control Tower 機能紹介編 統制の効いたマルチアカウント環境を構築する際に AWS Control Tower は有力な選択肢です。AWS Black Belt Online Seminar AWS Control Tower 機能紹介編では、AWS Control Tower の各機能の詳細を紹介いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Control Tower に興味のある方 AWS Control Tower について深く学びたい方 本 BlackBelt で学習できること AWS Control Tower の各機能の詳細 ランディングゾーン コントロール Account Factory スピーカー 桂井俊朗 ソリューションアーキテクト AWS Lake Formation AWS Lake Formation は安全なデータレイクを簡単に作ることができるサービスです。主要な機能としてデータレイクへの一元的なアクセス制御やデータレイクへのデータ投入、クロスアカウントやクロスリージョンでのデータ共有を行うことが可能です。 資料（ PDF ） 対象者 前提知識は、「AWS のグローバルインフラストラクチャやフルマネージドサービスの概念」と「AWS の基盤となるサービスの基本的な知識」です。 対象者は安全なデータレイクを作る上で「AWS Lake Formation」で何ができるのかを知りたい方です。 本 BlackBelt で学習できること AWS Lake Formation の基本的なサービス概要、Lake Formation の仕組み、Lake Formation の各種機能の詳細を解説します。 スピーカー 佐藤祥多 アナリティクススペシャリストソリューションアーキテクト Amazon SageMaker Canvas ノーコードで始める機械学習【ML-Dark-10】 Amazon SageMaker Canvas を利用してノーコードで機械学習を始める方法について解説しました。 資料（ PDF ） | 動画（ YouTube ） 対象者 まだ機械学習の知識・スキルはないけど、業務に機械学習を活用したい方 データ分析・機械学習のワークロードを効率化したい方 本 BlackBelt で学習できること Amazon SageMaker Canvas の使い方・使いどころ ビジネス課題へ機械学習を適用するはじめの一歩 既存の ML ワークロードを効率化する方法 スピーカー 小杉知己 プロフェッショナルサービス AWS Application Discovery Service の概要（AWS 移行準備シリーズ） クラウド移行をはじめるには、品質や TCO を考慮しつつ移行プランを作成する等入念な移行準備が必要になります。AWS では、そのための情報を収集する Discovery ツールを提供しています。本セッションでは、そのうちの1つ、エージェントまたはエージェントレス型での情報収集を行う AWS Application Discovery Service をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 移行案件に関わったことのある、これから関わられる方の内、移行を企画・検討中の方、移行プランの策定を行う方、IT 資産の棚卸しを検討中の方、特に、上記に取り組まれる PM 、アーキテクトの方 本 BlackBelt で学習できること Discovery 作業（情報収集）の必要性、および AWS Application Discovery Service の概要 スピーカー 鈴木槙将 ソリューションアーキテクト Amazon Monitron Part 2（設定編） Amazon Monitron は回転機器の振動や温度データを、設備に貼り付けた電源不要のセンサーデバイスでクラウド上へ収集しクラウドで分析することで、潜在的な障害の予兆を検知して、計画外のダウンタイム発生を防止するソリューションです。このセミナーでは Amazon Monitron シリーズ Part 2 として、Amazon Monitron を購入し実際に利用開始する方法を説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 工場、プラント、物流拠点等で設備の計画外ダウンタイムを減らしたい方 モーター・ギア・ベアリング・ポンプ・コンプレッサーなどの回転体部品を多く稼働させておりそれらの点検保守を効率化したい方 機器の計画保守（定期的な点検保守）を減らし、データに基づく予測型保守を導入したい方 Amazon Monitron ( 基礎編）Part1 で Amazon Monitron の仕組みを学んだ方 本 BlackBelt で学習できること Amazon Monitron ( 基礎編）Part1 で Amazon Monitron の仕組みを学んだ方向けに、今回の Part 2 では Amazon Monitron を購入し実際に利用開始する方法を説明します。 スピーカー 伊藤ジャッジ向子 ソリューションアーキテクト Amazon EventBridge グローバルエンドポイント この動画では、Amazon EventBridge のグローバルエンドポイントの機能について紹介します。本機能を使用することで、システムのレジリエンスを向上させ、より堅牢なアプリケーションを開発することが可能になります。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon EventBridge について基本的な知識をお持ちの方 システムのレジリエンス向上に興味のある方 Amazon EventBridge を利用したマルチリージョン構成をご検討の方 本 BlackBelt で学習できること EventBridge グローバルエンドポイントを使用した高可用性アプリケーションの設計・開発方法 スピーカー 櫻谷広人 パートナーソリューションアーキテクト Amazon Connect カスタム CCP による従業員体験の向上 Amazon Connect では、公開している API を使用してお客様がソフトフォンを自由にカスタマイズ可能です。本セッションはコンタクトセンターにおける様々な課題のうち従業員体験の課題にフォーカスし、技術的な解決方法としてサンプルのカスタムソフトフォンをご紹介し、アーキテクチャを詳細に解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect カスタム CCP の具体的な実装例を知りたい方 フロントエンド/バックエンド開発の基本的な知識のある方 本 BlackBelt で学習できること Amazon Connect のエージェントインタフェースを拡張するための実装方法、および Amazon Connect のメトリクスを取得する際の注意点について学習できます。 スピーカー 清水幸典、小柳ちか子 Amazon Connect スペシャリスト ソリューションアーキテクト、プロトタイピングエンジニア Amazon Connect Google Chrome サードパーティ Cookie の段階的廃止に関する対応 Google 社のプライバシーサンドボックスの取り組みの一環として、Google Chrome にてサードパーティ Cookie を段階的に廃止する計画が発表されました。このセミナーでは、Amazon Connect で Chrome を継続的にご使用頂くために必要な対応について説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect をご利用中のエンドユーザー様、パートナー様 Amazon Connect でカスタム CCP に関する基本的な知識や開発経験をお持ちの技術者 本 BlackBelt で学習できること Chrome のサードパーティ Cookie 廃止に伴いカスタム CCP や CTI Adapter において必要な対応および注意点 スピーカー 梅田裕義 ソリューションアーキテクト Amazon EC2 Auto Scaling スケーリングポリシーとおすすめ機能編 Amazon EC2 Auto Scaling の活用編として、スケーリングポリシーとおすすめ機能についてご紹介いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 基盤環境のインフラを担当されている方 EC2 インスタンスの自動スケールと管理に必要な知識を知りたい方 本 BlackBelt で学習できること Auto Scaling サービス群の整理、令和におすすめのスケーリングポリシー、よくあるご質問をご紹介します。 スピーカー 滝口開資 シニアスペシャリストソリューションアーキテクト AWS CloudFormation DeepDive 編 AWS CloudFormation は、インフラストラクチャをコードとして扱うことで、リソースをモデル化、プロビジョニング、管理することができます。 本セミナーでは、AWS CloudFormation を活用する上で有効な機能について紹介していきます。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS CloudFormation の深い機能を知りたい方 カスタムリソースやマクロなどカスタム機能について詳細を知りたい方 本 BlackBelt で学習できること カスタムリソースやマクロといったカスタム機能の詳細 スタックやリソースの保護に関する機能 AWS CodePipeline と組み合わせた構成例 スピーカー 山本一生 クラウドサポートエンジニア AWS CloudFormation CloudFormation レジストリ編 AWS CloudFormation は、インフラストラクチャをコードとして扱うことで、リソースをモデル化、プロビジョニング、管理することができます。 本セミナーでは、CloudFormation レジストリの概要や機能、実装について解説いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 CloudFormation レジストリに興味のある方 CloudFormation 上で独自に実装したロジックを実行されたい方 本 BlackBelt で学習できること CloudFormation レジストリの概要や機能 CloudFormation に対応したリソースの実装方法 スピーカー 山本一生 クラウドサポートエンジニア AWS CloudFormation よくあるユースケースと質問編 AWS CloudFormation の よくあるユースケース別の使い方や質問について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 本セミナーでは、AWS CloudFormation の ユースケース や よく聞かれる疑問に興味のある方 AWS の基本的な概要や操作、AWS CloudFormation の用語について理解している方 本 BlackBelt で学習できること よくあるユースケースとして、手動で作ったリソースの CloudFormation の管理化に入れる方法や CloudFormation テンプレートの分割方法、複数の AWS アカウントやリージョンに基本設定を展開するなどの様々な例を取り上げて解説します。 スピーカー 木村友則 ソリューションアーキテクト AWS Budgets AWS Budgets を使用すると、想定外の料金の増加にいち早く気付くことができます。 AWS Budgets を使用した予算、予算レポートのポイント、設定方法をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 料金の予算管理をしたい方 AWS 料金の想定外の増加にいち早く気付きたい方 AWS 料金の予測することにより、既存の計画の改善をしたい方 本 BlackBelt で学習できること AWS Budgets の概要と基本的な使い方 AWS Budgets Report の概要と基本的な使い方 AWS Chatbot を使用したチャットツールとの連携方法 スピーカー 岡本迅人 シニアテクニカルアカウントマネージャ Amazon CodeCatalyst Overview 編 Amazon CodeCatalyst は、アプリケーションの開発、ビルド、デプロイ、およびテストを簡単かつ迅速に行うための「統合ソフトウェア開発サービス」です。Overview 編では、Amazon CodeCatalyst の全体像を解説します。 資料（ PDF ）  対象者 チーム開発をするすべてのアプリケーション開発者 Amazon CodeCatalyst の全体像を理解したい方 本 BlackBelt で学習できること Amazon CodeCatalyst のメリット Amazon CodeCatalyst の機能と概念 Amazon CodeCatalyst の料金 スピーカー 三尾泰士 ソリューションアーキテクト Amazon GameLift FleetIQ Amazon GameLift FleetIQ は、セッションベースのオンラインマルチプレイヤーゲームの専用ゲームサーバーをホスティングする AWS サービス Amazon GameLift に含まれる、専用ゲームサーバー向けに Amazon EC2 と Amazon EC2 Auto Scaling の活用を最適化するホスティングオプションです。 本セミナーでは、Amazon GameLift FleetIQ の概念と統合方法について体系的に解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 柔軟性の高い専用ゲームサーバーホスティングサービスを検討されている方 既存の専用ゲームサーバーを AWS でホスティングしたい方 Amazon GameLift FleetIQ の導入予定・検討中の方 本 BlackBelt で学習できること Amazon GameLift FleetIQ の概念と統合方法 スピーカー 安藤怜央 ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2023-11 Amazon Linux 最新情報 ソリューションアーキテクト 寺部祐菜 2023-11 Karpenter Basic ソリューションアーキテクト 多田慎也 2023-11 AWS SAW – セルフサービス自動化ランブックを使用したトラフィック監視の視覚化 Amazon Virtual Private Cloud (Amazon VPC) 編 クラウドサポートエンジニア 中村佑希 2023-11 AWS CloudFormation#2 基礎編 クラウドサポートエンジニア 上原優樹 2023-11 AWS CloudFormation 開発・テスト・デプロイ編 ソリューションアーキテクト 山川達也 2023-11 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Kubernetes Service (Amazon EKS) 編 クラウドサポートエンジニア 坂元龍太 2023-11 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Compute Cloud – Windows 編 クラウドサポートエンジニア 和田智優 2023-11 Amazon CloudWatch Evidently テクニカルアカウントマネージャー 日平大樹 2023-11 AWS SAW – Nitro システムへの移行を支援する SAW ランブックのご紹介（EC2 Linux 編） クラウドサポートエンジニア 渡邉亮藏 2023-11 AWS SAW – セルフサービスなトラブルシューティング Amazon S3 + AWS Lambda 編 クラウドサポートエンジニア 石川直哉 2023-12 Amazon DynamoDB: Under the hood ソリューションアーキテクト 堤勇人 2023-12 Amazon CodeCatalyst Dev Environment 編 ソリューションアーキテクト 髙柴元 2023-12 Amazon CodeCatalyst Project 編 ソリューションアーキテクト 堀竜慈 2023-12 Amazon CodeCatalyst Space 編 ソリューションアーキテクト 柳久保友貴 2023-12 Amazon CodeCatalyst Workflow 編 パートナーソリューションアーキテクト 田中 創一郎 2023-12 Amazon CodeCatalyst Issues 編 ソリューションアーキテクト 江口昌宏 2023-12 Amazon MemoryDB Overview ソリューションアーキテクト 堤勇人 2023-12 モダナイゼーションプロジェクト立ち上げのポイント ソリューションアーキテクト 平岩梨果 2023-12 Amazon DataZone Overview ソリューションアーキテクト 平井健治 2023-12 移行戦略 (7R) の概要（AWS 移行準備シリーズ） テクニカルインストラクター 杉山大夢 2023-12 AWS への大規模移行のための戦略とベストプラクティス カスタマーソリューションマネージャー 大熊正浩

AWS Health の新機能を発表し、AWS リソースの計画されたライフサイクルイベントを管理し、チームがリソースレベルで実行する完了アクションを動的に追跡して、アプリケーションの円滑な運用を継続できるようにします。計画されているライフサイクルイベントの例としては、 Amazon Elastic Kubernetes Service (Amazon EKS) の Kubernetes バージョンの標準サポート終了、 Amazon Relational Database Service (Amazon RDS) の証明書のローテーション、他のオープンソースソフトウェアのサポート終了などが挙げられます。 これらの機能には以下が含まれます。 アプリケーションの中断を最小限にするために、可能な限りリソースレベルでアクションの完了を動的に追跡する機能。 マイナーな変更については少なくとも90日前、メジャーな変更については可能な限り180日前に通知を使用し、今後予定されているライフサイクルイベントをタイムリーに可視化します。 準備とアクションの実行に役立つ標準化されたデータ形式。AWS Health API を使用して、AWS Health イベントをお好みの運用ツールとプログラムで統合します。 委任された管理者を持つ全社的なワークロードを管理するチームの 計画されたライフサイクルイベントを組織全体で可視化します 。これは、Cloud Center of Excellence (CCoE) チームなどの中央チームが、組織ビューにアクセスするために管理アカウントを使用する必要がなくなったことを意味します。 Amazon EventBridge 上の組織内のすべてのアカウントからの AWS Health イベント の単一のフィード。これは、EventBridge 上でルールを作成してアクションを実行することで、組織全体の AWS Health イベントの管理を自動化するための一元的な方法を提供します。イベントの種類に応じて、イベント情報の取得、追加イベントの開始、通知の送信、是正処置、その他のアクションを実行できます。例えば、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスなどのアップデートがスケジュールされている AWS リソースが AWS アカウントにある場合、AWS Health を使用して、AWS コンソールモバイルアプリケーションに メール、AWS Chatbot、またはプッシュ通知を受け取ること ができます。 仕組み 計画されたライフサイクルイベントは、AWS Health Dashboard、AWS Health API、EventBridge から利用できます。AWS Health 通知を受信したり、作成したルールに基づいてアクションを開始するために、 “source”: [“aws.health”] 値を含む EventBridge 上のルールを作成すること によって、組織全体の AWS Health イベントの管理を自動化できます。例えば、AWS Health が EC2 インスタンスに関するイベントをパブリッシュした場合、これらの通知を使用してアクションを起こし、必要に応じてリソースを更新または置き換えることができます。「 スケジュールされた変更 」タブで、AWS リソースの計画されたライフサイクルイベントを見ることができます。 テーブルビュー – 組織レベル イベントの優先順位をつけるために、予定されている変更をカレンダービューで確認できるようになりました。イベントには、変更がいつ開始されるかを示す開始時刻があります。ステータスは、変更が発生するか、影響を受けるすべてのリソースに処置が施されるまで、「 今後の予定 」のままです。イベントのステータスは、影響を受けるすべてのリソースのアクションが完了したときに「 完了 」に変わります。 注目したくないイベントステータスの選択を解除することもできます。より具体的なイベントの詳細を表示するには、イベントを選択して、画面の右または下に分割パネルビューを開きます。 選択されたカレンダーイベント – 組織レベル（影響を受けるリソース） イベントの詳細表示で「 影響を受けるリソース 」タブを選択すると、影響を受けるリソースを解決するために適切な人々に働きかけるのに役立つ関連アカウント情報を見ることができます。 影響を受けるリソースビュー – アカウントレベル 他の AWS サービスとの統合 AWS Health に既に存在する EventBridge 統合を使用すると、変更イベントとその完全に管理されたライフサイクルを、JIRA、ServiceNow、 AWS Systems Manager OpsCenter などの他のツールに送信できます。EventBridge は、イベントに対するすべての更新（例えば、タイムスタンプ、リソースステータスなど）をこれらのツールに送信し、お好みのツーリングでイベントのステータスを追跡できるようにします。 EventBridge 統合 今すぐご利用いただけます AWS Health の計画されたライフサイクルイベントは、中国と GovCloud リージョンを除く、AWS Health が利用可能なすべての AWS リージョン で利用可能です。 詳細については、 AWS Health ユーザーガイド にアクセスしてください。ご質問は AWS re:Post for AWS Health 、または通常の AWS サポート窓口までお送りください。 — Veliswa 原文は こちら です。

「 データは、あらゆるアプリケーション、プロセス、ビジネス上の意思決定の中心にあります 」と、AWS のデータベース、分析、機械学習担当バイスプレジデントである Swami Sivasubramanian は述べていますが、まったく同感です。お客様が現在使用している一般的なパターンは、データパイプラインを構築して Amazon Aurora から Amazon Redshift にデータを移動することです。これらのソリューションは、売上の増加、コストの削減、ビジネスの最適化に役立つインサイトを得るのに役立ちます。 分析用のデータを準備するのではなく、データから価値を創出することに集中していただけるように、AWS re:Invent 2022 で Amazon Redshift との Amazon Aurora ゼロ ETL 統合を発表し 、2023 年 6 月に Amazon Aurora MySQL 互換エディションの パブリックプレビュー を行うことを発表しました。 一般提供開始: Amazon Redshift との Amazon Aurora MySQL ゼロ ETL 統合 11月7日、Amazon Redshift との Amazon Aurora MySQL ゼロ ETL 統合が一般公開されたことを発表しました。このフルマネージドソリューションがあれば、トランザクションデータから時間的制約のあるインサイトを引き出して重要なビジネス上の意思決定を行うために、複雑なデータパイプラインを構築して維持する必要がなくなります。 Amazon Aurora と Amazon Redshift の ゼロ ETL 統合 により、Amazon Redshift のペタバイト単位のトランザクションデータに対して、ほぼリアルタイムの分析と機械学習 (ML) を実行できるようになります。このデータが Aurora に書き込まれると、数秒以内に Amazon Redshift で利用できるようになります。 また、Amazon Redshift の複数の Aurora MySQL データベースクラスターから統合分析を実行して、多くのアプリケーションやパーティションにわたる総合的なインサイトを引き出すこともできます。 Amazon Redshift との Amazon Aurora MySQL ゼロ ETL 統合により、複数の Aurora データベースからの 1 分あたり 100 万件を超えるトランザクション (1 分あたり 1,750 万件の行の挿入/更新/削除操作に相当) が処理され、それらを Amazon Redshift で 15 秒未満で利用できるようになります (レイテンシーラグ 50 倍)。 さらに、マテリアライズドビュー、リージョン間のデータ共有、複数のデータストアやデータレイクへのフェデレーションアクセスなど、Amazon Redshift の分析機能と組み込みの ML 機能を活用できます。 使用を開始しましょう この記事では、いくつかのステップと、簡単に始めるための情報について説明します。既存の Amazon Aurora MySQL サーバーレスデータベースと Amazon Redshift データウェアハウスを使用します。 まず、Amazon RDS に移動し、 ゼロ ETL 統合 ページで ゼロ ETL 統合を作成 を選択する必要があります。 ゼロ ETL 統合の作成 ページで、いくつかのステップに従って、Amazon Aurora データベースクラスターと Amazon Redshift データウェアハウスの統合を設定する必要があります。 まず、統合用の識別子を定義し、 次へ を選択します。 次のページで、 RDS データベースの参照 を選択してソースデータベースを選択する必要があります。 ここでは、既存のデータベースをソースとして選択できます。 次のステップでは、ターゲットの Amazon Redshift データウェアハウスを尋ねられます。ここでは、自分のアカウントまたは別のアカウントで Amazon Redshift Serverless または RA3 データウェアハウスを柔軟に選択できます。 Redshift データウェアハウスの参照 を選択します。 次に、ターゲットデータウェアハウスを選択します。 Amazon Aurora はデータウェアハウスに複製する必要があるため、リソースポリシーを追加し、Aurora データベースを Amazon Redshift データウェアハウスの承認された統合ソースとして追加する必要があります。 この問題は、Amazon Redshift コンソールで手動で更新するか、Amazon RDS に修正を任せることで解決できます。チェックボックスにチェックを入れます。 次のページでは、Amazon RDS が実行する変更が表示されます。 続行 を選択します。 次のページでは、タグと暗号化を設定できます。デフォルトでは、ゼロ ETL 統合は AWS Key Management Service (AWS KMS) を使用してデータを暗号化します。独自のキーを使用することもできます。 次に、すべての設定を確認し、 ゼロ ETL 統合の作成 を選択して統合を作成する必要があります。 数分後に、ゼロ ETL 統合が正常に作成されました。次に、Amazon Redshift に切り替えると、 ゼロ ETL 統合 ページに、最近作成したゼロ ETL 統合があることがわかります。 統合には、まだ Amazon Redshift 内にターゲットデータベースがないため、ターゲットデータベースを作成する必要があります。 これで統合設定は完了です。このページでは、統合ステータスがアクティブで、複製されたテーブルが 1 つあることがわかります。 テストのために、Amazon Aurora データベースに新しいテーブルを作成し、このテーブルにレコードを挿入します。 その後、Amazon Redshift 内部の Redshift クエリエディタ v2 に切り替えました。ここで、統合の一環として作成したデータベースに接続できます。簡単なクエリを実行すると、データが Amazon Redshift 内ですでに利用可能であることがわかります。 このゼロ ETL 統合は、2 つの理由で非常に便利だと思いました。まず、複数のデータベースクラスターのすべてのデータを統合し、集約して分析できました。次に、トランザクションデータが Amazon Aurora MySQL に書き込まれてから数秒以内に、このゼロ ETL 統合により、Amazon Redshift でシームレスにデータを使用できるようになりました。 留意点 可用性 – Amazon Redshift との Amazon Aurora ゼロ ETL 統合は、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) でご利用いただけます。 サポートされているデータベースエンジン – Amazon Redshift との Amazon Aurora ゼロ ETL 統合は現在、Amazon Aurora の MySQL 互換エディションをサポートしています。Amazon Aurora PostgreSQL 互換エディションのサポートは現在進行中です。 価格 –  Amazon Redshift との Amazon Aurora ゼロ ETL 統合は追加料金なしで提供されます。ゼロ ETL 統合の一環として作成された変更データの作成と処理に使用された既存の Amazon Aurora および Amazon Redshift リソースに対してお支払いいただきます。 私たちは、お客様が分析用のデータを準備するのではなく、データから価値を創出することに集中していただけるよう、また一歩前進しています。開始方法の詳細については、 Amazon Redshift との Amazon Aurora MySQL ゼロ ETL 統合 ページをご覧ください。 統合おめでとうございます! —  Donnie 原文は こちら です。

Amazon Data Lifecycle Manager は、 AWS Systems Manager ドキュメントに埋め込まれたスナップショット前のスクリプトとスナップショット後のスクリプトの使用をサポートするようになりました。これらのスクリプトを使用して、 Data Lifecycle Manager によって作成された Amazon Elastic Block Store (Amazon EBS) スナップショットにアプリケーション整合性があることを確認できます。スクリプトは、I/O 操作の一時停止と再開、バッファリングされたデータの EBS ボリュームへのフラッシュなどを行えます。このリリースの一環として、セルフマネージドリレーショナルデータベースと Windows Volume Shadow Copy Service (VSS) でこの機能の使用方法を示す詳細なブログ記事も公開します。 Data Lifecycle Manager (DLM) のまとめ 簡単にまとめると、 Data Lifecycle Manager は、Amazon EBS ボリュームスナップショットの作成、保持、削除を自動化するのに役立ちます。EC2 インスタンスを AWS Systems Manager にオンボーディングする、DLM 用の IAM ロールをセットアップする、SSM ドキュメントにタグを付けるなどの前提条件となるステップを完了したら、ライフサイクルポリシーを作成し、該当する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを (タグで) 示し、保持モデルを設定して、残りは DLM に任せるだけです。ポリシーでは、スナップショットをいつ実行するか、何をバックアップするか、どれだけの期間スナップショットを保持するかを指定します。DLM の詳細な説明については、2018 年のブログ記事「 新規 – Amazon EBS スナップショットのライフサイクル管理 」をご覧ください。 アプリケーション整合性があるスナップショット EBS スナップショットは Crash-consistent です。つまり、スナップショットが作成された時点の関連付けられた EBS ボリュームの状態を表しています。アクティブなリレーショナルデータベースの状態をキャプチャするためにスナップショットを使用しないアプリケーションを含め、多くの種類のアプリケーションにはこれで十分です。 アプリケーション整合性 があるスナップショットを作成するには、保留中のトランザクション (処理が完了するのを待っている、またはトランザクションが失敗するのいずれか) を考慮し、それ以降の書き込み操作を一時的に停止し、スナップショットを作成して、通常の操作を再開する必要があります。 そして、それが今日のリリースが行われる場所です。DLM は、アプリケーション整合性があるバックアップの準備をするようインスタンスに指示できるようになりました。スナップショット前のスクリプトは、保留中のトランザクションを管理したり、メモリ内のデータを永続ストレージにフラッシュしたり、ファイルシステムを フリーズ させたり、アプリケーションやデータベースを停止させたりすることができます。その後、スナップショット後のスクリプトによって、アプリケーションやデータベースを元の状態に戻したり、永続ストレージからメモリ内キャッシュをリロードしたり、ファイルシステムを解凍したりすることができます。 カスタムスクリプトの基本レベルのサポートに加えて、この機能を使用して VSS Backup スナップショットの作成を自動化することもできます。 前および後のスクリプト 新しいスクリプトはインスタンスの DLM ポリシーに適用されます。スナップショット前のスクリプトとスナップショット後のスクリプトを含む SSM ドキュメントを参照するポリシーを作成し、それが単一のインスタンスに適用されると仮定します。ポリシーをスケジュールに従って実行すると、次のようになります。 スナップショット後のスクリプトは SSM ドキュメントから起動されます。 スクリプト内の各コマンドが実行され、スクリプトレベルのステータス (成功または失敗) がキャプチャされます。ポリシーで有効になっている場合、DLM は失敗したスクリプトを再試行します。 マルチボリューム EBS スナップショットは、インスタンスにアタッチされた EBS ボリュームに対して開始され、ポリシーによってさらに制御されます。 スナップショット後のスクリプトは SSM ドキュメントから起動されます。 スクリプト内の各コマンドが実行され、スクリプトレベルのステータス (成功または失敗) がキャプチャされます。 ポリシーには、いずれかのスクリプトがタイムアウトまたは失敗したときに実行されるアクション (再試行、続行、またはスキップ) を制御できるオプションが含まれています。ステータスはログに記録され、 Amazon CloudWatch メトリクスが公開され、 Amazon EventBridge イベントが発行されます。また、ステータスは各スナップショットに自動的に割り当てられるタグにエンコードされます。 スナップショット前のスクリプトとスナップショット後のスクリプトは、コマンドドキュメントで許可されている任意のアクション ( シェルスクリプトの実行 、 PowerShell スクリプトの実行 など) を実行できます。アクションは、ポリシーで指定されたタイムアウト (10 秒から 120 秒の許容範囲) 内に完了する必要があります。 開始方法 堅牢なスクリプトペアを構築するには、アプリケーションまたはデータベースを詳細に理解する必要があります。すべてがうまくいったときに「ハッピーパス」を処理することに加えて、スクリプトはいくつかの障害シナリオに備えて計画を立てる必要があります。例えば、スナップショット前のスクリプトは、スナップショット後のスクリプトが期待どおりに動作しない場合に備えて、フェイルセーフとして機能するバックグラウンドタスクをフォークする必要があります。各スクリプトは、 こちら で詳しく説明するように、シェルレベルのステータスコードを返す必要があります。 スクリプトを作成してテストし、SSM ドキュメントとしてパッケージ化したら、EC2 コンソールの Data Lifecycle Manager ページを開き、 EBS スナップショットポリシー を選択して、[ 次のステップ ] をクリックします。 本稼働 の モード でタグ付けされたすべてのインスタンスをターゲットにし、デフォルトの IAM ロールを使用し (別のロールを使用する場合は、SSM へのアクセスを有効にする必要があります)、残りの値はそのままにして、次に進みます。 次のページで、[ 前および後のスクリプト ] まで下にスクロールして、セクションを展開します。[ 前および後のスクリプトを有効にする ] をクリックし、[ カスタム SSM ドキュメント ] を選択して、メニューから [自分の SSM ドキュメント] を選択します。また、タイムアウトと再試行のオプションも設定し、スクリプトの 1 つが失敗した場合は Crash-consistent バックアップをデフォルトに設定しています。[ ポリシーをレビュー ] をクリックし、最後の確認をして、次のページの [ ポリシーを作成 ] をクリックします。 自分のポリシーが作成され、すぐに有効になります。少なくとも 1 回実行したら、CloudWatch メトリクスを調べて、開始、完了、失敗の有無を確認できます。 その他の参考資料 先ほどお約束した詳細なブログ投稿の最初の記事は次のとおりです。 MySQL と PostgreSQL のアプリケーション整合性があるスナップショットの作成を自動化する VSS バックアップの作成を自動化する 今年後半に向けてさらに多くの作業を進めており、公開されたら上記のリストを更新します。 また、 ドキュメント を読んで詳細を確認することもできます。 DLM ビデオ この機会に、有用なビデオをいくつかご紹介します。 ポリシーステータスの変化をモニタリングする CloudWatch イベントでポリシーをモニタリングする CloudWatch メトリクスでポリシーアクションをモニタリングする Amazon Data Lifecycle Manager で Amazon EBS スナップショットと AMI を管理する 新しい機能がすでに利用でき、今日からすぐに使用を開始できます。 – Jeff ; 原文は こちら です。

この記事は Backup and restore your Amazon EKS cluster resources using Velero (記事公開日: 2021 年 12 月 1 日) を翻訳したものです。 2023 年 9 月 9 日更新: この記事はもともと 2021 年 12 月 1 日に掲載されました。最新の EKS バージョンと Velero Helm チャートの変更をサポートするため、このブログ記事のウォークスルー手順を更新しました。 世界中の企業がマイクロサービスをカプセル化するためにコンテナを採用しており、その多くはコンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するために Kubernetes を選択しています。これらのマイクロサービスの数が増えるにつれて、以下を行うための一元的なバックアップのメカニズムを導入することがますます重要になります。 物理的および論理的なエラーが発生した場合のアプリケーションの保護 Kubernetes クラスター間のマイグレーションの実行 本番環境クラスターの開発環境やテスト環境へのレプリケーション Velero は、Kubernetes クラスターのディザスタリカバリ、データ移行、データ保護を提供する人気のあるオープンソースツールです。Velero は、Kubernetes のクラスターリソースと永続ボリューム (Persistent Volume) を、オンデマンドまたはスケジュールに従って、サポートされた外部のストレージバックエンドにバックアップできます。 Amazon Elastic Kubernetes Service (Amazon EKS) は、高可用かつ安全な Kubernetes クラスターを提供し、パッチ適用、ノードのプロビジョニング、アップデートなどの主要タスクを自動化にするのに役立つマネージドソリューションです。AWS のお客様は、このソリューションを活用して、Kubernetes オブジェクトとアプリケーションを Amazon EKS からバックアップ、および Amazon EKS にリストアできます。これは、お客様は Velero を使用して、セルフホスト型の Kubernetes から Amazon EKS に移行できることも意味します。 このブログ記事では、Velero を使用して Amazon EKS クラスターのリソースをバックアップ、リストア、移行する方法に焦点を当て、組織のユースケースに最適なアプローチを決定するために Velero が提供するバックアップオプションを紹介します。 Velero の概要 このセクションでは、Velero と Amazon EKS の統合方法、このツールがアプリケーションのバックアップとリストアのために提供するカスタマイズ、およびバックアップとリストアのワークフローについて説明します。 Velero と Amazon EKS Amazon EKS のアプリケーションレベルのバックアップは、次の 2 つのコンポーネントが対象となります。 etcd キーバリューストアに保存された Kubernetes オブジェクトとコンフィギュレーション Persistent Volume に保存されたアプリケーションデータ Amazon EKS では、etcd キーバリューストアは AWS によって管理され、Kubernetes API サーバーを介してのみアクセスできます。Velero は Kubernetes API を利用して、キーバリューストアに保存されているデータを取得します。API 呼び出しでは、名前空間 (Namespace)、リソースタイプ、またはラベルによってリソースを簡単にフィルタリングできるため、このアプローチは etcd に直接アクセスするよりも柔軟性があります。例えば、ラベルでフィルタリングしてバックアップの範囲を特定のアプリケーションに制限したり、オブジェクトタイプでフィルタリングして現在の RBAC 戦略を保存したりできます。 また、Velero はクラスターの Persistent Volume のスナップショットを取得し、クラスターのオブジェクトと一緒にリストアできます。詳細は次のセクションで説明します。 バックアップとリストア操作は Kubernetes の カスタムリソース定義 (CRD) オブジェクトとして宣言されます。CRD はこれらの新しい CRD オブジェクトを処理するコントローラーによって管理され、バックアップ、リストア、およびすべての関連操作が実行されます。これらのバックアップとリストアの CRD オブジェクトを作成する際は、以下のカスタマイズを指定できます。 リソースのフィルタリング : Namespace、オブジェクトタイプ、ラベルでフィルタリングして、バックアップやリストアの範囲を制限します。リストア時に、Namespace とオブジェクトタイプを除外してフィルタリングできます。 バックアップタイプの選択 : オンデマンドバックアップを作成するか、定期的にバックアップを自動的に開始するスケジュールを設定します。 保持時間の設定 : バックアップを保持する期間を指定します。 フックの指定 : バックアップまたはリストア操作の前後にコンテナ内でカスタムコマンドを実行するためのプレフックとポストフックを設定します。 バックアップとリストアのワークフロー Velero は 2 つのコンポーネントで構成されます。 Velero サーバー : Amazon EKS クラスター内で実行される Pod Velero CLI : ローカルで実行されるコマンドラインクライアント Amazon EKS クラスターに対してバックアップを発行するたびに、Velero は以下の方法でクラスターリソースのバックアップを実行します。 Velero CLI が Kubernetes API サーバーにアクセスし、バックアップ CRD オブジェクトを作成します。 バックアップコントローラーが以下を実施します。 バックアップ CRD オブジェクトのスコープ、すなわちフィルターが設定されているかどうかをチェックします。 バックアップが必要なリソースについて API サーバーにクエリを実行します。 取得した Kubernetes オブジェクトを .tar ファイルに圧縮し、 Amazon S3 に保存します。 同様に、リストア操作を発行するときは以下のようになります。 Velero CLI は Kubernetes API サーバーにアクセスし、既存のバックアップからリストアするリストア CRD オブジェクトを作成します。 リストアコントローラーが以下を実施します。 リストア CRD オブジェクトを検証します。 Amazon S3 にアクセスしてバックアップファイルを取得します。 リストア操作を開始します。 Velero は、スコープ内の Persistent Volume のバックアップとリストアも実行します。 Amazon Elastic Block Store (Amazon EBS) を使用している場合、Velero はスコープ内の Persistent Volume の Amazon EBS スナップショットを作成します。 その他のボリュームタイプ (hostPath を除く) の場合は、Velero の Restic 統合を使用して、ボリュームの内容のファイルレベルのバックアップを作成します。本記事執筆時点では、Restic はベータ版であるため、本番環境グレードのバックアップには推奨されません。 次のセクションでは、Amazon EKS 上のアプリケーションと関連する EBS ボリュームをバックアップする方法を紹介します。 ウォークスルー 以下のセクションでは、Velero を使用して、あるクラスター内のアプリケーションをバックアップし、そのアプリケーションを別のクラスター内にリストアする方法を説明します。ここでは、人気の高いオープンソースの Ghost パブリッシングプラットフォームを使用して、アプリケーション定義だけでなく、Persistent Volume Claim (PVC) を使用して EBS ボリュームに保存されているステートもバックアップおよびリストアする方法を示します。 前提条件 次のステップに進むためには、以下の前提条件が必要です。 eksctl v0.155.0 以降 : Installing or upgrading eksctl を参照してください。 同じ AWS アカウント内の 2 つの EKS クラスター : Creating an EKS Cluster を参照してください (このブログ記事は、Kubernetes バージョン 1.27 を実行する EKS でテストされました)。 この記事では、この 2 つのクラスターを Primary クラスターと Recovery クラスターと呼びます。 各クラスターは IAM OIDC プロバイダーを設定する必要があります。 Create an IAM OIDC provider for your cluster を参照してください。これは、 IAM Roles for Service Accounts (IRSA)を使用して Velero デプロイメントに必要な AWS アクセス許可を付与するため必要です。 各クラスターには Amazon EBS CSI ドライバー がインストールされている必要があります。 AWS CLI バージョン 2 : Installing, updating, and uninstalling the AWS CLI version 2 を参照してください。 Helm v3 : Installing Helm を参照してください。 kubectl : Installing kubectl を参照してください。 このチュートリアルで使用する 2 つの EKS クラスターは同じアカウントにありますが、これは Velero を使用するためのハード要件ではありません。このブログ記事をガイドラインとして使用し、必要に応じて IAM と S3 バケットのアクセス許可を調整することができます。 以下のセクションのコマンドは Bash を前提として書かれています。 Velero のインストール EKS のベストプラクティスを使用して Velero をインストールするには、いくつかのステップが必要です。まず、バックアップを保存するための S3 バケットを作成します。次に、 IAM Roles for Service Accounts (IRSA) を使用して、バックアップとリストア操作のために必要な AWS アクセス許可を Velero に付与します。最後に、このツールの操作方法を簡素化する Velero CLI をインストールします。 バックアップを保存するための S3 バケットの作成 Velero は、AWS で実行する場合、EKS のバックアップを保存するために S3 を使用します。以下のコマンドを実行して、Velero 用の S3 バケットを作成します。 <company-fqdn>-eks-velero-backups のような一意のバケット名を使用してください。 <BUCKETNAME> と <REGION> は自分の値に置き換えてください。 BUCKET=<BUCKETNAME> REGION=<REGION> aws s3 mb s3://$BUCKET --region $REGION Amazon S3 は、デフォルトで地理的に離れた複数の アベイラビリティーゾーン にデータを保存しますが、コンプライアンス要件により、さらに離れた場所にデータを保存することが求められる場合があります。 クロスリージョンレプリケーション を使用することで、これらの要件を満たすために、離れた AWS リージョン間でデータをレプリケーションすることができます。 IAM ポリシー Velero はスナップショットを実行し、バックアップを S3 バケットに保存するために、EC2 と S3 のリソースに対して多くの API 呼び出しを実行します。以下の IAM ポリシーは、Velero に必要なアクセス許可を付与します。 cat > velero_policy.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeVolumes", "ec2:DescribeSnapshots", "ec2:CreateTags", "ec2:CreateVolume", "ec2:CreateSnapshot", "ec2:DeleteSnapshot" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:DeleteObject", "s3:PutObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::${BUCKET}/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::${BUCKET}" ] } ] } EOF aws iam create-policy \ --policy-name VeleroAccessPolicy \ --policy-document file://velero_policy.json Velero の Service Account の作成 EKS クラスター上で実行されるアプリケーションに AWS ポリシーを提供するためのベストプラクティスは、 IAM Roles for Service Accounts (IRSA) を使用することです。eksctl は、必要な IAM ロールを作成し、信頼関係のスコープを velero-server Service Account に設定する簡単な方法を提供します。 <CLUSTERNAME> は Primary と Recovery の EKS クラスターの名前に置き換えてください。 PRIMARY_CLUSTER=<CLUSTERNAME> RECOVERY_CLUSTER=<CLUSTERNAME> ACCOUNT=$(aws sts get-caller-identity --query Account --output text) eksctl create iamserviceaccount \ --cluster=$PRIMARY_CLUSTER \ --name=velero-server \ --namespace=velero \ --role-name=eks-velero-backup \ --role-only \ --attach-policy-arn=arn:aws:iam::$ACCOUNT:policy/VeleroAccessPolicy \ --approve eksctl create iamserviceaccount \ --cluster=$RECOVERY_CLUSTER \ --name=velero-server \ --namespace=velero \ --role-name=eks-velero-recovery \ --role-only \ --attach-policy-arn=arn:aws:iam::$ACCOUNT:policy/VeleroAccessPolicy \ --approve --namespace=velero フラグによって、 velero Namespace で実行されているアプリケーションだけが、前のステップで作成した IAM ポリシーにアクセスできるようになります。 両方の EKS クラスターへの Velero のインストール 以下の手順には、Helm チャートを使用して Velero をインストールするために必要な手順が含まれています。この手順では、Velero バージョン v1.11.1 をインストールするチャートバージョン 5.0.2 を指定していることに注意してください。新しい Velero バージョンをインストールしたい場合は、 互換性マトリックス を使用して Velero AWS プラグインのバージョンを正しい Velero バージョンに合わせるなど、以下の values.yaml ファイルを必ず調整してください。 helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts cat > values.yaml <<EOF configuration: backupStorageLocation: - bucket: $BUCKET provider: aws volumeSnapshotLocation: - config: region: $REGION provider: aws initContainers: - name: velero-plugin-for-aws image: velero/velero-plugin-for-aws:v1.7.1 volumeMounts: - mountPath: /target name: plugins credentials: useSecret: false serviceAccount: server: annotations: eks.amazonaws.com/role-arn: "arn:aws:iam::${ACCOUNT}:role/eks-velero-backup" EOF cat > values_recovery.yaml <<EOF configuration: backupStorageLocation: - bucket: $BUCKET provider: aws volumeSnapshotLocation: - config: region: $REGION provider: aws initContainers: - name: velero-plugin-for-aws image: velero/velero-plugin-for-aws:v1.7.1 volumeMounts: - mountPath: /target name: plugins credentials: useSecret: false serviceAccount: server: annotations: eks.amazonaws.com/role-arn: "arn:aws:iam::${ACCOUNT}:role/eks-velero-recovery" EOF Velero サーバーを 2 回、 Primary クラスターと Recovery クラスターにインストールする必要があります。 kubectl config ( kubectl チートシート ) または kubectx を使用して、両方のクラスターのコンテキストを表示し、コンテキストを簡単に切り替えることができます。 kubectl config の管理を簡単にするために、エイリアスを使用してクラスターを kubeconfig に追加します。 PRIMARY_CONTEXT=primary RECOVERY_CONTEXT=recovery aws eks --region $REGION update-kubeconfig --name $PRIMARY_CLUSTER --alias $PRIMARY_CONTEXT aws eks --region $REGION update-kubeconfig --name $RECOVERY_CLUSTER --alias $RECOVERY_CONTEXT 次のコマンドを使用して、これらの新しいコンテキストがあることを確認できます。 kubectl config get-contexts 「*」が、どのコンテキストにいるかを示しています。 コンテキストを Primary クラスターに変更し、Velero をインストールしましょう。 kubectl config use-context $PRIMARY_CONTEXT helm install velero vmware-tanzu/velero --version 5.0.2 \ --create-namespace \ --namespace velero \ -f values.yaml 次に、コンテキストを Recovery クラスターに変更し、Velero をインストールしましょう。 kubectl config use-context $RECOVERY_CONTEXT helm install velero vmware-tanzu/velero --version 5.0.2 \ --create-namespace \ --namespace velero \ -f values_recovery.yaml 各コンテキストで以下のコマンドを実行することで、Velero サーバーが正常にインストールされたことを確認できます。 kubectl get pods -n velero Velero CLI のインストール Velero はコマンドを CRD としてを送信することで動作します。クラスターのバックアップを作成するには、クラスターにバックアップ CRD を送信します。これを手作業で作成するのは難しい場合があるため、Velero チームはバックアップとリストアを簡単に実行できる CLI を作成しました。ここでは、Velero CLI を使用して Primary クラスターのバックアップを作成し、 Recovery クラスターにリストアします。 インストール手順はオペレーティングシステムによって異なります。 こちら の手順に従って Velero をインストールしてください。 サンプルアプリケーションのバックアップとリストア Velero をインストールした状態で、 Primary クラスターにアプリケーションをインストールしてバックアップし、 Recovery クラスターにリストアを行います。お客様は、以下の手順に従って、自分の Amazon EKS クラスター内の自分のアプリケーションをバックアップおよびリストアすることもできます。 Ghost アプリケーションのインストール (および記事の作成) Ghost をサンプルアプリケーションとして Primary クラスターにバックアップし、 Recovery クラスターにリストアします。一般的にデプロイされ、十分にテストされている Bitnami Helm チャート を使用します。このチャートは、ブログアプリケーションのための永続的なデータストアとして機能する Bitnami MySQL チャート に依存しています。MySQL のデータは EBS ボリュームに保存され、バックアップ実行の一環として Velero によってスナップショットが作成されます。 それでは、 Primary クラスターにコンテキストに切り替え、Ghost をインストールしましょう (Ghost をインストールするときに表示される通知 ERROR: You did not provide an external host は無視してください。これは次のコマンドで解決されます)。 kubectl config use-context $PRIMARY_CONTEXT helm install ghost oci://registry-1.docker.io/bitnamicharts/ghost \ --create-namespace \ --namespace ghost export APP_HOST=$(kubectl get svc --namespace ghost ghost --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}") export GHOST_PASSWORD=$(kubectl get secret --namespace "ghost" ghost -o jsonpath="{.data.ghost-password}" | base64 -d) export MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace "ghost" ghost-mysql -o jsonpath="{.data.mysql-root-password}" | base64 -d) export MYSQL_PASSWORD=$(kubectl get secret --namespace "ghost" ghost-mysql -o jsonpath="{.data.mysql-password}" | base64 -d) helm upgrade ghost oci://registry-1.docker.io/bitnamicharts/ghost \ --namespace ghost \ --set service.type=LoadBalancer \ --set ghostHost=$APP_HOST \ --set ghostPassword=$GHOST_PASSWORD \ --set mysql.auth.rootPassword=$MYSQL_ROOT_PASSWORD \ --set mysql.auth.password=$MYSQL_PASSWORD 次のコマンドを実行することで、インストールが成功したことを確認できます。 kubectl get pods -n ghost Persistent Volume のバックアップとリストアをデモするブログ記事の作成 Helm チャートのインストールが完了すると、コンソールにチャートの README が表示されます。 これには次のものが含まれます。 ブログ URL 管理 URL デフォルトの管理者ユーザー名 kubectl を使用してパスワードを取得する手順 オプションで、(上に表示されている管理 URL を使用して) Ghost 管理コンソールにサインインし、バックアップとリストアのプロセスに含めるサンプルのブログ記事を作成することができます。これにより、バックアップにはアプリケーションのデプロイメント構成だけではなく、すべての記事を含むブログデータベースの状態も含まれることが確認できます。 記事を作成するには、まず左側のナビゲーションペインで Posts を選択します。 次に、ページの右上にある New post を選択します。 記事のタイトルを追加し、内容を書くことができます。サンプルのブログ記事を保存する準備ができたら、ページの右上にある Publish ドロップダウンメニュー項目を選択し、ドロップダウンメニューから Publish ボタンを選択します。 バックアップの作成 Primary クラスターのバックアップを作成しましょう。以下のコマンドを実行する前に、kubectl コンテキストが Primary クラスターに設定されていることを確認してください。 velero backup create ghost-backup -o フラグを使用することで、Velero のバックアップ CRD がどのように見えるかを確認できます。これは、実際にバックアップ作成を Velero サーバーに送信せずに、バックアップ CRD の YAML を出力します。 velero backup create test -o yaml バックアップ CRD では、 includedNamespaces 配列にワイルドカードが含まれているため、すべての Namespace をバックアップしていることがわかります。クラスター全体をバックアップしている場合でも、セレクターを使用してクラスターの個々のコンポーネントを選択できます。これにより、例えば単一のアプリケーションを含む単一の Namespace をバックアップできます。 バックアップが成功したことの検証 バックアップのステータスを確認し、バックアップが正常に完了したことを確認しましょう。 velero backup describe ghost-backup コマンドの出力で、 Phase: フィールドを探します。現在の Phase が InProgress の場合、しばらく待ってから Phase: Completed が表示されるまで再試行してください。開始時刻や完了時刻、バックアップされたアイテムの数などの情報を含む、バックアップの追加の詳細を確認できます。 以前に作成した Amazon S3バケット内に、Velero が作成したバックアップファイルを確認できます。 aws s3 ls $BUCKET/backups/ghost-backup/ アプリケーションの Recovery クラスターへのリストア kubectl コンテキストを Recovery クラスターに切り替えます。 kubectl config use-context $RECOVERY_CONTEXT 次のコマンドを使用して、Ghost アプリケーションのみを Recovery クラスターにリストアします。 velero restore create ghost-restore \ --from-backup ghost-backup \ --include-namespaces ghost リストアが成功したことの検証 リストアのステータスを確認し、リストアが正常に完了したことを確認しましょう。 velero restore describe ghost-restore 出力の Phase: Completed を探してください。 Phase: InProgress と表示された場合は、しばらく待ってからコマンドを再実行してください。次に、 Recovery クラスター内の Ghost ブログの LoadBalancer Service の URL を取得します。 kubectl -n ghost get svc ghost EXTERNAL-IP の URL にアクセスして、ブログがリストアされたことを確認します。Ghost ブログと、前のステップで作成したサンプルのブログ記事が表示されるはずです。 おめでとうございます！ Primary クラスターのバックアップと、 Recovery クラスターへのアプリケーションのリストアに成功しました。 本番環境のバックアップ/リストア/DR 操作では、サービスが期待通りに動作していることを確認した後、本番の DNSレコードが Recovery クラスターを指すように移動する必要がある点に注意してください。 クリーンアップ 今後の課金が発生しないようにするために、リソースを削除してください。 eksctl を使ってクラスターを作成した場合は、 eksctl delete cluster <clustername> コマンドを使用してクラスターを削除できます。 バックアップを保存するために使用した S3 バケットと、Velero が使用している IAM ロールも削除する必要があります。 aws s3 rb s3://$BUCKET --force aws iam delete-policy --policy-arn arn:aws:iam::$ACCOUNT:policy/VeleroAccessPolicy まとめ ディザスタリカバリとマイグレーション戦略にはいくつかの種類があります。このブログ記事では、Velero が障害や災害イベントからの迅速なリカバリと、Amazon EKS のアプリケーションとクラスターリソースのシームレスな移行をどのように保証するかを紹介しました。このツールが提供するオプションをハイライトし、ステートフルアプリケーションをバックアップして新しいクラスターにリストアするプロセスを紹介しました。同様に、お客様は自分のアプリケーションと Kubernetes リソースを他の Amazon EKS クラスターにマイグレーション、レプリケーション、または以前のアプリケーション状態をリストアすることもできます。 このアプローチにより、単に CI/CD パイプラインをリダイレクトして新しい EKS クラスターにデプロイするのとは対照的に、ディザスタリカバリやマイグレーションイベントのためのオペレーションを一元化できます。これは、Kubernetes においてアプリケーションのデプロイやアップデートに使用される CI/CD パイプラインは、このような状況では必要のないアクションを実行する可能性があるためです。さらに、データの永続化に対処するためのアプローチを別途考える必要もあります。代わりに、このようなイベントのための特定の CI/CD パイプラインを作成することができます。 セルフマネージド型の Kubernetes クラスターの場合、お客様は Amazon EKS への移行にこのオープンソースツールを使用することもできます。このユースケースを深く掘り下げるには、 このブログ記事 で説明されているベストプラクティスに従うことをお勧めします。 翻訳はプロフェッショナルサービスの杉田が担当しました。原文は こちら です。