CloudFront エッジキャッシュにオブジェクトを保持する時間の指定（有効期限切れ） - Amazon CloudFront
CloudFront が別のリクエストをオリジンに転送するまでにファイルを CloudFront キャッシュに保持する期間を制御できます。この期間を短くすると、動的なコンテンツを供給できます。この期間を長くすると、ユーザー側のパフォーマンスは向上します。ファイルがエッジキャッシュから直接返される可能性が高くなるためです。期間を長くすると、オリジンの負荷も軽減されます。 一般的に CloudFront は、指定したキャッシュ保持期間が経過するまで、つまりファイルの有効期限が切れるまでエッジロケーションからファイルを提供します。ファイルの有効期限が切れると、エッジロケーションがファイルのリクエストを次に受け取ったときに、CloudFront は、リクエストをオリジンに転送し、キャッシュにファイルの最新バージョンが含まれていることを確認します。オリジンからのレスポンスは、ファイルが変更されたかど
IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management
AWS Identity and Access Management ベストプラクティスは 2022 年 7 月 14 日に更新されました。 AWS のリソースを保護するには、AWS Identity and Access Management (IAM) を使用する際の以下のベストプラクティスに従ってください。 人間のユーザーが一時的な認証情報を使用して AWS にアクセスする場合に ID プロバイダーとのフェデレーションを使用することを必須とする 人間のユーザーとは、別名人間 ID と呼ばれ、人、管理者、デベロッパー、オペレーター、およびアプリケーションのコンシューマーを指します。人間のユーザーは AWS の環境とアプリケーションにアクセスするための ID を持っている必要があります。組織のメンバーである人間のユーザーは、ワークフォースアイデンティティとも呼ばれます。人間のユーザーには
Amazon RDS DB インスタンスを変更する - Amazon Relational Database Service
ストレージの追加や DB インスタンスクラスの変更などのタスクを完了するために、DB インスタンスの設定を変更できます。このトピックでは、Amazon RDS DB インスタンスを変更する方法と、DB インスタンスの設定について説明します。 本稼働インスタンスの修正前に、各変更の影響を完全に把握できるように、テストインスタンスでの変更のテストをお勧めします。これにより、各変更の影響を完全に理解できます。このようなテストは特に、データベースのバージョンをアップグレードするときに重要です。 DB インスタンスに対するほとんどの変更は、すぐに適用することも、次のメンテナンスウィンドウまで延期することもできます。一部の変更 (パラメータグループの変更など) を適用するには、手動による DB インスタンスの再起動が必要になる場合があります。 また、一部の変更を適用するために Amazon RDS で
Amazon SESとは？ - Amazon Simple Email Service
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon SESとは？ Amazon Simple Email Service (Amazon SES) は、ユーザー自身の E メールアドレスとドメインを使用して E メールを送受信するための、簡単でコスト効率の高い方法を提供する E メールプラットフォームです。 例えば、特価販売などのマーケティング E メールや、注文確認などの取引 E メール、ニュースレターなどのその他のタイプの通信文の送信に使用できます。Amazon SES を使用してメールを受信するときは、E メール自動応答システム、E メール登録解除システム、受信 E メールからカスタマーサポートのチケットを生成するアプリケーションなどのソフトウェアソリューションを開発できます。 Amazon SE
バーストパフォーマンスインスタンス - Amazon Elastic Compute Cloud
多くの汎用ワークロードでは、平均的な状態はビジーではないので、持続的で高いレベルの CPU パフォーマンスを必要としません。以下のグラフは、現在 AWS クラウドのお客様が実行している多くの一般的なワークロードにおける、CPU の使用率を示しています。 これらの CPU 使用率が低～中程度のワークロードが、CPU サイクルを浪費するような場合には、使用量以上の料金が発生することになります。こういった問題に対処するには、低コストのバースト汎用インスタンス (T インスタンス) を活用します。 T インスタンスファミリーは、ベースラインの CPU パフォーマンスを提供しながら、いつでも必要な時間だけ、能力をベースライン以上にバーストさせる機能を備えています。ベースライン CPU は汎用ワークロードにおける大部分のニーズを満たすように構成されており、大規模なマイクロサービス、ウェブサーバー、中小
Amazon EBS 最適化インスタンスを使用する - Amazon Elastic Compute Cloud
Amazon EBS 最適化インスタンスは、最適化された設定スタックを使用し、Amazon EBS I/O 用に専用のキャパシティを追加で提供します。このように最適化することで、Amazon EBS I/O と、インスタンスからのその他のトラフィックとの間の競合を最小に抑え、EBS ボリュームの最高のパフォーマンスを実現します。 EBS 最適化インスタンスは、Amazon EBS 用に専用の帯域幅を用意します。汎用 SSD (gp2 および gp3) ボリュームを EBS 最適化インスタンスにアタッチすると、1 年で 99% の期間、プロビジョンド IOPS パフォーマンスの少なくとも 90% のボリュームが提供されます。また、プロビジョンド IOPS SSD (io1 および io2) ボリュームでは、1 年で 99.9% の期間、プロビジョンド IOPS パフォーマンスの少なくとも 9
インスタンスのステータスチェック - Amazon Elastic Compute Cloud
インスタンスのステータスのモニタリングでは、インスタンスによるアプリケーションの実行を妨げる可能性のある問題をAmazon EC2 が検出したかどうかをすばやく判断できます。Amazon EC2 は、稼働中のすべての EC2 インスタンスに対して自動チェックを実行して、ハードウェアおよびソフトウェアの問題を特定します。これらのステータスチェックの結果を表示して、具体的で検出可能な問題を識別できます。このイベントステータスデータは、各インスタンス (pending、running、stopping) の状態に関して Amazon EC2 が既に提供している情報と、Amazon CloudWatch が監視している使用状況メトリクス (CPU 使用率、ネットワークトラフィック、ディスクアクティビティ) を補足するものです。 ステータスチェックは 1 分ごとに実行され、それぞれ成功または失敗のス
Amazon S3 のポリシーとアクセス許可 - Amazon Simple Storage Service
ここでは、Amazon S3 のバケットポリシーとユーザーポリシーの概要を示し、ポリシーの基本的なエレメントについて説明します。リストされた各エレメントは、そのエレメントの詳細と使用方法の例にリンクしています。 Amazon S3 アクションの完全なリストについては、「サービス認証リファレンス」の「Amazon S3 のアクション、リソース、および条件キー」を参照してください。 基本的に、ポリシーには以下のエレメントが含まれます。 リソース — ポリシーが適用される Amazon S3 バケット、オブジェクト、アクセスポイント、またはジョブ。バケット、オブジェクト、アクセスポイント、またはジョブの Amazon リソースネーム (ARN) を使用してリソースを識別します。 バケットレベルのオペレーションの例: - "Resource": "arn:aws:s3:::bucket_name"
IAM JSON ポリシー要素のリファレンス - AWS Identity and Access Management
JSON ポリシードキュメントは要素で構成されます。要素は、ポリシーで使用する一般的な順番で記載されています。要素の順番は重要ではありません (たとえば、Resource 要素を Action 要素の前にもってくることなどが可能です)。ポリシーで、あらゆる Condition 要素も特定する必要はありません。JSON ポリシードキュメントの全体構造と目的については「JSON ポリシー概要」をご覧ください。 一部の JSON ポリシーの要素は相互排他的です。つまり、両方を使用するポリシーを作成することはできません。たとえば、Action と NotAction を同じポリシーステートメントで使用することはできません。相互排他的な他のペアには Principal/NotPrincipal や Resource/NotResource があります。 ポリシーに取り入れる詳細は各サービスによって異
特定の AWS アカウントとの AMI の共有 - Amazon Elastic Compute Cloud
AMI を公開せず、特定の AWS アカウント とだけ共有することもできます。これに必要なものは AWS アカウント ID のみです。 AWS アカウント ID は、AWS アカウント を一意に識別する 12 桁の数値です (012345678901 など)。詳細については、AWS Account Management リファレンスガイドの「AWS アカウント 識別子の表示」を参照してください。 考慮事項 特定の AWS アカウント で AMI を共有する場合は、以下について検討してください。 所有権 — AMI を共有するには、お客様の AWS アカウント がその AMI を所有している必要があります。 共有制限 – リージョン内で AMI を共有できるエンティティの最大数については、「Amazon EC2 Service Quotas」をご覧ください。 タグ - ユーザー定義タグ (A
Linux で Amazon EBS ボリュームを使用できるようにする - Amazon Elastic Compute Cloud
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon EBS ボリュームを使用できるようにする Amazon EBS ボリュームをインスタンスにアタッチすると、ブロックデバイスとして公開されます。任意のファイルシステムでボリュームをフォーマットし、マウントできます。EBS ボリュームを使用できるようにすると、他のボリュームと同じようにアクセスできます。このファイルシステムに書き込まれるデータはすべて EBS ボリュームに書き込まれますが、デバイスを使用するアプリケーションには透過的になります。 EBS ボリュームのスナップショットは、バックアップ目的で作成したり、別のボリュームを作成する際のベースラインとして使用したりできます。詳細については、「Amazon EBS スナップショット」を参照してください。
AWS サービスクォータ - AWS 全般のリファレンス
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 AWS サービスクォータ AWS アカウントには、各 AWS サービスについて、以前は制限と呼ばれていたデフォルトのクォータがあります。特に明記されていない限り、クォータは地域固有です。一部のクォータの引き上げをリクエストできますが、すべてのクォータを増やすことはできません。 サービスクォータを表示するには サービスクォータは、次のオプションを使用して表示できます。 ドキュメントから: ドキュメントのサービスエンドポイントとクォータページを開き、サービス名を検索し、リンクをクリックしてそのサービスのページに移動します。ページを切り替えずにドキュメント内のすべての AWS サービスのサービスクォータを表示するには、PDF サービスエンドポイントとクォータページで情報を
IAM と AWS STSクォータ - AWS Identity and Access Management
IAM の使用状況とクォータに関するアカウントレベルの情報を取得するには、GetAccountSummary API オペレーション、または get-account-summary AWS CLI コマンドを使用します。 ポリシードキュメントには、次の Unicode 文字のみを含めることができます。水平タブ (U+0009)、ラインフィード (U+000A)、キャリッジリターン (U+000D)、および U+0020～U+00FF の範囲内の文字。 ユーザー、グループ、ロール、ポリシー、インスタンスプロファイル、サーバー証明書、およびパスの名前は、英数字で指定する必要があります。これには、プラス記号 (+)、等号 (=)、カンマ (,)、ピリオド (.)、アットマーク (＠)、アンダースコア (_)、ハイフン (-) も含まれます。パス名の前後にはスラッシュ (/) を指定する必要があり
Elastic Load Balancing とは? - Elastic Load Balancing
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Elastic Load Balancing とは? Elastic Load Balancing は、受信したトラフィックを複数のアベイラビリティーゾーンの複数のターゲット (EC2 インスタンス、コンテナ、IP アドレスなど) に自動的に分散させます。登録されているターゲットの状態をモニタリングし、正常なターゲットにのみトラフィックをルーティングします。Elastic Load Balancing は、着信トラフィックの変化に応じて、自動的にロードバランサーの容量を拡張します。 ロードバランサーの利点 ロードバランサーは、ワークロードを仮想サーバーなど複数のコンピューティングリソース間に分散させます。ロードバランサーを使用すると、アプリケーションの可用性と耐障害
AWS サービスエンドポイント - AWS 全般のリファレンス
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 AWS サービスエンドポイント AWS サービスにプログラムで接続するには、 エンドポイントを使用します。エンドポイントは、 AWS ウェブサービスのエントリポイントの URL です。 AWS SDKs と AWS Command Line Interface （AWS CLI) は、 AWS リージョン内の各サービスのデフォルトのエンドポイントを自動的に使用します。ただし、API リクエストの代替エンドポイントを指定できます。 サービスでリージョンがサポートされている場合、各リージョンのリソースは他のリージョンの類似したリソースから独立しています。たとえば、1 つのリージョンで Amazon EC2 インスタンスまたは Amazon SQS キューを作成できます。
Amazon Route 53 を既存ドメインの DNS サービスとして使用する - Amazon Route 53
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon Route 53 を既存ドメインの DNS サービスとして使用する 1 つまたは複数のドメイン登録を Route 53 に移管していて、現在有料の DNS サービスを提供していないドメインレジストラを使用している場合は、ドメインを移行する前に DNS サービスを移行する必要があります。そうしないと、レジストラはドメインの移行時に DNS サービスの提供を停止し、関連するウェブサイトやウェブアプリケーションはインターネット上で使用できなくなります。(現在のレジストラから別の DNS サービスプロバイダーに DNS サービスを移管することもできます。 Route 53 に登録されているドメインの DNS サービスプロバイダとして、Route 53 の使用は
Amazon EC2 インスタンスストア - Amazon Elastic Compute Cloud
インスタンスストアは、インスタンス用のブロックレベルの一時ストレージを提供します。このストレージは、ホストコンピュータに物理的にアタッチされたディスク上にあります。インスタンスストアは、バッファ、キャッシュ、スクラッチデータ、その他の一時的データのように頻繁に変化する情報の一時的なストレージに最適です。また、負荷分散されたウェブサーバーのプールなど、インスタンスのフリート全体で複製する一時データを保存するためにも使用できます。 インスタンスストアは、ブロックデバイスとして表示される 1 つ以上のインスタンスストアボリュームで構成されます。インスタンスストアのサイズと、利用可能なデバイスの数は、インスタンスタイプおよびインスタンスサイズによって異なります。詳細については、「インスタンスストアボリューム」を参照してください。 インスタンスストアボリュームの仮想デバイスは ephemeral[0
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DynamoDB を使用した設計とアーキテクチャの設計に関するベストプラクティス - Amazon DynamoDB
MySQL データベースのログファイル - Amazon Relational Database Service
Amazon VPC クォータ - Amazon Virtual Private Cloud