Open47

AWS☁️

日常のアウトプット日常のアウトプット

cat ~/.aws/config
→AWS CLIの設定確認

  • どのAWSリージョンを使う設定になっているか
  • 複数のプロファイルが設定されているかどうか
  • デフォルトの出力形式(JSONやtableなど)が何か
日常のアウトプット日常のアウトプット

CloudFormationとは
AWSリソース(EC2, S3, RDS, VPC等)をコードで定義して自動作成、管理するサービス

  • Template: YAML or JSON形式でAWSリソースの構成を記述するリソース構成の設計図
  • スタック: 上記のTemplateを元に作成されたAWSリソース群
    • スタック単位で作成、構成、削除が可能

<使用するメリット>
⭕️インフラのコード化
⭕️リソース管理の効率化
→スタック単位でリソースをまとめて作成・更新・削除可能
⭕️スタックの追跡

日常のアウトプット日常のアウトプット

AWS CloudTrail:APIの使用状況を追跡、AWSマネジメントコンソールやAWS SDKからのリクエストをキャプチャし、アカウントのリソースに対する変更ログを残す
AWS CloudWatch:リソースの状態を監視可能だが、ユーザーアクションを記録することはできない
Amazon Simple Notification Service:CloudWatchアラートがトリガーされた際に、SNSを使用して通知を受けることができる
✉️メールやモバイルプッシュ通知、SMS、AWSLambda関数の実行などによる通知可能

日常のアウトプット日常のアウトプット

AWSで受けられるサービス

  • AWSプロフェッショナルサービス:クラウドの移行やソリューション設計などに関して、有料でコンサルやプロフェッショナルなサービスを提供している
  • AWSエンタープライズサポート:24時間365日技術支援を提供するサポートプラン
日常のアウトプット日常のアウトプット

AWSのDBサービス

  • RDS:リレーショナルDBを簡単にセットアップ、運用、スケーリングするためのマネージドサービス
  • Redshift:データウェハウスサービスであり、大規模なデータ分析に最適
  • DynamoDB:NoSQLデータベースサービスであり、キーと値のペアによる高速なデータアクセスに最適
  • Aurora:MySQL,PostgreSQLの両方互換のクラウドネイティブなリレーショナルデータベースエンジンで、従来のアプリケーションを移行したり、新しいインターネット向けアプリケーション構築したりするのに適している(簡単にスケーリングできる)
日常のアウトプット日常のアウトプット

AWS Batchとは
バッチ処理の分散に向いている!
複数のインスタンスにジョブを自動的に分散することができる🔀

日常のアウトプット日常のアウトプット

Amazon Macie(メイシー)とは
機械学習とパターンマッチングして機密データを発見し、データセキュリティのリスクを可視化して、そのリスクに対する自動的な制御を行う

  • 機密データの検出:名前、住所、クレジットカード番号などの個人を特定できる情報を含む機密データを自動検出
  • データセキュリティリスクの可視化:S3に保存したデータのセキュリティとプライバシーを可視化
  • 自動保護
日常のアウトプット日常のアウトプット

ユーザーからの音声ベースの入力を受け付け、結果を音声で伝え場合のおすすめソリューション✨
❶Amazon Transcribe:音声をテキストに変換するサービス
❷Amazon Polly:テキストを自然な音声に変換するサービス
→Amazon Transcribeを使用して音声をテキストに変換し、Amazon Pollyを使用してテキスト結果を音声で伝える

日常のアウトプット日常のアウトプット

常に変化するデータの読み取り/書き込みにおいて

  • RDS:データの変更に応じて柔軟にデータの読み書きが可能
  • Amazon EFS(Elastic File System):クラウド上の拡張性の高いファイルストレージを提供するサービスで、複数のEC2インスタンスからデータの読み書きが可能
日常のアウトプット日常のアウトプット
  • S3:低コスト、高耐久性、高い可用性を備えたオブジェクトストレージサービス
    →DBのバックアップを保存でき、すぐに取得することが可能
  • Glacier:アーカイブ用のストレージ、データ取得に時間がかかる
  • EBS:仮想ハードドライブで、バックアップ用途に適していない
  • EC2インスタンスストア:一時的に付与されるストレージ、永続的なバックアップの保存は向いていない
日常のアウトプット日常のアウトプット

新しいアプリケーションをデプロイする際にリージョンを選択する要因として、顧客の決定に影響を与える可能性

  • アプリケーションのレスポンス:レスポンス時間は、ユーザー体験に直接影響を与えるため、デプロイするリージョンの選択において非常に重要
    ⭕️ユーザーに近いリージョンを選択することで、ネットワーク遅延を最小限に抑制することができる
  • 利用可能なサービスの種類:各リージョンで利用可能なAWSサービスが異なるため、特的のサービスが利用可能なリージョンを選択することが、アプリケーションの機能やパフォーマンスに大きな影響を与えることがある
日常のアウトプット日常のアウトプット

Amazon EC2インスタンスの割引オプション

  • スポットインスタンス:AWSのEC2インスタンスの余剰能力を利用することで、従来のオンデマンドインスタンスに対して、最大90%の割引価格がある
    Amazon EC2の未使用コンピューティング能力を利用するものであり、需要と供給に基づいて価格が変動するため、需要が高ければ価格も高くなり、需要が低ければ価格も低くなる

  • リザーブドインスタンス:長期コミットメント(1~3年)に対して割引が提供されるが、最大75%が限度

  • オンデマンド:従量課金制のため、割引なし

日常のアウトプット日常のアウトプット

ロードバランサー (ELB):
トラフィックを複数のEC2インスタンスに振り分けて、各インスタンスの負荷を均一化
たとえば、リクエストが100件あれば、それを4台のインスタンスに25件ずつ分散するイメージ
EC2インスタンスの数が固定されている場合でも動作します。

Auto Scaling:
トラフィックの状況に応じて、EC2インスタンスの数を動的に増減させる
例えば、トラフィックが増加すれば、新しいEC2インスタンスを自動的に追加し、トラフィックが減少すれば、余分なインスタンスを削除する

日常のアウトプット日常のアウトプット

CloudFrontを使用することで、EC2インスタンスへの直接アクセスを減らすことが可能になる

キャッシュによる負荷軽減
CloudFrontはコンテンツデリバリネットワーク (CDN) の一種で、エンドユーザーに近いエッジロケーションでコンテンツをキャッシュする
ユーザーが同じリソース(例えば静的なHTML、画像、CSS、JavaScriptなど)にアクセスすると、CloudFrontはキャッシュされたデータを返す
→バックエンド(EC2インスタンスやS3バケット)へのリクエスト数が減少し、負荷が軽減される

読み取り専用のユースケースに適している
頻繁に変更されない静的コンテンツ(画像、スタイルシート、ドキュメントなど)は、CloudFrontがキャッシュして効率的に配信可能
例えば、ニュースサイトやブログのように、多くのユーザーが同じコンテンツを読み取る場合、CloudFrontが最適

  • CloudFrontが適さない場合
    動的コンテンツ
    動的に生成されるデータ(例: ユーザーごとに異なるダッシュボード)にはキャッシュが効果的でない場合がある
    ただし、CloudFrontには動的コンテンツのプロキシ機能があり、EC2インスタンスとエンドユーザー間の通信を最適化できる
    頻繁に更新されるデータ
    例えば、リアルタイムで変更されるAPIのレスポンスや、キャッシュが不適切な場面ではCloudFrontは適切ではない
日常のアウトプット日常のアウトプット

責任今日中モデルの下で、顧客とAWSの間で共有されるもの

パッチ管理
AWSにおけるパッチ適用のポリシーはサービスによって異なる
顧客責任:EC2のようなコンピューティングサービス
AWS責任:S3のようなマネージドサービス

日常のアウトプット日常のアウトプット

AWS Direct Connect:企業のデータセンターとVPCを専用ネットワークで接続できサービス
AWS VPN:インターネットを経由してVPCに接続するサービスで、Direct Connectのような専用ネットワークではない

日常のアウトプット日常のアウトプット

AWSのセキュリティとコンプライアンスの責任共有モデルについて

AWSのセキュリティとコンプライアンスの責任共有モデルでは、AWSと顧客がそれぞれ異なる責任範囲を持っています。質問の中で「Amazon EC2ホストファームウェアの更新」がAWSの責任に該当する理由を具体的に解説します。

責任共有モデルの基本
AWSが責任を持つ部分(セキュリティ "of" the cloud):

AWSが提供するインフラストラクチャ(データセンター、ネットワーク、物理ハードウェア)のセキュリティ。
これには、ハードウェアやホストファームウェアの更新が含まれます。
顧客が責任を持つ部分(セキュリティ "in" the cloud):

AWS上で稼働するシステムやアプリケーションの管理。
これには、オペレーティングシステムやアプリケーション設定、データ暗号化、アクセス管理などが含まれます。
Amazon EC2ホストファームウェアの更新
ホストファームウェアとは:

EC2インスタンスを実行するための物理サーバーに組み込まれている低レベルのソフトウェア。
例: BIOSやベースバンド管理コントローラ (BMC) など。
これらのソフトウェアは、ハードウェアの基本動作やセキュリティを確保します。
AWSが担当する理由:

EC2インスタンスはAWSの物理サーバー上で動作します。この物理サーバーのハードウェアとファームウェアの管理はAWSが一元的に行い、顧客が手動で操作する必要はありません。
ホストファームウェアの更新作業には以下が含まれます:
セキュリティパッチの適用。
ハードウェアの脆弱性(例: SpectreやMeltdown)の修正。
パフォーマンス改善や信頼性向上のためのアップデート。
他の選択肢が顧客の責任となる理由
個人およびサービスへのアクセスの許可:

IAM(Identity and Access Management)を使ってアクセス制御を設定するのは顧客の責任です。
例: ユーザーやサービスがAWSリソースにアクセスするためのポリシー設定。
転送中のデータの暗号化:

顧客がTLS証明書や暗号化プロトコルを設定する必要があります。
例: EC2インスタンスで動作するアプリケーション間の暗号化通信。
オペレーティングシステムの更新:

EC2インスタンスの中で動作するOSは顧客が管理します。
例: UbuntuやAmazon Linuxのアップデート。
具体例
AWSの責任(ホストファームウェア更新):

AWSはデータセンター内の物理ホストを定期的にアップデートします。
これにより、EC2インスタンスのパフォーマンスやセキュリティが向上します。
顧客の責任(OS更新):

もし顧客がUbuntuをインスタンスにインストールしている場合、セキュリティパッチやOSアップデートは顧客が行います。
まとめ
「Amazon EC2ホストファームウェアの更新」がAWSの責任である理由は、これは物理インフラストラクチャの一部であり、AWSがその管理を行うことで顧客が直接触れる必要がないからです。逆に、OSの更新やアクセス管理などのタスクは、AWSのクラウドを利用している顧客の環境の管理に該当し、顧客の責任となります。

日常のアウトプット日常のアウトプット

aws configure sso の役割

AWS CLIでSSOを使用できるように設定するコマンド
このコマンドでアカウントの設定を行うことで、
AWS CLIが認証情報を取得するために必要なSSOプロファイルを作成する!

上記の設定により、

aws sso login --profile <設定したSSO session name>

SSOプロファイルでログインし、有効な認証トークンを取得することができるようになる

日常のアウトプット日常のアウトプット

AWS Security Token Service(AWS STS)

信頼できるユーザーに一時的なセキュリティ認証情報を作成、提供し、AWSリソースへにアクセスを制御するためのサービス

AWS Artifact

日常のアウトプット日常のアウトプット

AWS CloudTrail

ユーザーのアクティビティログを取得することができるログ監視サービス
ユーザー、ロール、または AWS のサービスによって実行されたアクションは、CloudTrail にイベントとして記録される!
イベントには、AWS マネジメントコンソール、AWS CLI、および AWS SDK と API で実行されたアクションが含まれる。

日常のアウトプット日常のアウトプット

Amazon EFS

EC2インスタンスからLAN上にあるNASのように利用可能な共有ファイルストレージを提供するサービス
複数のEC2インスタンスから接続可能なストレージとして機能する
S3とは異なり、インターネットから直接のアクセスができないストレージ
※EBSもインターネットから直接のアクセスができないストレージではあるが、複数のEC2インスタンスから共有して利用することができない!
完全に内部サーバー向けストレージとして強化することができる

日常のアウトプット日常のアウトプット

AWS Elastic MapReduce

ビックデータの処理と分析に特化したマネージドサービスのこと
分散処理フレームワークであるApache HadoopやApache Sparkを簡単にセットアップし、大規模なデータ処理ワークフローを効率的に実行する
大量のデータを効率的に複数のサーバーに分散させて処理・分析するためのマネージドサービス

日常のアウトプット日常のアウトプット

データウェアハウスとは?

→企業や組織が蓄積した大量のデータを統合して保管し、分析のための最適化されたデータベースのこと

AWS Redshiftは、AWSが提供するクラウド型のデータウェアハウスサービス
大量のデータの分析するために最適化されている

日常のアウトプット日常のアウトプット

DynomoDB

  • 利用する際にユーザーに責任になるセキュリティ関連タスク
    アクセスは、ユーザー側でアクセス許可を設定して管理する必要がある

例)Lambda関数からDynamoDBテーブルにアクセスしてデータを登録する処理を実行する場合、Lambda関数に対してDynamoDBへのアクセスを許可するIAMロールを付与する必要がある
※ユーザーデータはデフォルトでデータ保管時に暗号化される

日常のアウトプット日常のアウトプット

Route53

  • DNSサービス
    • ドメインを登録して、DNS名前解決によってドメインをルーティングすることができる(例.Amazon.comのAmazonがドメイン)
  • Route 53 Resolver DNS Firewall
    • サイトへのアクセスを制御し、Route 53 Resolverを介してVPCから送信されるDNSクエリに対するDNSレベルの脅威を防ぐことができる
ファイアウォールとは、
企業や組織内のネットワークとインターネットの間に設置されるセキュリティ対策で、不正アクセスやサイバー攻撃などの脅威からネットワークや端末を守る役割をになっている
  • アプリケーションとWebサーバーおよびその他のリソースの状態とパフォーマンスを監視するヘルスチェック機能を提供する
    • ヘルスチェックに基づいて、Route53は正常なエンドポイントのみにトラフィックをルーティングしてアプリケーションのフォールトトレランスのレベルを高める
日常のアウトプット日常のアウトプット

EC2におけるAmzon Machine Imageの役割

Amzon Machine Imageとは
EC2インスタンスを起動するためのテンプレート
OS(Amazon Linux, Ubuntu, Windows Serverなど)やアプリケーション、設定等が含まれている

日常のアウトプット日常のアウトプット

AWS Storage Gateway

オンプレミス環境のストレージwpS3にシームレスに接続でいるハイブリッドストレージサービス
❶オンプレミスストレージをS3バケットに接続
❷バックアップ構成にしたり、データ移行する

日常のアウトプット日常のアウトプット

ChefやPuppetとは

コードを使用してサーバーの構成を自動化できるようにするためのオートメーションプラットフォーム

OpsWorksでは、Chef や Puppet を利用し、EC2インスタンスやオンプレミスのコンピューティング環境でのサーバーの設定、デプロイ、管理を自動化可能

日常のアウトプット日常のアウトプット

サーバレス

アプリのフロント、サーバーのコードは開発者が書く必要があるが、サーバー自体の管理や設定作業はクラウドプロバイダが代わりに行ってくれる

日常のアウトプット日常のアウトプット

AWS Global Accelerator

AWSの有するグローバルなインフラネットワークを利用して、ユーザーのトラフィックのパフォーマンスを最大60%向上させるネットワーキングサービス
→インターネットが混雑している場合に、パケット損失、ジッター、レイテンシーを一貫して低く保ちながら、世界中のユーザーに提供するアプリケーションの可用性とパフォーマンスを改善する

日常のアウトプット日常のアウトプット

DynamoDB

  • テーブルに保存できる項目数に制限なし
  • 大量のデータを効率的に保存・取得するために「パーティション」という単位でデータを分割
    • 各パーティションはAWSの複数のデータセンター(AZ)へコピーされる
    • 複数のアベイラビリティゾーンにデータベースを配置し、各ノードにデータを分散して配置することで単一障害を防いでいる
  • RDSと異なり、カラムではなく、属性という概念を持つ
    • 各アイテムが必要な属性を必要なだけもつことが可能
  • 複雑な検索はできないので、主に「パーティションキー」で検索
  • 複数のテーブルを結合
  • 集計等のSUM, AVG, COUNTは直接できないので、アプリ側で処理が必要になる

※プライマリーキーだけは必須!!!!

説明
スカラー(Scalar) 1つの値のみ "Alice", 30, true
セット(Set) 重複なしのリスト ["AWS", "DynamoDB"]
リスト(List) 重複ありのリスト ["Alice", "Bob", "Charlie"]
マップ(Map) JSON のような構造 { "city": "Tokyo", "country": "Japan" }

パーティションキー+ソートキーの複合キー

  • 同じパーティションキーをもつ複数のアイテムが存在できる
  • パーティションキーごとに、ソートキーの値で並ぶ
  • ソートキーも含めて「一意」になればOK

RDSと異なりできないこと

  • データが分散して配置されているため、テーブル間の結合不可
  • キーはパーティションキーとソートキーに限定されるため外部キーがない
  • データが分散して配置されているため、
    • プライマリーキー以外で検索が不可能
    • 検索結果のデータを条件とすることができない
    • 集約に必要なデータが検索時に足りない

スループット

一定時間内に処理できるデータ量のこと
「プロビジョニングモード」 や 「オンデマンドモード」 によって、このスループットを管理する
トランザクションの書き込みの場合、スループットが半分になる

日常のアウトプット日常のアウトプット

Route53

ドメイン名を管理し、クライアントのリクエストを適切なサーバーへ振り分けるDNSの役割
インターネット上の名前(ドメイン)住所(IPアドレス) に変換する

  1. ユーザーが example.com にアクセス
  2. OS(パソコンやスマホ)がRoute 53に問い合わせ
    🔍Route53は、example.comというドメイン名に対応するIPアドレスを持っているのか検索する
    →ドメイン名を「IPアドレス」に変換
    例)www.example.com → 192.168.1.10
  3. 適切なサーバーやサービス(EC2, S3, CloudFront, API Gateway など)に振り分け
[ ユーザー ]
     ⬇︎ (アクセス)
  example.com
     ⬇︎ (DNS 解決)
[ Route 53 ]
     ⬇︎ (ルーティング)
[ EC2 / S3 / CloudFront / API Gateway など ]

📌 Aレコードと CNAME の違い
DNSでドメイン名をどこに接続させるのか、ドメイン名を何に変換するのかという違いがある

◾️Aレコード

  • 「ドメイン名 → IPアドレス」への変換

◾️CNAMEレコード

  • 「ドメイン名 → 別のドメイン名」への変換
日常のアウトプット日常のアウトプット

静的コンテンツと静的Webサイト

静的コンテンツは、クライアントのリクエストに問わず、同じ内容を表示
HTMLファイル、画像ファイル等が該当

S3

容量無制限のオブジェクトストレージ
データは複数のAZに保存され、高い耐久性を持つ
→複数のデータセンターに保存されているため、特定にAZに障害が起きてもデータ消失を防げる

オブジェクトを更新・削除すると元に戻せない
バージョニングを有効にすることで、S3バケット内で更新・削除のイベントは1つのバージョンとして管理されるようになる

◾️バケットとは
オブジェクトの格納場所
バケット名がそのままURLに含まれるため、世界中のAWSアカウントの中で一意でないといけない

◾️Webサイトホスティング

  • サーバーサイド処理なしに、HTMLや画像、CSS、JSなどの静的ファイルを公開することができる
  • スケーラブル

※動的な処理はできない

◾️バケットポリシー
どのドメイン、またはユーザーがS3にデータにアクセスできるのか細かく制御可能
特定ドメインからのアクセスだけ許可:CORS設定

日常のアウトプット日常のアウトプット

AWS Certificate Manager

SSL/TLSサーバー証明書管理機能を提供するマネージドサービス
❶ACMで「指定したドメインのSSL証明書が欲しい!」とリクエスト
❷ACMがDNS認証のためのCNAMEレコードを提供
❸Route53にCNAMEレコードを追加
❹ACMがCNAMEレコードを確認し、SSL証明書を発行

※SSL/TLS:データを暗号化して送受信する仕組み
SSLを有効化するには、通信を行うサーバーに対してSSL/TSL証明書をを発行・配備する必要がある
→SSLが有効:HTTPを暗号化したHTTPS通信を利用する

日常のアウトプット日常のアウトプット

CloudFront

クライアントへコンテンツを高速配信することが可能

◾️CDNとは
システムのサーバー負荷を一時的に保存するエッジサーバーに、コンテンツを配信する高速化する仕組み

エッジサーバーを世界中に配置することで、他の国でアクセスされてもレイテンシーの遅延がないようにしている
自動的にもっとも近いエッジロケーションにアクセスするように振り分けを行う

日常のアウトプット日常のアウトプット

サーバレス

OS、スケーリング、セキュリティパッチ等はAWS側で自動で行うということ!
◾️Lamda
サーバーなしで関数を実行する

もしサーバーありで関数を実行するとなると、以下のようになる

方法 説明
EC2 インスタンス AWS の仮想サーバー(VM)を起動して、アプリケーションコードを実行 Python や Node.js のアプリを EC2 で動かす
オンプレミスサーバー 物理サーバーを自社で用意し、関数を実行 データセンター内の Linux サーバーで bash や Python を実行
コンテナ(Docker + ECS / Kubernetes) コンテナ化した関数を実行 AWS Fargate や ECS, EKS で Node.js アプリを動かす
Webサーバー(Nginx, Apache) HTTP リクエストを受けて関数を実行 Apache + PHP, Nginx + Python で関数を実行
サーバーアプリ(Express.js, Flask, Spring Boot) アプリケーションサーバーを用意し、関数を API として提供 Node.js (Express), Python (Flask), Java (Spring Boot) で API を作成

事前にサーバーを用意してシステム構築する場合よりも、「自由度は低くなる」
例)実行時間は最大15分のため、これを超えるとタイムアウトする
→Lamdaを使用してアプリケーションを構成すると処理単位が小さくする必要があり、必然的にコンポーネント数が増える

◾️API Gateway

  • フロントエンドとバックエンド(Lambda、EC2、コンテナ、マイクロサービスなど)を繋ゲートウェイ
  • 認証・認可
  • リクエストの検証と変換
  • レート制限・DDoS対策
    →特定のクライアントがAPIを連続で呼び出しすぎないように制限
  • モニタリング
  • キャッシュ
    • APIレスポンスをキャッシュし、パフォーマンスを向上
日常のアウトプット日常のアウトプット

Cognito

APIベースで実装されているWebアプリケーションやモバイルアプリケーションに認証機能を提供するサービス

構成要素

◾️ユーザープール
ユーザー名、パスワード、メールアドレスなどを管理するユーザーディレクトリサービスが提供される
ユーザーの認証に成功すると、CognitoからJSON形式のトークンが発行される

◾️IDプール
ユーザープールや外部IDプロパイダーで認証したユーザーに対して、AWSサービスへのアクセスを許可する機能
ユーザーの認証に成功すると、一時的なIAMクレデンシャルが発行される

DBにユーザー情報を保存して、手動で認証を管理できるが、Cognitoを使用する理由

✅ Cognito を使う理由

理由 説明
認証機能を自前で作らなくていい ユーザー登録 / ログイン / パスワード管理を Cognito が自動でやってくれる
セキュリティ管理が AWS 標準で強固 Cognito は MFA, JWT, OAuth, SAML などの最新技術に対応
スケーラブル(大量ユーザー対応) DB での認証だと負荷がかかるが、Cognito は AWS がスケーリング
IAM との連携が簡単 ユーザーごとのアクセス管理が簡単に設定できる
SNS ログインが簡単 Google, Apple, Facebook などのログインを簡単に統合可能
日常のアウトプット日常のアウトプット

スタックとは

AWS CDK や CloudFormation において、AWSリソースの集合を一括管理する単位

cdkでは、1つのスタックの中にVPC、ECS、RDS、IAM、S3などのAWSリソースを定義できる!

日常のアウトプット日常のアウトプット

AWSで、フロントエンド・バックエンドの更新の違い

フロントエンドは、基本的に静的ファイルをとして配信されるため、S3にアップロードしてCloudFrontChildでキャッシュ削除するだけで更新が可能になる!

しかし、バックエンドは、APIの処理、つまり動的な処理が必要なため、フロントエンドと同様の更新方法では更新できない。
また、Dockerコンテナを使用してデプロイし、「コンテナ化されている」ため、単にコードを変更するだけではなく 新しいコンテナをデプロイする というプロセスが必要になる!

  1. アプリケーションのコードを変更
  2. Dockerイメージをビルド
  3. ECRにプッシュ
  4. ECSのタスク定義を更新
  5. ECSのサービスを更新
  6. 新しいコンテナが立ち上がり、古いコンテナが置き換わる
日常のアウトプット日常のアウトプット

CloudFrontのビューワープロトコルポリシー

クライアントからのリクエストを受け付けるプロトコルを指定する。
選択肢は以下の3つ。
HTTP と HTTPS の両方からのリクエストを受け付ける
HTTP を HTTPS にリダイレクトする
HTTPS のリクエストのみ受け付ける

日常のアウトプット日常のアウトプット

サブネット設定

ECS:インタネットサクセスが必要なことが多い、パブリックサブネットが使用されることが多い。
isolated:インターネットと遮断されたPriveteサブネット→RDS、ElastecCacheなど内部で使用されるサービスに適している。

日常のアウトプット日常のアウトプット

ポリシーとロールの違い

ポリシー:ルール
ロール:どこにどのルールをアタッチするのか定義

ポリシーの種類

  • インライン:直接ルールを付与する(※他のスタックとかで共有ができなくなるルール)
  • カスタム
  • 管理ポリシー:AWS側で作成されたルール
日常のアウトプット日常のアウトプット

S3

S3バケット名は「グローバルで一意」
S3バケット名は世界中で1つだけしか使えない😂
同じ名前のバケットは、他のアカウントや他のリージョンでも使えない