AWS が推奨する原則・ベストプラクティスの基本を学べる【Architecting on AWS】を受講してみた

皆さんこんにちは、AWS事業本部オペレーション部の清水です。

AWS Certified Solution Architect - Assosiate 認定を取得するべく、「Architecting on AWS」を受講してきました。以下に、学習した内容や参考ブログをご紹介したいと思います。

本コースの受講をお考え中の方へ、お役に立てば幸いです。

AWS認定トレーニングとは？

以下のブログに、弊社AWS認定トレーニング講師の平野のほうで執筆した各トレーニングの詳細が記載されています。

私が今回受講したのは、以下の図の赤枠に入るコースになります。このトレーニングは、AWSが推奨する原則・ベストプラクティスの基本を学べる内容のため、AWS学習の初級編を卒業された方々の最初に受けるトレーニングになるかと思います。

扱うサービスカテゴリ

1. サーバーレス
2. ネットワークとコンテンツ配信
3. データベース
4. セキュリティ
5. マネジメントとガバナンス
6. ストレージ
7. AWSコスト管理
8. コンピューティング
9. コンテナ

事前準備

お申込みすると以下のようなメールが届き、事前にこのような前提知識があるうえでトレーニングが行われるといった説明が記載されています。

知識レベル

「AWS認定クラウドプラクティショナー」レベルの知識習得/構築経験

無料デジタルトレーニング（事前受講推奨）

• [Architecting on AWS 受講者向け]
  • 「入門ウェビナー Cloud Practitioner Essentials for Entry」

１日目

モジュール１：アーキテクチャの設計の基礎

AWSを利用するメリット

AWS の クラウドが選ばれる 10 の理由 | AWS

1. AWSは世界で一番使われているサービス！
2. 従量課金制（使った分だけ払うのがクラウドの利点）

• 移行するメリット
  1. 俊敏性（物理的にサーバーをもっているのと比較して、サーバーを発注して使うまでの時間と比べて圧倒的に速い）
  2. 自分たちが本当に開発したいアプリなどに、リソースを集中できる
  3. ピーク時に容量やスペックが足りなくなっても、クラウドの場合はスケーリング可能
  4. 物理的なデータセンターの管理から解放される

AWSインフラストラクチャ

• データセンター
• アベイラビリティゾーン
  • データセンターを１まとめにした塊（少なくとも１００キロ圏内に設置）
• リージョン
  • 複数のアベイラビリティゾーンで構成
  • リージョンは完全に独立
    • 物理的に距離が離れているとレイテンシーの遅延につながる
      • 一般的に日本の会社であれば、東京リージョンを選択
    • ガバナンス
      • 例えばヨーロッパリージョンを使う場合、ヨーロッパの法令が基準になる。そのため要件で国外にデータ保管出来ないといった場合は、東京リージョンを選択することが必要
    • リージョンによりコストが異なる
    • 利用できるサービス
      • アメリカから展開されることが多いので、東京リージョンにないサービスも
• AWS Local Zones
  • 低レイテンシー
  • ユースケース：「動画編集」制作会社⇔動画編集システム
  • 遅延を極力少なくしたい場合に利用
• エッジロケーション
  • 高速コンテンツ配信
  • ユースケース：「配信」動画編集システム⇒ユーザー
  • 世界の主要な都市に設置

AWS Well-Architected Framework

1. 計画
2. 調査
3. ビルド

上記の３つの知見を活かしたフレームワーク

• セキュリティ
• コスト最適化
• 信頼性
• パフォーマンス効率
• 運用上の優秀性
• 接続可能性

あくまで Well-Architected Freamework はガイドライン。全項目必ず従っていなければいけないわけではない。これらを理解した上で、ビジネス的な判断をすることが必要！（ガイドラインを使わない項目は、リスクや改善点を組織内で共有しておく）

AWS Well-Architected Tool

• フレームワークをドキュメントを読んで、確認していくのは非常に大変！
  • AWS Well-Architected Tool を使うとドキュメントを読まなくても、AWS Well-Architected Framework に従った設計かどうか確認できるので便利

ラボ１：AWS マネジメントコンソールとAWS Command Line Interface  の確認と操作

1. AWS マネジメントコンソールを確認して操作
2. AWS マネジメントコンソールを使用してリソースを作成
3. AWS CLI を確認して操作
4. AWS CLI を使用してリソースを作成

モジュール２：アカウントのセキュリティ

プリンシパルとアイデンティティ

• ルートユーザー
  • すべてのAWSサービスへのフルアクセス権を持つ
  • AWSの日常の操作に使用しない
• IAM
  • ユーザー、グループ、ロールを作成及び管理
  • AWSサービスとリソースへのアクセスを管理
  • アクセスコントロールを分析
  • 認証：認証情報（AWSにサインイン）
  • 認可：行動、アクションなどのアクセスを許可（リクエストを実行）
• プリンシパル
  • AWSリソースに対して、アクションや操作のリクエストを行う
  • ヒト、アプリケーション、フェデレーテッドユーザー（外部ユーザー）、ロール

• IAM ポリシーによるアクセス許可の設定
  • ポリシー⇒ユーザー・グループ・ロールへ割り当て
  • IAMポリシーを、IAMユーザーに都度都度アタッチすると管理が大変 ⇒ グループにポリシーをアタッチする
• IAM ロール
  • 一時的な認証情報を提供（一時間だけアクセス許可したい場合など）
  • 引き受けたロールで作業を行っている間のみ、アクセス許可が有効になる
  • IAMユーザー以外にも、AWSサービスでもアクセス許可を行える

• セキュリティポリシー
  • アクセス許可の付与
    1. アイデンティティベースのポリシー
       1. サービスアクセスのもの（AWS管理）
       2. 職務権限のもの（AWS管理）
       3. カスタム（ユーザー管理）
    2. リソースベースのポリシー

複数アカウントの管理

• 本番環境と検証環境では、アカウントは分けるのをおススメ
• AWS Organizations を利用してる場合
  • 一括請求が、管理アカウントに対して可能に
  • 仕組みは無料で利用可能！
• AWS Organizations を使用しない場合
  •  IAMポリシーなどをそれぞれのアカウントで書く必要がでてくるので大変
• IAM ポリシーとSCP
  • SCPはアクセス許可として付与するのではなく、フィルターとして使うイメージ

モジュール３：ネットワーク１

VPC の基礎

• Amazon VPC（バーチャルプライベートクラウド）
  • まずは自分たちが使うIPアドレスの範囲を決め、VPCを利用
  • 予め大きな範囲を指定するのを推奨（今後拡張されることが予想される場合は "/16" で区切る、特に大きく範囲指定しても追加で課金はなし）
  • AZは１個以上設置可能
• サブネット
  • CIDRブロックは重複できない
  • ５つのアドレスは予約される
  • １つのAZに複数のサブネットを含められる
• インターネットゲートウェイ
  • VPCをただ置いただけでは、外のインターネットと通信が出来ない
  • これを設置することによって、VPCが外と通信できるようになる
• ルートテーブル
  • VPCの中での通信の通り道
• Elastic IP アドレス
  • クラウドの中で、動的なIPアドレスを固定したい場合に利用
  • EC2インスタンスが障害が発生した場合などに、あらかじめIPアドレスを振っておくと新しいEC２インスタンスでも同じIPアドレスが利用できる
  • リージョン、アカウント毎にデフォルトでは５個まで
  • これを回避するために、IGWの前にNATゲートウェイを使う
• Elastic Network Interface
  • ケータイのSIMカードみたいなもの
  • これがあるからこそ、Elastic IP アドレスが使えて外と通信が出来る

NAT ゲートウェイ

• パブリックのIPアドレスの節約が可能に！
  • Elastic IP アドレスは５個までしか使えないので、１つ１つのEC2インスタンスに振るのではなく、NATゲートウェイ１つに割り振りする
  • NATゲートウェイから、その先のEC2インスタンスへ割り振りをする

• プライベートサブネット
  • VPCの中でしか通信しない
  • 通信の宛先にNATゲートウェイにしておけば、外に通信が可能に

VPC トラフィックセキュリティ

• ネットワークアクセスコントロールリスト（ACL）
  • サブネットに対して適用
  • デフォルトでは、全部許可
  • ステートレス（自分がリクエストした通信で投げるのを許可していても、帰りの通信も許可ルールが必要）

• セキュリティグループ
  •  ステートフル（自分がリクエストした通信で投げるのを許可していれば、帰りの通信は無条件でOK、許可ルール不要）
  • インスタンスなどのリソースレベルで適用
  • デフォルトでは、全部拒否
  • セキュリティグループはチェーンできる

モジュール４：コンピューティング

EC２インスタンス

• 名前とタグ
  • タグは少ないより多いほうがいい
  • 大文字小文字が区別
• アプリケーションとOSイメージ
  • Amazon Machine Image（AMI）EC2インスタンスの起動テンプレート
    1. AWSが提供
    2. マーケットプライス
    3. 独自のAMIを手動作成
• インスタンスのタイプとサイズ
  • AWS Compute Optimizerを使えば、Cloud Watchデータを元に、最適なインスタンスファミリーをオススメしてくれる
  • EC2インスタンスファミリー（リージョンによっては、使えないものもある）
    1. 汎用
    2. メモリ最適化
    3. ストレージ最適化
    4. コンピューティング最適化
    5. 高速コンピューティング
• キーペア
• ネットワークとセキュリティ
• ストレージ
  • 記憶する容量がないとEC２インスタンスが動かない
  • Amazon Elastic Block Store（EC2インスタンスにつけたり、外したりが可能なブロックストレージ）
    • １つ以上のEBSを必ずアタッチする
• プレイスメント
  • クラスター（ハイパフォーマンスコンピューティング）
  • スプレッド（医療記録システムなど）
  • パーテーション（大規模な分散）
•  テナンシー
  • 共有テナンシー（ハードウェアを、別の組織と共有）
  • ハードウェア専有インスタンス（料金を払えば、別の組織のインスタンスと、物理的に分離される）
  • Dedicated Hosts（料金を払えば、別の組織のインスタンスは載ってこず、完全に制御される）
• スクリプトとメタデータ

EBSボリュームタイプ

• EC2インスタンスが停止すると、インスタンスストアの全データが失われる
  • 消えて困る場合、EBSボリュームまたは別のストレージサービスに保存する

• SSDベースを基本では使う
  • gp2（汎用、迷ったらこれ）
  • gp3（汎用、迷ったらこれ）
  • io1
  • io2
• HDDベース（保存容量が多い、コスト安い）
  • st1
  • sc2

料金オプション

1. オンデマンド
2. SavingsPlans（RIよりこっちのほうが、うまく使えば安くなることもありオススメ）
   1. Compute Savings Plans
   2. EC2 Instance Savings Plans
3. スポットインスタンス
   1. 割引率が最大９０％でコスパがいい
   2. ただし中断に備える必要がある。途中で停止してもリカバリー可能な処理で利用をオススメ
      1. イメージとメディアのレンダリング
      2. Webサービス
      3. ビッグデータと分析

２日目

ラボ２：Amazon VPC インフラストラクチャを構築する

1. Amazon VPC を作成
2. パブリックサブネットとプライベートサブネットを作成
3. インターネットゲートウェイを作成
4. ルートテーブルを設定し、サブネットに関連付け
5. Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを作成し、インスタンスへのパブリックアクセスを可能に
6. Amazon EC2 インスタンスをプライベートサブネットに分離
7. セキュリティグループを作成し、Amazon EC2 インスタンスに割り当て
8. AWS Systems Manager の機能であるセッションマネージャーを使用して Amazon EC2 インスタンスに接続

モジュール５：ストレージ

ストレージは３種類

1. ファイルストレージ（EFS,FSｘ）
   1. フォルダーを階層構造で作っていき、データを探しに行くもの
2. オブジェクトストレージ（S3、S3 Glaicer)
   1. フラット構造。それぞれのデータに対して一意のIDがふられていて、同じ階層に保存。
3. ブロックストレージ（EBS)
   1. データを細かいブロック、ボリュームに分割したうえで保存。

Amazon S3

• ユースケース
  • バックアップと復元
  • 分析用のデータレイク
  • メディアストレージとストリーミング
  • 静的Webサイト（この場合、CloudFrontなどを門番においてアクセス制御する）
  • アーカイブ、コンプライアンス

• アクセスコントロール
  • デフォルトは、全てプライベート
  • パブリックの設定も可能だが、推奨していない
  • アクセスポリシーを利用し、アクセス制御を推奨

• 暗号化
  • S3管理キー（SSE-S3）
  • KMSキー（SSE-KMS）
  • 二重層サーバーサイド暗号化（DSSE-KMS）
  • カスタマー提供キー（SSE-C)

• ストレージクラス
• 耐久性　99.999999999%（保存されたデータが、失われない数値）
  • 標準（高頻度アクセス）
    • S3標準
    • S3標準 - IA
    • S3 One Zone - IA
  • Glaicer（低頻度のアクセス、コスト効率がいい）
    • S3 Glacier Instant Retrieval (ミリ秒単位で復元）
    • S3 Glacier Flexible Retrieval（数分～数時間で復元）
    • S3 Glacier Deep Archive（12時間以内で復元）
  • Intelligent-Tiering（不定期アクセス、自動で使う頻度によって保存タイプを変更してくれる）

• バージョニング（設定するかしないか、決定できる）
• ライフサイクルポリシー
  • ３０日超えたものは、別のストレージクラスへ移動。その後365日経ったらアーカイブへさらに移動するなど
• レプリケーション
  • バケット全体のオブジェクトを、自動で非同期でコピー（同じリージョンでも、クロスリージョンも可）

Amazon EFS

• S3はファイルシステム向けに構築されていない
• EBSは１つのインスタンスにアタッチしたら、複数では使えない
• 利点
  • スループットをスケール
  • 自動的に拡大、縮小できる
  • 使った分だけ料金請求される

以下を使いたい場合は、EFSを利用する

1. Amazon Linux

Amazon FSｘ

以下を使いたい場合は、EFSではなくFSｘを利用する

1. Windowsファイルサーバー
2. NetApp ONTAP
3. Lustre
4. OpenZFS

データ同期・移行ツール (ソース：ストレージ）

【オンライン】

AWS Storage Gateway

1. オンプレミス環境 ⇔ AWSを低遅延で接続。
2. オンプレミスのバックアップで利用するため、オンプレミスメインで利用している方が利用するケースが多い。

AWS DataSync

1. 専用のAPPをオンプレミス環境にインストール。専用のプロトコルでデータを転送。
2. ファイルデータを定期的に同期するため、オンプレミスもクラウドも両方同じ割合で使っているケースが多い。

AWS Transfer Family

【オフライン】

AWS Snow Family

1. 大規模なデータの移行の場合。物理的に物を運んで、運搬してデータを移行する

モジュール６：データベースサービス

リレーショナルDB

• 入るデータが決まっていて、データ品質の確保が必要な場合
  • 沢山の負荷がかかると、高いパフォーマンスが必要になる
  • 銀行の口座管理などが利用例

Amazon RDS

• 使いたいDBエンジンが決まってる時は、Auroraは利用しない
• ハードウェア、OS、DBのデプロイやメンテナンス、組み込みモニタリングもAWSがやってくれる！
• マルチAZ配置は、基本的に行う
• リードレプリカ（読み取り専用のDBを作り、読み取りの負荷をプライマリのDBの負荷を軽減）

- Amazon Aurora（DBエンジンに制限がない場合、第一候補はこれ）

• PostgreSQL、MySQL互換性がある別のDBエンジン（純正のPostgreSQL、MySQLではない）
• AuroraはAWSが作ったので、DBエンジンに縛りがない時はAuroraを選ぶ
• 高い可用性が必要な要件の時に利用する、リレーショナルDB
• クラスター（DBのかたまり）
• プライマリDBを残しておきたい場合、こちらもマルチAZ配置は行う

非リレーショナルDB

• プライマリーキー：属性
• NOSQL DBのほうが、早く読み込み書き込みが可能
  • 早さが大事なため、ゲームのデータに利用される
  • ecサイト

DynamoDB

• 離れたリージョン間でのレプリケーションを自動化

キャッシュ

Amazon ElasticCache

• キャッシュが可能なAWSのサービス
  • Memcached（遅延の許容が可能な場合、こちらが選択の第一候補）
  • Redis（銀行の口座情報など、遅延が許されないもの）

DynamoDB Accelerator（DAX)

• DynamoDB向けのキャッシュサービス

データ移行ツール (ソース：データベース）

AWS Database Migration Service

• 異種のデータベース移行

AWS Schema Conversion Tool

• AWSにないDBを、AWSへ使えるDBに移行してくれる

ラボ３：Amazon VPC インフラストラクチャでのデータベースレイヤーの作成

1. Amazon Relational Database Service (Amazon RDS) データベースのインスタンスを作成
2. Application Load Balancer を作成
3. Application Load Balancer に HTTP リスナーを作成
4. ターゲットグループを作成
5. ターゲットをターゲットグループに登録
6. ロードバランサーとデータベースへのアプリケーション接続テスト
7. コンソールを使用して Amazon RDS DB インスタンスのメタデータを確認

モジュール７：モニタリングとスケーリング

モニタリング

Amazon CloudWatch

• メトリクス
  • 　システムパフォーマンスに関するデータ
• ログ
  • CloudWatch Logs
    • メトリクスデータを元にしたログデータ
  • CloudTrail（監査ログ）
    • IAMユーザーのアクティビティ、APIの使用状況
    • アクセスキー漏洩、不正利用が考えられるときなどに調査で利用
  • VPCフローログ
    • VPCの中を流れるトラフィックのログ
  • カスタムログ
    • アプリケーションインスタンスから生成されたログ

アラーム

CloudWatch アラーム

• 「ALARM」は必ずしも緊急事態とは限らない

EventBridge

• CloudWatchから送信されたアラームによって、インスタンスを終了させたり、機能を有効化させたりなど、イベントを発火させるときに利用
• 料金は発生したイベントごとに課金

オートスケーリング

Auto Scalling

• 起動テンプレート
• EC2 Auto Scalling グループ
• Auto Scalling ポリシー

ラボ４：Amazon VPC で高可用性を構成する

1. Amazon EC2 Auto Scaling グループを作成し、複数のアベイラビリティーゾーンにまたがる Application Load Balancer に登録
2. 可用性の高い Amazon Aurora データベース (DB) クラスターを作成
3. Aurora DB クラスターの可用性を高める変更を加える
4. Amazon Virtual Private Cloud (Amazon VPC) の設定を変更し、冗長な NAT ゲートウェイを使用して可用性を高く
5. 障害をシミュレートして、アプリケーションとデータベースに高可用性が確保されていることを確認

モジュール８：オートメーション

AWS CloudFormation

• 命令書を書いたら、あとはインフラを自動でリソースを作成してくれる（アプリケーションの部分は、Step Functionsの領域）
• 複数のテンプレートを使用する
  • アイデンティティ
  • ベースネットワーク
  • 共有
  • バックエンド
  • フロントエンド

SystemsMaganer

• システム管理の自動化
• パッチの適用など

CodeWhisperer

• 自分がコードを途中まで書くと、そのあとのコードをAIを使って提案してくれる
• ChatGPTよりもAWSに特化している
• セキュリティスキャン

３日目

モジュール９：コンテナ

• モノリシックアーキテクチャ
  • 全ての機能を一緒にデプロイする必要があるアーキテクチャ
• マイクロサービスアーキテクチャ
  • アプリケーションを細かく分割、個別に管理するアーキテクチャ

• 疎結合
  • アンチパターン（Webサーバーがアプリケーションサーバーと密結合）
  • ベストプラクティス（ロードバランサーを介して疎結合、こちらを推奨している）

Amazon ECS

• フルマネージド型
• とりあえず、一度AWSでコンテナを使ってみたい方向け

Amazon EKS

• Kubernetesを使うには、EKSを利用するのが必要

AWS Fargate

• ECSまたはEKSをスケールするタイミングで、Fargateがコンテナを実行してくれる
• 最小の労力で済むため、コストがかかる

モジュール１０：ネットワーク２

VPCエンドポイント

• VPCの外にAWSのサービスに、インターネットゲートウェイやNATゲートウェイ、パブリックIPを利用せずにアクセス可能
• 通信をパブリックに流したくない時に利用
  • ゲートウェイエンドポイント
    • ルートテーブルで指定
    • S3・DynamoDBをサポート
  • インターフェイスエンドポイント
    • 基本はこちらを採用することを最初に考える

VPCピアリング

• VPC同士を接続する
  • VPC A- VPC B -VPC C（AからCへは繋がっていないため、A-Cもつなげたい場合、フルメッシュピアリング設定が必要）
  • Transit Gatewayを使うと、フルメッシュピアリングの悩みが解消される

Transit Gateway

• 最大5000台のVPCと、オンプレミス環境を接続
• Transit Gatewayを介すと、1つづつVPCピアリングしなくていい

Site to Site VPN

• 一時間単位の時間で請求

Direct Connect

• データ容量で料金が請求（こっちのほうが高額になる）
• データセンターからAWSリソースへのファイバーリンクを作成（物理的にケーブル配線が必要）

モジュール１１：サーバーレス

• EC2インスタンスだと、リクエストが来ていない時にも課金されてしまう
  • サーバーレスで解決！

AWS Lambda

• • 実行時間が15分・最大10GBなので、これの要件に合わない場合はEC２を使う
    • Webサイトのように常に起動していて、そこにある必要がある要件の場合はLambdaは使えない
    • OSを選びたい場合や古い言語を使う場合も、Lambdaが使えない
  • サーバーやOSをメンテナンスする必要がなく、開発者はコードを開発、管理するだけでいい
  • コードが実行されると、料金が課金されてしまう
    • リクエストが多い場合などは、EC２のほうが安い場合も

Amazon API Gateway

• 数1000件の同時API実行数が、可能になる
  • Lambda単体だと、制限がでてしまう実行数でも可能になる

Amazon Simple Queue Service (SQS)

• メッセージの永続性がある
• フルマネージドのメッセージキューイングサービス

Amazon Simple Notification Service (SNS)

• メッセージの永続性がない
• メール・JSON形式のメール
• 人が読めるメッセージで配信される
•  AWSのサービスにもメッセージを送信できる
  • Lambda
  • SQS
  • Kinesis

Amazon Step Functions

• フローチャートを利用して、マイクロサービスを連携できる

ラボ５：サーバーレスアーキテクチャを構築する

1. リソースを疎結合にする価値を理解
2. Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを Lambda 関数に置き換える潜在的価値を理解
3. Amazon SNS トピックを作成
4. Amazon SQS キューを作成
5. Amazon S3 でイベント通知を作成
6. 既存のコードを使用して AWS Lambda 関数を作成
7. SQS キューから AWS Lambda 関数を呼び出す
8. Amazon CloudWatch Logs で AWS Lambda の S3 関数をモニタリング

モジュール１２：エッジサービス

エッジとは

• 出来るだけ使ってる人の近くで、クラウドのサービスを展開する機能のこと

Amazon Route53

• パブリックホストゾーン
• プライベートホストゾーン

Amazon CloudFront

• グルーバルなコンテンツ配信ネットワーク
• WAF・Shieldと統合

AWS Outposts

• AWS のサービスをオンプレミスで実行
• 手元にデータを置きながら、データベースのサービスを使う場合など

ラボ ６: Amazon S3 オリジンで Amazon CloudFront ディストリビューションを設定する

1. S3 バケットをデフォルトのセキュリティ設定で作成
2. S3 バケットをパブリックアクセス用に設定
3. S3 バケットを既存の CloudFront ディストリビューションに新しいオリジンとして追加
4. S3 バケットを保護して CloudFront ディストリビューションからのアクセスのみを許可
5. OAI を設定してセキュリティを S3 バケットにロックダウン
6. Amazon S3 のリソースポリシーをパブリックまたは OAI アクセスに設定

モジュール１２：バックアップと復旧

• 目標復旧時点（RPO）
  • データ損失の最小化
• 目標復旧時間（RTO）
  • ダウンタイムの最小化
• スナップショット
  • バックアップの軽いバージョンのようなイメージ

AWS Backup

• AWSの様々なサービスのバックアップを一元化で管理できる

おわりに

AWSには各サービスが多数ありますが、トレーニングを受講しハンズオンを行うまで、似たような役割のサービスは問題を解いているだけでは感覚的に理解できず、苦戦していました。非エンジニアの方でも、クラウドプラクティショナーを取得後に、各サービスの大まかな概念や前提知識を入れるには、こちらのトレーニングが最適です！

なお本コースは、各サービスの深堀はしないため、SAA取得後にそれぞれのカテゴリの専門分野を学習したい場合は、別途トレーニングを受講していく必要があります。この記事がどなたかのお役に立てば幸いです。