Preparing for Amazon Aurora MySQL-Compatible Edition version 2 end of Standard Support - Amazon Aurora
Preparing for Amazon Aurora MySQL-Compatible Edition version 2 end of Standard Support Amazon Aurora MySQL-Compatible Edition version 2 (with MySQL 5.7 compatibility) is planned to reach end of Standard Support on October 31, 2024. Amazon advises that you upgrade all clusters running Aurora MySQL version 2 to the default Aurora MySQL version 3 (with MySQL 8.0 compatibility) or higher before Aurora
DB インスタンスのメンテナンス - Amazon Relational Database Service
Amazon RDS では、Amazon RDS リソースのメンテナンスを定期的に実行します。メンテナンスでは、ほとんどの場合、DB インスタンスの以下のリソースの更新が行われます。 通常、オペレーティングシステムのアップデートはセキュリティ問題に関連しています。できるだけ早く実行する必要があります。 一部のメンテナンス項目では、Amazon RDS が DB インスタンスを少しの間オフラインにする必要があります。リソースをオフラインにする必要があるメンテナンス項目には、必要なオペレーティングシステムやデータベースのパッチが含まれます。セキュリティやインスタンスの信頼性に関連するパッチのみ、必須のパッチ適用として自動的にスケジューリングされます。そのようなパッチ適用はまれであり、通常は数か月に一度です。メンテナンスウィンドウのごくわずかしか必要としないことがほとんどです。 すぐに適用しない
AWS SDK for PHP バージョン 3 での Amazon S3 ストリームラッパー - AWS SDK for PHP
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 AWS SDK for PHP バージョン 3 での Amazon S3 ストリームラッパー Amazon S3 ストリームラッパーにより、組み込み PHP 関数 file_get_contents、fopen、copy、rename、unlink、mkdir、rmdir などを使用して Amazon S3 に対してデータの保存および取得ができます。 使用するために Amazon S3 ストリームラッパーを登録する必要があります。 $client = new Aws\S3\S3Client([/** options **/]); // Register the stream wrapper from an S3Client object $client->regis
Amazon Aurora MySQL のパフォーマンスとスケーリングの管理 - Amazon Aurora
Aurora MySQL DB インスタンスのスケーリング Aurora MySQL DB インスタンスは、インスタンススケーリングと読み取りスケーリングの 2 つの方法でスケールできます。読み取りスケーリングの詳細については、「読み取りのスケーリング」を参照してください。 DB クラスター内の各 DB インスタンスの DB インスタンスクラスを変更することで、Aurora MySQL DB クラスターをスケーリングできます。Aurora MySQL は、Aurora 用に最適化された複数の DB インスタンスクラスをサポートしています サイズが 40 TB より大きい Aurora クラスターには、db.t2 または db.t3 インスタンスクラスを使用しないでください。Aurora MySQL でサポートされている DB インスタンスクラスの詳細な仕様については、「Aurora DB
DB クラスタースナップショットの作成 - Amazon Aurora
Amazon RDS は DB クラスターのストレージボリュームのスナップショットを作成し、個々のデータベースだけではなく、その DB クラスター全体をバックアップします。DB クラスターを作成したら、バックアップする DB クラスターを特定してから、DB クラスターに名前を付けて後で復元できるようにする必要があります。DB クラスタースナップショットを作成するためにかかる時間は、データベースのサイズによって異なります。スナップショットにはストレージボリューム全体が含まれているため、一時ファイルなどのファイルのサイズも、スナップショットを作成するための時間に影響します。 自動バックアップとは異なり、手動スナップショットはバックアップ保持期間の影響を受けません。スナップショットは期限切れになりません。 非常に長期間のバックアップの場合、スナップショットデータを Amazon S3 にエクスポ
Two-Pizza Teams - Introduction to DevOps on AWS
"We try to create teams that are no larger than can be fed by two pizzas," said Bezos. "We call that the two-pizza team rule." The smaller the team, the better the collaboration. Collaboration is very important, as software releases are moving faster than ever. And a team’s ability to deliver the software can be a differentiating factor for your organization against your competition. Imagine a sit
ストレージ転送と使用量のリクエスタ支払いバケットの使用 - Amazon Simple Storage Service
一般に、Amazon S3 のバケットのストレージおよびデータ転送にかかるコストはすべて、そのバケット所有者が負担します。ただし、バケットをリクエスタ支払いバケットに設定することはできます。リクエスタ支払いバケットの場合、リクエストおよびバケットからのデータのダウンロードにかかるコストは、所有者でなくリクエストを実行したリクエスタが支払います。データの保管にかかるコストは常にバケット所有者が支払います。 通常は、データを共有したいが、他者がデータにアクセスする際に発生する費用を負担したくない場合に、リクエスタ支払いバケットをバケットに設定します。例えば、郵便番号リスト、参照データ、地理空間情報、ウェブクロールデータといった、大規模なデータセットを利用できるようにする際にリクエスタ支払いバケットを設定することができます。 リクエスタ支払いバケットに関するリクエストはすべて認証する必要がありま
API Gateway で Lambda エラーを処理する - Amazon API Gateway
Lambda カスタム統合の場合、統合レスポンスで Lambda によって返されたエラーを、クライアントの標準 HTTP エラーレスポンスにマップする必要があります。そうしないと、Lambda のエラーはデフォルトで 200 OK レスポンスとして返されるため、API ユーザーは直感的に理解できません。 Lambda から返されるエラーには、標準エラーとカスタムエラーの 2 種類があります。API では、これらを異なる方法で処理する必要があります。 Lambda プロキシ統合では、Lambda は次の形式で出力を返す必要があります。 { "isBase64Encoded" : "boolean", "statusCode": "number", "headers": { ... }, "body": "JSON string" }この出力で、通常、statusCode の 4XX はクライ
AWS の ABAC とは - AWS Identity and Access Management
属性ベースのアクセスコントロール (ABAC) は、属性に基づいて権限を定義する認可戦略です。これらの属性は、AWS でタグと呼ばれています。タグは、IAM エンティティ (ユーザーまたはロール) を含めた IAM リソース、および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または少数のポリシーのセットを作成できます。これらの ABAC ポリシーは、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。ATBAC は、急成長する環境や、ポリシー管理が煩雑になる状況で役に立ちます。 例えば、access-project タグキーを使用して 3 つのロールを作成できます。最初のロールのタグ値を Heart、2 番目を Star、3 番目を Lightning に設定します。そうすることで、access-p
署名付き URL と署名付き Cookie を作成できる署名者の指定 - Amazon CloudFront
署名付き URL または署名付き Cookie を作成するには、署名者が必要です。署名者は、CloudFront で作成した信頼されたキーグループ、または CloudFront のキーペアを含む AWS アカウントのいずれかです。署名付き URL と署名付き Cookie が有効な信頼されたキーグループを使用することをお勧めします。詳細については、「信頼されたキーグループ (推奨) と AWS アカウントのいずれかの選択」を参照してください。 署名者には 2 つの目的があります。 署名者をディストリビューションに追加するとすぐに、ビューワーからファイルへのアクセスには、署名付き URL または署名付き Cookie の使用が CloudFront によって求められるようになります。 署名付き URL または署名付き Cookie を作成するときは、署名者のキーペアのプライベートキーを使用し
IAM: IAM ユーザーに MFA デバイスの自己管理を許可する - AWS Identity and Access Management
この例は、IAM ユーザーが多要素認証 (MFA) デバイスを自己管理することを許可する ID ベースのポリシーの作成方法を示しています。このポリシーでは、AWS API または AWS CLI から、このアクションをプログラムで完了するために必要なアクセス権を許可します。 このポリシーを設定した IAM ユーザーが MFA 認証されていない場合、このポリシーは、MFA を使用した認証に必要なアクションを除いて、すべての AWS アクションへのアクセスを拒否します。AWS にサインインしているユーザーにこれらのアクセス許可を追加する場合、これらの変更を確認するには、サインアウトしてからサインインする必要がある場合があります。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowListActions", "Effect": "A
Set up Lambda proxy integrations in API Gateway - Amazon API Gateway
Understand API Gateway Lambda proxy integration Amazon API Gateway Lambda proxy integration is a simple, powerful, and nimble mechanism to build an API with a setup of a single API method. The Lambda proxy integration allows the client to call a single Lambda function in the backend. The function accesses many resources or features of other AWS services, including calling other Lambda functions. I
Application Load Balancer の設定 - AWS Elastic Beanstalk
ロードバランシングを有効にしている場合、AWS Elastic Beanstalk 環境には環境内のインスタンス間にトラフィックを分散する Elastic Load Balancing ロードバランサーが用意されています。Elastic Load Balancing は、いくつかのロードバランサータイプをサポートしています。それらについては、Elastic Load Balancing ユーザーガイドを参照してください。Elastic Beanstalk では、ロードバランサーを作成したり、作成した共有ロードバランサーを指定したりできます。 このトピックでは、Elastic Beanstalk が作成し、環境専用にする Application Load Balancer の設定について説明します。「共有 Application Load Balancer の設定」も参照してください。Ela
CloudWatch Logs Insights Query Syntax - Amazon CloudWatch Logs
CloudWatch Logs Insights では、クエリ言語を使用してロググループに対するクエリの実行します。クエリ構文は、一般的な関数、算術演算と比較演算、正規表現など、さまざまな関数とオペレーションをサポートしています。 複数のコマンドを含むクエリを作成するときは、コマンドをパイプ文字 (|) で区切ります。 コメントを含むクエリを作成するときは、コメントをハッシュ文字 (#) で区切ります。 CloudWatch Logs Insights は、さまざまなログタイプのフィールドを自動で検出し、@ 文字で始まるフィールドを生成します。これらのフィールドの詳細については、「Amazon CloudWatch ユーザーガイド」の「サポートされるログと検出されるフィールド」を参照してください。
バインドマウント - Amazon Elastic Container Service
バインドマウントでは、ホスト (Amazon EC2 インスタンスや AWS Fargate など) 上のファイルまたはディレクトリがコンテナにマウントされます。バインドマウントは、Fargate インスタンスと Amazon EC2 インスタンスの両方でホストされているタスクでサポートされています。デフォルトではバインドマウントは、それらを使用しているコンテナのライフサイクルに紐付けられています。タスクが停止するなど、バインドマウントを使用するすべてのコンテナが停止すると、データが削除されます。Amazon EC2 インスタンスでホストされているタスクの場合、タスク定義で host 値とオプションの sourcePath 値を指定することにより、データをホスト Amazon EC2 インスタンスのライフサイクルに紐付けすることができます。詳細については、Docker ドキュメントの 「バ
Amazon EC2 Auto Scaling ライフサイクルフック - Amazon EC2 Auto Scaling (日本語)
Amazon EC2 Auto Scaling は、Auto Scaling グループにライフサイクルフックを追加する機能を提供します。これらのフックにより、Auto Scaling インスタンスライフサイクルのイベントを認識し、対応するライフサイクルイベントが発生したときにカスタムアクションを実行するソリューションを作成できます。ライフサイクルフックでは、インスタンスが次の状態に移行する前に、ライフサイクルアクションの完了を待つ時間 (デフォルトでは 1 時間) が指定されます。 Auto Scaling インスタンスでライフサイクルフックを使用する例として、以下を実行します。 スケールアウト イベントが発生すると、新しく起動したインスタンスはスタートアップ シーケンスを完了し、待機状態に移行します。インスタンスが待機状態の間に、アプリケーションに必要なソフトウェアパッケージをダウンロー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon RDS DB インスタンス - Amazon Relational Database Service
Permissions - AWS Cloud Development Kit (AWS CDK) v2
https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/step-functions-dg.pdf
AWS クラウドでの Linux 踏み台ホスト