[概要]Amazon DynamoDB データベースオペレーションを効率的に実行するには、エンティティを要求し、作成、読み取り、更新、削除 (CRUD) オペレーション関数が必要になるのが一般的です。PynamoDB は Python 3 をサポートする Python ベースのインターフェイスです。また、Amazon DynamoDB トランザクションのサポート、属性値の自動シリアル化と逆シリアル化、Flask や Django などの一般的な Python フレームワークとの互換性などの機能も提供します。このパターンは、PynamoDB モデルと CRUD オペレーション関数の自動作成を効率化するライブラリを提供することで、Python と DynamoDB を使用するデベロッパーに役立ちます。 PynamoDB データベーステーブルに不可欠な CRUD 関数を生成しますが、Amazon

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 AWS Lambda を使用して六角形アーキテクチャで Python プロジェクトを構築する 作成者: Furkan Oruc (AWS)、Dominik Goby (AWS)、Darius Kunce (AWS)、および Michal Ploski (AWS)

多くの場合、セカンダリインデックスは、アプリケーションに必要なクエリパターンをサポートするために必要です。同時に、セカンダリインデックスを過度に使用するか、非効率的に使用すると、コストがかかり、不要にパフォーマンスが低下する可能性があります。

CloudFront が別のリクエストをオリジンに転送するまでにファイルを CloudFront キャッシュに保持する期間を制御できます。この期間を短くすると、動的なコンテンツを供給できます。この期間を長くすると、ユーザー側のパフォーマンスは向上します。ファイルがエッジキャッシュから直接返される可能性が高くなるためです。期間を長くすると、オリジンの負荷も軽減されます。 一般的に CloudFront は、指定したキャッシュ保持期間が経過するまで、つまりファイルの有効期限が切れるまでエッジロケーションからファイルを提供します。ファイルの有効期限が切れると、エッジロケーションがファイルのリクエストを次に受け取ったときに、CloudFront は、リクエストをオリジンに転送し、キャッシュにファイルの最新バージョンが含まれていることを確認します。オリジンからのレスポンスは、ファイルが変更されたかど

[概要]マイクロサービスアーキテクチャの主な目標は、アプリケーションの俊敏性、柔軟性、および市場投入までの時間を短縮するために、分離された独立したコンポーネントを構築することです。デカップリングにより、各マイクロサービスコンポーネントには独自のデータ永続化レイヤーが設けられます。分散型アーキテクチャでは、ビジネストランザクションが複数のマイクロサービスにまたがる可能性があります。これらのマイクロサービスは単一のアトミック性、一貫性、分離、耐久性 (ACID) トランザクションを使用できないため、部分的なトランザクションになってしまう可能性があります。この場合、すでに処理されたトランザクションを元に戻すには、何らかの制御ロジックが必要です。ディストリビュートサガパターンは、通常、この目的のために使用されます。 サガパターンは、分散アプリケーションの一貫性を確立し、複数のマイクロサービス間のト

デフォルトでは、Amazon Redshift クラスターまたは Amazon Redshift Serverless ワークグループは仮想プライベートクラウド (VPC) 内にプロビジョニングされます。VPC は、パブリックアクセスを許可するか、インターネットゲートウェイ、NAT デバイス、または AWS Direct Connect 接続を設定してトラフィックをクラスターにルーティングすると、別の VPC またはサブネットからアクセスすることができます。また、Redshift 管理の VPC エンドポイント (AWS PrivateLink を使用) を設定して、クラスターまたはワークグループにアクセスすることもできます。 Redshift 管理の VPC エンドポイントは、クラスターまたはワークグループを含む VPC とクライアントツールを実行する VPC 間のプライベート接続として

Amazon RDS API を使用した問題のデバッグについては、「Amazon RDS のアプリケーションのトラブルシューティング」を参照してください。 Amazon RDS DB インスタンスに接続できない DB インスタンスに接続できない場合、一般的な原因として次のようなものがあります。 インバウンドルール - ローカルのファイアウォールによって適用されているアクセスルールと DB インスタンスへのアクセスが許可された IP アドレスが一致していない可能性があります。問題の原因として最も多いのは、セキュリティグループのインバウンドルールです。 デフォルトでは、DB インスタンスへのアクセスは許可されていません。アクセスは、DB インスタンスとの間のトラフィックを許可する VPC に関連付けられたセキュリティグループによって許可されます。必要に応じて、特定の状況のインバウンドルールとア

AWS Identity and Access Management (IAM) データベース認証を使用して、DB インスタンスを認証できます。IAM データベース認証には、MariaDB、MySQL、および PostgreSQL を使用します。この認証方法では、DB インスタンスに接続するときにパスワードを使用する必要はありません。代わりに、認証トークンを使用します。 認証トークンは、Amazon RDS がリクエストに応じて生成する一意の文字列です。認証トークンは、AWS 署名バージョン 4 を使用して生成されます。各トークンには 15 分の有効期間があります。認証は IAM を使用して外部的に管理されるため、ユーザー認証情報をデータベースに保存する必要はありません。引き続きスタンダードのデータベース認証を使用することもできます。トークンは認証にのみ使用され、確立後のセッションには影響

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon OpenSearch Service 用 AWS AppSync リゾルバーにより、GraphQL を使用してアカウントの既存の OpenSearch Service ドメインに対してデータを保存または取得することが可能になります。このリゾルバーにより、受信した GraphQL リクエストを OpenSearch Service リクエストにマッピングし、その後の OpenSearch Service のレスポンスを GraphQL にマッピングすることができます。このセクションでは、サポートされる OpenSearch Service オペレーションのマッピングテンプレートについて説明します。 リクエストマッピングテンプレート ほとんどの OpenS

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 チュートリアル: 開発エンドポイントで PyCharm Professional をセットアップする このチュートリアルでは、ローカルマシンで実行中の PyCharm Professional Python IDE を開発エンドポイントに接続し、AWS Glue ETL (抽出、転送、およびロード) スクリプトをデプロイ前にインタラクティブに実行、デバッグ、およびテストします。チュートリアルの手順とスクリーンショットは、PyCharm Professional バージョン 2019.3 に基づいています。 開発エンドポイントをインタラクティブに接続するには、PyCharm Professional がインストールされている必要があります。無料版を使用してこれを行うこ

オンライン移行を使用して、Amazon EC2 のセルフホスト Redis から Amazon ElastiCache にデータを移行できます。 概要 Amazon EC2 で実行されている Redis から Amazon ElastiCache にデータを移行するには、既存または新規作成の Amazon ElastiCache デプロイが必要です。このデプロイの設定は、移行可能な設定になっている必要があります。また、インスタンスのタイプやレプリカの数などの属性を含め、目的の設定になっている必要もあります。 オンライン移行は、Amazon EC2 でホストされている Redis またはオンプレミスの自己ホスト型 Redis から ElastiCache for Redis へのデータ移行のために設計されており、ElastiCache for Redis クラスター間でのものではありません。

Amazon Data Firehose は、以前は Amazon Kinesis Data Firehose として知られていました 翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon データFirehose によるアクセス制御 以下のセクションでは、Amazon Data Firehose リソースとの間のアクセスを制御する方法について説明します。対象となる情報には、Firehose ストリームにデータを送信できるようにアプリケーションにアクセス権を付与する方法が含まれます。また、Amazon Data Firehose に Amazon Simple Storage Service (Amazon S3) バケット、Amazon Redshift クラスター、または Amazon OpenSear

Athena では、高度にパーティションされたテーブルのクエリ処理を高速化し、パーティション管理を自動化するためにパーティション射影を使用できます。 パーティション射影では、Athena は AWS Glue のテーブルに直接設定したテーブルプロパティを使用してパーティション値と場所を計算します。テーブルプロパティにより、Athena は AWS Glue Data Catalogで時間をかけてメタデータを検索しなくても、必要なパーティション情報を「射影」または決定できます。多くの場合、インメモリオペレーションはリモートオペレーションよりも高速であるため、パーティション射影は高度にパーティションされたテーブルに対するクエリの実行時間を短縮できます。クエリおよび基盤となるデータの特定の特性によっては、パーティション射影によって、パーティションメタデータの取得時に制限されているクエリのクエリラ

This section provides best practices for modeling relational data in Amazon DynamoDB. First, we introduce traditional data modeling concepts. Then, we describe the advantages of using DynamoDB over traditional relational database management systems—how it eliminates the need for JOIN operations and reduces overhead. We then explain how to design a DynamoDB table that scales efficiently. Finally, w

フェイルオーバーが発生した場合に Aurora PostgreSQL クラスター内の書き込み DB インスタンスを迅速にリカバリするには、Amazon Aurora PostgreSQL のクラスターキャッシュ管理を使用します。クラスターキャッシュ管理を使用することで、フェイルオーバー発生時でもアプリケーションパフォーマンスを維持することができます。 一般的なフェイルオーバーが発生した場合、フェイルオーバー後に一時的だがパフォーマンスが大幅に低下することがあります。この低下は、フェイルオーバー DB インスタンスの起動時にバッファキャッシュが空になることが原因で発生します。空のキャッシュは、コールドキャッシュとも呼ばれます。コールドキャッシュでは、DB インスタンスは、低速のディスクから読み取る必要があるため、パフォーマンスが低下します。バッファキャッシュに格納されている値は使用されません