SAA学習-模擬試験1回目問題と要点
今回のテーマ：模擬試験1回目問題と要点
SAA模試1回目
EBS
- 設問ポイント
- 200GB規模のRDB
- 13:00～17:00がピークタイム
- コスト効率がよいストレージ？
解説
設問ポイント
- 500MiB/sのスループット
- 継続的なログ処理
- 処理性能とコスト効率？
- 解説
DB
- 設問ポイント
- SMBを使用したデータ転送
解説
設問ポイント
- Kinesisストリームを数日かけて送信
- ストリームデータをS3へ保存するがS3にない
- データの未送信あり
解説
- Kinesis Stream
- できること
- ログとデータフィードとの取り込みと処理高速化
- リアルタイムのメトリクスとレポート作成
- リアルタイムデータ分析
- 複雑なストリーム処理
- 保存期間
- デフォルト24時間以内まで
- 最大8760時間(365日)
- できること
- Kinesis Stream
設問ポイント
- バックエンド
- 一時的にアクセス集中
- DynamoDB
- フロントエンド
- 費用帯効果が高くスケーラブルな構成
- バックエンド
- 解説
- 設問ポイント
- 負荷テスト実施時、CPU100%
- 読み取り処理が思い
- データレイヤーを最適化する方法？
解説
設問ポイント
- ELBで統合されたログファイルを分析
- ログファイル分析をする構成
- 解説
- 設問ポイント
- ゲーム開発
- ユーザー行動の解析を高速化
- 最小待ち時間で実現
解説
設問ポイント
解説
設問ポイント
- DynamoDBを利用すべき状況
- 解説
- 設問ポイント
解説
設問ポイント
- S3に蓄積したデータをRedshift連携したBI利用
- プライベートサブネットのみデータ利用に限定
- 解説
- 設問ポイント
- 大規模データの仕組みをAWSへ移行
- 現状、数百万行のデータを列集計し定期的にレポーティング
解説
- Redshift
- 高速でシンプルかつ費用対効果が高いDWH
- 列指向型のデータベース
- 列集計に優れたDWH
- レポーティングやBIで活用
- Redshift
設問ポイント
- ステートレスなアプリ構築
- セッションデータを格納するDB
- 解説
CloudFront
- 設問ポイント
- ECサイト展開
- 各地域に応じた言語表示
- 言語区分
- URL
- jp
- en
- URL
- 解説
- クエリ文字列パラメータ
- キャッシュ設定
- HTTPフィールドで言語表示の切り替え
- サーバー情報を送るためURLの末尾につけ立つ変数
- キャッシュ設定
- クエリ文字列パラメータ
環境の自動化
- 設問ポイント
- 社内CI/DC
- 自動ワークロード設定
- Elastic Beanstalkのワークロード
- ワークロード：実行中のSW処理によって占有される度合
- 解説
- Elastic Beanstalk
- 自動的にデプロイメント詳細を処理
- WEBアプリなどのワーカー環境構築
- 実行時間の長いワーカープロセスのチューニング
- Elastic Beanstalk
- 設問ポイント
- Kubernetesの利用
- AWSで使用できるサービス
解説
- Amazon EKS
- EKS = Ekastic Kubernetes Service
- フルマネージド型 Kubernetes docs.aws.amazon.com
- Amazon EKS
設問ポイント
- CloudFrontを利用したグルーバル配信
- 配信コスト削減効果
- 解説
- CloudFront
- オリジンからファイル取得
- エッジロケーションからファイル圧縮
- 各ロケーションにおける配信コスト低減
- CloudFront
- 設問ポイント
解説
HTTPアウトバウンド許可
NetworkACL Rulenumber:110 RuleAction:allow Egress:true CidBlock:0.0.0.0 PortRange: From:80 To:80特定IPからのFTPインバウンド
NetworkACL Rulenumber:120 RuleAction:allow Egress:false CidBlock:特定IP PortRange: From:20 To:20- Egress
- true→アウトバウンド
- false→インバウンド
設問ポイント
- ECS利用しDockerサービスを利用予定
- Dockerイメージセットの保管先
- 解説
- 設問ポイント
- 社内CI/CD
- chefレシピの利用
- 解説
- OpsWorks
- Chef/Puppet利用可能
- Chef/Puppet
- オートフォーメーションプラットフォーム
- コードを使用し、環境の自動化
- OpsWorks
サーバレス
- 設問ポイント
- ECSを利用し、マイクロサービス型分散システム構築
- マイクロサービス1とマイクロサービス2の連携
解説
- SQS
- サービス間の後処理連携
- フルマネージド型のメッセージキューイングサービス
- マイクロサービス
- 分散システム
- サーバレス
- SQS
設問ポイント
- ユーザーがファイルをS3にアップロード
- 各ファイルDynamoDBと連携
解説
- Lambda関数作成
- ファイルの名前をDynamoDBレコード追加
- S3バケットのイベント機能有効化
- Lambda関数と連携
- Lambda関数作成
設問ポイント
- マイクロサービス設計でアプリケーション構築
- コンポーネントは分離させ連携可
解説
設問ポイント
- 会員登録のWEBサイト構築
- SMSにメッセージの自動配信
解説
設問ポイント
- SNSとSQSの違い
- 解説
- SQS
- キューをポーリングするメッセージシステム
- ポーリング型配信
- SNS
- トピックに関するメッセージ送信
- プッシュ型配信
- SQS
Rouote53
- 設問ポイント
- EC2、CLB、Auto-Scaling、Route53構成
- Blue/Greenデプロイメント=異なる2つのアプリ
- ルーティングポリシーは？
- 解説
VPC
- 設問ポイント
解説
- NACL
- 1つ以上のサブネットに対しインバウンド/アウトバウンドを制御するFW
- 特定IPに対し拒否設定を登録
- サブネットの保護を実施
- NACL
設問ポイント
解説
設問ポイント
- ELB、複数AZにEC2設置
- 利用急増
- Auto-Scaling
- インターネット接続
- NATインスタンスで実施
- NATGWへの変更？
解説
- NATインスタンスからNATGWへ移行
- NATGWをパブリックサブネットへ設置
- プライベートサブネット側のルートテーブルにルート追加
- NATインスタンスからNATGWへ移行
設問ポイント
解説
設問ポイント
- パブリックサブネットにEC2
- インターネット接続可能で、自由にWEBサイトアクセス
- ルーティングテーブルは何？
- 解説
- ルートテーブルの設定
- 自由にどこからでも接続可
- Destination:0.0.0.0
- インターネット接続可能
- Target：InternetGW
- 自由にどこからでも接続可
- ルートテーブルの設定
S3
- 設問ポイント
- 解説
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/using-prefixes.html:embed;cite
- 設問ポイント
- 高可用性
- フォールトトレランス
- ファイルデータ格納でS3利用
- AZ損失時でもアクセス可能な状態？
- 解説
- Amazon S3の可用性
- S3はデフォルトで高可用性なので不要
- フォールトトレランス
- 構成要素の一部故障や停止
- 予備の系統に切り替える
- Amazon S3の可用性
- 設問ポイント
解説
設問ポイント
- EC2からS3へのアクセス
- インターネットを通過しない
- 解説
- 設問ポイント
- 動画データを大量保存
- アップロードした動画を利用可能
- 限られた期限内のアクセス許可
- 解説
- Amazon S3のアクセス権限
- デフォルト
- オブジェクト所有者のみしかアクセス不可
- 事前署名付きURLを利用
- 自身のセキュリティ資格を使用しアクセス可
- 他ユーザーに対しアクセス許可を提供
- デフォルト
- Amazon S3のアクセス権限
- 設問ポイント
- 動画保存
- データ量削減
- 2か月以上は削除
- 保存後は変更しない
- 解説
- S3 Standard IA
- アクセス頻度低い
- IA = Infrequency Access
- 低コスト
- 種別
- 標準IA
- 再作成できないデータ保管
- One-zone
- AZ障害発生時にデータを再作成可能
- 標準IA
- ライフサイクルポリシー
- 数か月以上のデータ削除
- アクセス頻度低い
- S3 Standard IA
- 設問ポイント
- バージョンによってデータ管理
- 複数EC2インスタンスからストレージにアクセス
- 頻繁に利用可能
解説
- S3
- データ共有
- バージョニング可能
- 頻繁に利用
- S3
設問ポイント
- 特定ファイル登録
- データ確認はレコード生成後2か月は逐次確認
- 以降のデータ確認は不要
解説
- S3のライフサイクルポリシー
- オブジェクトのライフタイムを定義
- 移動、アーカイブ、削除可
- S3のライフサイクルポリシー
設問ポイント
解説
- Standard-IA
- 低頻度アクセス時に利用
- 重要データを保管
- Standard-IA
設問ポイント
- 写真共有サイトを運営
- 他WEBサイトから共有サイトリンク
- 広告料金がもらえない
- 画像リンクの問題解消は？
- 解説
- 有効期限付きの事前署名付きURL
- 利用が終わったら削除
- リンクからの閲覧拒否
- 有効期限付きの事前署名付きURL
- 設問ポイント
- ストレージ容量限界
- S3を利用し大量データ保管
- ユーザーがアクセスしデータ保管するため間違って削除があり得る
- データ保護向けの管理は？
- 解説
- S3バケットのバージョンニング有効化
- 削除ファイルを復元
- 単一ファイルの複数バージョン保管
- S3バケットのバージョンニング有効化
EC2
- 設問ポイント
- 開発者が本番向けEC2を削除するかも？
- 対応方法は？
解説
- EC2の操作制限
- AWSアカウント分割
- 開発向けの環境のみ管理
- 開発用リソースしかアクセスできない
- タグ付け
- 専用タグ付与
- タグベースのIAMポリシー制限
- AWSアカウント分割
- EC2の操作制限
設問ポイント
- 大量データを定期的に処理
- 費用効果が高いもの
- 高負荷時はAuto-Scaling利用し拡張
解説
- スポットインスタンス
- 一時的な高負荷時のAuto-Scalingで使用
- 費用面で格安
- スポットインスタンス
設問ポイント
- 常に6つのEC2が3つのAZで稼働
- 単一AZが利用不可でも100%のフォールトトレランスが必要
- フォールトトレランス：障害があってもシステムは稼働
解説
- フォールトトレランスの条件
- 1つのAZが落ちても6つのEC2が稼働
- 各AZに3つのEC2
- 2つのAZに6つのEC2
- フォールトトレランスの条件
設問ポイント
- Linux AMIから起動した3つのWebサーバ
- Auto-Scalingが同じAMIで利用
- パブリックサブネットで稼働
- 4つ目起動時インターネット接続不可
解説
- インスタンス起動時の動作
- パブリックアドレスが付与されないときもあり
- パブリックIPの割り当てがオフ
- インスタンス起動時の動作
設問ポイント
解説
- EBSのバックアップ
- すべてのボリュームのスナップショット取得
- インスタンスを停止
- 各ボリュームに対し個別にスナップショット作成
- EBSのバックアップ
設問ポイント
- VPCには3つのサブネット
- パブリック：1つ
- Auto-Scaling設定のEC2
- プライベート：2つ
- パブリック：1つ
- EC2は同じSGで設定
- カスタムポートを使用し、モバイル許可するアプリ
- カスタムポートでインターネット接続
- ロールアウト：公開、運用開始、本格展開
- インターネット接続するための条件？
- VPCには3つのサブネット
解説
- セキュリティグループの反映
- 既存のSGで即時反映
- インターネット接続用のポート解放
- セキュリティグループの反映
設問ポイント
- リージョンでの障害発生
- BCPソリューションの作成
解説
- EC2のBCP対策
- EC2からAMIを作成し別リージョンへコピー
- 障害発生時別リージョンで復元
- AMIやスナップショットはデータ保存コストのみ
- EC2のBCP対策
設問ポイント
- EC2をオンデマンドにスケールアウトするため、Auto Scaling
- 起動時にソフトウェアをプレインストール
解説
設問ポイント
- 解説
セキュリティの確保
- 設問ポイント
- EC2とRDS構成のWEBアプリ
- EBSボリュームの暗号化
解説
- AWS Key Management Service(KMS)
- キー作成・管理を容易に実施
- EBS対応で暗号化可能
- AWS Key Management Service(KMS)
設問ポイント
- 一時的な認証情報
- 高いセキュリティ要件
解説
設問ポイント
- 自社リソースの保護
- リソースの保管時とAWSへ転送時のデータ保護は？
解説
設問ポイント
- S3のデータ暗号化
- 暗号化キーではない方法
- 解説
- SSE-S3
- Amazon S3がデータとマスターの暗号化キーを管理
- 暗号化と複合化はS3によって自動で管理
- SSE-S3
コスト最適化
- 設問ポイント
- WEBアプリ数年間利用
- 利用率：90～100%
- コスト最適化は？
解説
設問ポイント
- EC2とRDSの障害復旧モデル
- コスト最小化は？
- 解説
- 費用対効果が高いBCP対策
- バックアップを取得し、S3へ保管後にリストア
- バックアップ方式
- EC2:AMI
- スナップショットとブートイメージ
- RDS:スナップショット
- EC2:AMI
- 費用対効果が高いBCP対策
IAM
- 設問ポイント
- JSONでのリソース制御
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1487980617000", "Effect": "Allow", "Action": [ "codebuild:*", "codecommit:*", "codedeploy:*" ], "Resource": [ "arn:aws:codebuild:us-east-2:123456789012:project/my-demo-project", "arn:aws:codecommit:us-east-2:123456789012:MyDemoRepo", "arn:aws:codedeploy:us-east-2:123456789012:application:WordPress_App", "arn:aws:codedeploy:us-east-2:123456789012:instance/AssetTag*" ] } ] } 解説
- 特定権限設定
"Action": [ 許可するAWSサービス ],"Resource": [ 制限する項目 ]設問ポイント
- ルートアカウント作成
- IAMユーザーとグループ作成
- 特定のセキュリティ認証情報は？
解説
設問ポイント
- JSONでのS3リソース制御
{ "Version": "2012-10-17", "Statement": [ { "Sid": "FullAccess", "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] }, { "Sid": "DenyCustomerBucket", "Action": ["s3:*"], "Effect": "Deny", "Resource": ["arn:aws:s3:::customer", "arn:aws:s3:::customer/*" ] } ] }- 解説
- アクセス許可
- S3に対しすべて許可
{ "Sid": "FullAccess", "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] }アクセス拒否
- costomerバケットリソースはすべて拒否
{ "Sid": "DenyCustomerBucket", "Action": ["s3:*"], "Effect": "Deny", "Resource": ["arn:aws:s3:::customer", "arn:aws:s3:::customer/*" ] }設問ポイント
- EC2のWebアプリ
- DynamoDBに書き込み
- セッション読み取り専用EC2あり
- この時のテーブルアクセス制御は？
- 解説
- IAMロールをEC2にアタッチ
- DynamoDBの読み取り処理を許可
- IAMロールをEC2にアタッチ
- アクセス許可
Auto Scaling
- 設問ポイント
- EC2インスタンスに対し、AutoScalingの最適化
- スケールイン/アウトが頻発
- 対応策？
- 解説
- スケールイン/アウト頻発
- スケールインの開始が早すぎ
- Auto-Scalingグループ設定
- クールダウンタイマーの変更
- CloudWatchアラーム設定
- スケールインの基準値を変更
- スケールイン/アウト頻発
運用上の優秀性
- 設問ポイント
- BCP対策
- コスト最適化
- 他リージョンで必要時同じ構成で実装
- 解説
- CloudFormation
- 既存システム構成の準備
- AMIなどの指定
- EBSデータの内容も継承可
- CloudFormation
今回のテーマは以上です。
SAA学習-セキュリティと運用-コスト最適化
今回のテーマ：コスト最適化
主要サービスの公式資料
Auto Scaling： aws.amazon.com
リザーブドインスタンス： docs.aws.amazon.com
AWS Trusted Advisor： aws.amazon.com
Amazon CloudWatch： aws.amazon.com
5つの設計原則と11のベストプラクティス
5つの設計原則と11のベストプラクティスよりコスト最適化のスコープの概略図は以下のようになります。
Well-Architected FrameworkのCost Optimization：コスト最適化
コスト最適化では、不必要なリソースを削除し、最適な料金選択によりコストを最適化します。
設計事項は以下の項目が挙げられます。
- 不必要なリソース削減
- 透明性のある費用割賦
- マネージド型サービスの利用によるコスト削減
- 固定の償却コストを変動コストへ変換
- スケールによるコストメリット
- データセンターへの投資不要化
コスト最適化の主要サービス
AWSでのコスト最適化の観点は以下のものが挙げられます。
- 需要と共有の一致
- コストの高いリソース
- 支出の認識
- 継続した最適化
また、コスト最適化の観点とAWSで使用できるサービスの関係図は以下のようになります。
AWSの課金方式
AWSは利用量に応じて柔軟な価格設定となります。
利用形態の概要は以下のようになります。
- 従来課金
従来課金による利用料に応じた価格設定が基本 - 予約による低価格
EC2など特定のサービスには、予約による低価※格販売が実施
※リザーブド価格 - 使用するほど安い
AWSはボリュームディスカウントを受けることができ、使用量や増える程節約可能
AWSの料金改定
他のクライドサービスと競争するため、頻繁に料金改定がされ利用ごとに料金表を確認することが基本となります。
公式サイト
EC2の購入オプション
EC2の購入オプションは、利用形態や利用基幹などに応じて多岐にわたるため、コスト最適な選択をすることが重要となります。
オプションの項目は以下のようになります。
EC2のリザーブドインスタンス
EC2のリザーブドインスタンスは利用期間を長期指定で利用する形式となります。
リザーブドインスタンスの購入オプションとオンデマンドに合わせた概要となります。
| 項目 | スタンダード | コンバーティブル |
|---|---|---|
| 利用期間 | 1年：40%割引 3年：60%割引 |
1年：31%割引 3年：54%割引 |
| AZ/インスタンス/ネットワークタイプの変更 | 有 | 有 |
| インスタンスファミリー/OS/テイナンシー/支払いオプションの変更可否 | なし | 有 |
| リザーブドインスタンスマートプライスでの販売可否 | 可能 | 今後可能 |
また、リザーブドインスタンスやスポットインスタンスを利用するユースケースは以下のようになります。
- 一定した状態または使用料が予測可能
- BCPなどキャパシティ予約が可能なアプリケーション
EC2のスポットインスタンス
予備のコンピューティング容量をオンデマンドインスタンスに比べて、最大90%で利用できるEC2インスタンスとなります。
ポイントは以下のようになります。
- 予備用の入札式で利用するため安価
- 起動に通常より少し時間が必要
- 予備用のため途中で削除される可能性あるため、一時的な拡張で利用
EC2の物理対応可能なインスタンス
物理サーバーにインスタンスを起動し制御可能なタイプのインスタンスは以下のものがあります。
AWS Organizationsによる一括請求
AWS Organizationsの一括請求で、メンバーアカウント間のリザーブドインスタンスを共有化できたり、S3の利用用に応じた課金がお得となります。
Saving Plan
1年～3年の期間に一定の使用量を守ることでコストを削減できます。
ポイントは以下のものがあります。
- リザーブドインスタンスと同様に1年または3年の特定量の処理能力(USD/時間で測定)を使用する契約を結ぶことで適用される割引契約
- AWSコンピューティング使用料金を最大72%制約
- Amazon EC2、AWS Fargate、AWS Lambdaに適用可能
価格算定ツールを利用
AWS公式ツールを利用し、見積や価格比較を実施します。
公式ツールは以下のものがあります。
| ツール | 概要 |
|---|---|
| 簡易見積りツール | 利用するAWSサービスに対する利用料金を見積 |
| TCO計算ツール | AWS利用した場合とオンプレ環境やコロケーション環境との価格比較 |
| Pricing Calculrator | ビジネスや個人のニーズに沿った個別の予測コスト見積 |
コストの可視化
CloudWatchのbilling機能により請求額通知を可能とし、Trusted Advisorからアドバイスをもらいます。
Trusted Advisorの他の項目は以下のものがあります。
- コスト最適化
- セキュリティ
- 耐障害性
- パフォーマンス向上
AWS Budgets
カスタム予算を設定し、コストまたは使用料が予算額や予算量を超えた場合、細かくアラームを設定することが可能です。
Cost Explorer
AWSのコストと使用量の経時的変化を可視化し、カスタムレポートを作成することで、コストと使用料のデータ分析を行います。
AWSのコストと使用状況レポート
AWSのコストと使用状況に関する最も包括的データを提供します。
AWS Cost Categories
自身の組織やプロジェクト構造に分けてコストをカテゴライズすることが可能な機能となります。
今回のテーマは以上です。
SAA学習-セキュリティの運用-AWS KMSの活用
今回のテーマ：AWS KMS
主要サービスの公式資料
AWS KMS： docs.aws.amazon.com
AWS KMS
AWS KMSは、データを暗号化するためのマネージド型暗号化サービスとなります。
特徴としては以下のものが挙げられます。
- 暗号鍵の作成/管理/運用を実施するマネージドサービスで、AWSコンソールやAWS SDKまたはCLIを使用し、キーの作成/インポート/ローテション/削除/管理を実施
- IAMと連携し鍵のアクセス管理を実施
- カスタマーマスターキー(CMK)の無効化/有効化/削除を実施し、1年ごとの自動ローテションが可能
- CMKを外部から持ち込んで管理することが可能
- キーを保護するため、FIPS140-2の検証済みまたは検証段階のハードウェアセキュリティモジュールを採用
- AWS CloudTrail統合されており、すべてのキーの使用ログを表示
- RDSやS3などの多数のAWSサービスに適用可能
- KMS SDKを利用し、アプリケーションの暗号化が可能
AWS KMSの概念
AWS KMSの構成要素として3つあり以下のようなものがあります。
カスタマーマスターキー
- 暗号化を実行する上で最初に作成されるマスターキー
- 暗号化キーを暗号化する
- ローテションされる
カスタマーデータキー(暗号化キー)
- 実際のデータ暗号化に利用するキー
- KMSで生成されCMKにて暗号化される
エンベロープ暗号化
- マスターキーで暗号化せず、暗号化したデータキーを利用し暗号化をする暗号化方式
構成要素よりAWS KMSのポイントは、以下のようになります。
- データキーとマスターキーによる暗号化を実施
- カスタマーマスターキー(CMK)を利用しデータを暗号化
エンベロープ暗号化
エンベロープ暗号化の暗号化方式は、以下のように概要図となります。
今回のテーマは以上です。
SAA学習-セキュリティと運用-セキュリティの確保
今回のテーマ：セキュリティの確保
主要サービスの公式資料
AWS CloudTrail： docs.aws.amazon.com
Amazon CloudWatch： docs.aws.amazon.com
Amazon GuardDuty： docs.aws.amazon.com
Amazon Inspector： docs.aws.amazon.com
AWS WAF： docs.aws.amazon.com
AWS Shield： docs.aws.amazon.com
AWS リソースの アクセス管理： docs.aws.amazon.com
AWS Security Hub： docs.aws.amazon.com
AWS CloudHSM： docs.aws.amazon.com
5つの設計原則と11のベストプラクティス
5つの設計原則と11のベストプラクティスよりセキュリティの確保のスコープの概略図は以下のようになります。
Well-Architected FrameworkのSecurity
Well-Architected FrameworkのSecurityはAWS内のデータ/システム/アセットを保護し、モニタリングによりセキュリティを高めます。
設計事項としては以下の項目が挙げられます。
- すべてのレイヤーでセキュリティを適用
- アクセス追跡/モニタリングの確実な実施
- 条件ドリブンのアラートをトリガーとし、セキュリティイベントへの応答を自動化
- AWS責任共有モデルに基づく対象範囲の保護に集中
- セキュリティのベストプラクティスの自動化
- ソフトウェアベースのセキュリティ設定を使用し、迅速でコスト効率のよいスケーリングを安全に実行
- 仮想サーバーのカスタムベースラインイメージによる新サーバーへの適用自動化
- インフラストラクチャ全体のテンプレート化による管理
責任共有モデル
セキュリティに対しAWSとユーザーで責任分解し対応する責任共有モデルとなります。
ユーザー側の責任範囲とAWS側の責任範囲は以下のようになります。
公式サイトの資料：
なお、ユーザーが利用するAWSサービスの項目は以下のものが挙げられます。
- IAMによるアカウント管理
- セキュリティグループの設定
- アプリケーションのロールベースのアクセス設定
- ネットワーク/インスタンスオペレーション/バッチなどの設定
- OS/ホストベースのファイアーウォール設置
AWSのセキュリティの観点
AWSでのセキュリティの観点は、以下のものが挙げられます。
- データ保護
- 権限管理
- インフラ保護
- 検出制御
また、セキュリティの観点とAWSで使用できるサービスの関係図は以下のようになります。
データ保護
データ保護の項目として以下のものが挙げられます。
- 暗号化
- S3の暗号化
- RDSの暗号化
データ保護：暗号化
KMSは、多くのDBサービスと統合されており暗号化を容易に実施できます。
KMSを活用できるAWSサービスは以下のものが挙げられます。
- EBS
- RedShift
- RDS
- Elastic Transcoder
- S3
- WorkMail
- EMR
KMSより堅牢な対応として、CloudHSMを活用し、不正使用防止策がとられている専用HWモジュールによる暗号化キーを保護するサービスを活用します。(専用HWモジュールの略称：HSM)
データ保護：S3の暗号化
S3は、データ保護のためAWS認証情報によるアクセス制御と暗号化を実施します。
S3の暗号化方式と特徴は以下のようになります。
| 暗号化方式 | 特徴 |
|---|---|
| サーバーサイド暗号化 | ・AWSのサーバーリソースを利用し格納データを暗号化 ・暗号化タイプ：SSE-S3/SSE-KMS/SSE-C |
| クライアントサイド暗号化 | ・暗号化プロセスをユーザー側で管理 ・暗号化タイプ：AWS KMSで管理されたカスタマーキーで暗号化/クライアントで管理するマスターキーで暗号化 |
データ保護：RDSの暗号化
RDSは、セキュリティグループの制御、データ接続の暗号化およびリソースの暗号化を実施します。
RDSのセキュリティの実施概要については以下のようになります。
| 項目 | 実施概要 |
|---|---|
| セキュリティグループ | ・DBのSGでDBインスタンスへのアクセス制御 ・VPCのSGでVPC内のインスタンスへのアクセス制御 ・EC2のSGでEC2インスタンスへのアクセス制御 |
| データ接続の暗号化 | ・SSL/TLSを用いてアプリケーションとDBインスタンスのデータ接続を暗号化 |
| リソースの暗号化 | ・暗号化オプションにより保管データを暗号化 |
権限管理
権限管理の項目でAWSで実施するサービスなどは以下のものが挙げられます。
権限管理：AWS Directory Service
AWS Directory Serviceは、ユーザーに関わる各種情報を保管しユーザー認証を実現する仕組みとなります。
管理する情報と実現する機能について以下のものがあります。
管理するユーザー情報
- ID
- ユーザー名
- 妙名氏名
- 部署
- グループ
- 担当
- 電話番号
- メールアドレス
- パスワード
実現する機能
- IDとアクセス管理
- 運用上の向上
- コンプライアンスの向上
- セキュリティの強化など
アプリのアクセス制御
- ファイル共有
- パッチ管理など
また、AWS Directory Serviceを使用する際、AWSに新規ディレクトリを作成するか既存のActive Directory認証を利用した制御を利用するか2つの認証方式があります。
- Simple AD：AWSに新規ディレクトリサービスを作成
- AD Connect：既存のディレクトリサービスをAWSに接続
権限管理：Security Token Service(略称：STS)
STSは、限定的で一時的なセキュリティ認証情報を提供するサービスとなります。
フローとしては以下のようになります。
権限管理：Amazon Cognito
Amazon Cognitoは、シンプルでセキュアなユーザーのサインアップ、サインインおよびアクセスコントロールをアプリケーションへ実装するサービスになります。
例：FacebookのSNS認証など
インフラ保護
インフラ保護の観点としてネットワーク制御となり、観点は以下のものが挙げられます。
- サブネットの分割
- VPCアクセス制御
インフラ保護：サブネットの分割
サブネットは、インターネットアクセス範囲を定義するため利用します。利用するサブネットは、プライベートサブネットを活用し、インターネットから隔離することでセキュリティを高める対応を行います。
インフラ保護：VPCアクセス制御
VPCは、セキュリティグループとネットワークACLで制御します。
検出制御
検出制御は、監視やモニタリングを継続的に実施し、セキュリティを高めます。
AWSサービスと概要については以下ものがあります。
| AWSサービス | 概要 |
|---|---|
| CloudTrail | AWSユーザーの行動ログを取得し、ガバナンス、コンプライアンスおよび運用とリスク監視を行えるように支援するサービス |
| CloudWatch | AWSリソースとAWSで実行するアプリケーションに対し、さまざまなメトリクスやログを収集/追跡するモニタリングサービス |
| AWS GuardDuty | AWS上で悪意のある操作や不正な動作を継続的にモニタリングする脅威検出サービス |
| AWS Inspector | 自動的にアプリケーションを検証し、その露出、脆弱性およびベストプラクティスから逸脱状況を確認後、セキュリティ評価を実施するサービス |
| AWS WAF | 可用性、セキュリティ侵害、リソースの過剰消費といった一般的なWebの脆弱性からWebアプリケーションまたはAPIを保護するWebアプリケーションファイアーウォール CloudFrontと連携されるサービス |
| AWS Shield | マネージド型の分散サービス妨害(略称：DDoS)に対する保護サービス AWS Shieldにはスタンダートとアドバンスの2つの階層がありサポート範囲が異なる |
| IAM Access Analyzer | 外部エンティティと共有されているAmazon S3バケットやIAMロールなど組織とアカウントのリソースを識別し、セキュリティ上でリスクであるリソースとデータへの意図しないアクセスを特定 |
| AWS Security Hub | セキュリティアラートを一元的に表示と管理し、コンプライアンスチェックを自動化 監査結果から修正すべき設定の数と現在のセキュリティ状態を把握可能 |
cf)AWS WAFとAWS ShieldをセットでDDos攻撃対策を実施します。
今回のテーマは以上です。
SAA学習-環境自動化-小テスト
今回のテーマ：環境自動化の小テスト
問1 Codeシリーズの組合せとして正しい内容を選択してください
回答
CodeDeployはコーディングされた内容を展開する
解説
AWS CodeDeployは、Amazon EC2/AWS Fargate/AWS Lambda/オンプレミスで実行されるサーバーなど、さまざまなコンピューティングサービスへのソフトウェアのデプロイを自動化を行うフルマネージド側サービス
問2 Elastic Beanstalkの説明で正しい内容を選択してください
回答
Webアプリケーションやサービスを使い慣れたサーバーでデプロイおよびスケーリングするためのサービス
解説
Elastic Beanstalkでは、アプリケーションを実行しているインフラストラクチャについて学習することなく、AWSクラウドでアプリケーションをすばやくデプロイし、管理できます
問3
Elastic Beanstalkの説明として間違っている内容を選択してください
回答
アプリケーションはBeanstalkによって展開されるWebアプリケーションの単位
解説
アプリケーションはトップレベルの論理単位でバージョンや環境設定が含まれる
問4
OpsWorksで実施できる利用方法として正しい内容を選択してください
回答
OpsWorks for Puppet EnterpriseはPuppetのみしか利用できません
解説
なし
問5
Amazonのコンテナサービスの説明として正しい内容を選択してください
回答
Amazon ECRはコンテナサービスを格納します
解説
なし
問6
CodePipelineの特徴として間違えている内容を選択してください
回答
Code Commit/CodeBuild/CodeDeployに特化した専用パイプラインサービス
解説
CodePipelineは上記以外にもECSなどで利用可能です
問7
Amazon ECSについて間違っているものを選択してください
回答
解説
Amazon ECSはDockerFileを使ってDockerイメージを作成します
問8
CloudFormationのテンプレート内の記述要素について間違っている内容を選択してください
回答
Parametersにリソースなどの詳細な設定内容を記述する
解説
Parametersにはパラメーター設定を定義し、関数で呼び出す際に利用する
今回のテーマは以上です。
SAA学習-環境の自動化-CloudFormationの概要
今回のテーマ：CloudFormationの概要
主要サービスの公式資料
AWS CloudFormation： docs.aws.amazon.com
CloudFormation
AWSクラウド環境内の全インフラリソースを記述し、テンプレート化することで展開する環境自動設定サービスとなります。
特徴としては以下のものが挙げられます。
- プロビジョニングされたリソースの変更・削除が可能
- JSON/YAMLで記述
- クロスリージョンとクロスアカウントで管理
- 直接サポートされてないリソースや機能を利用する場合、カスタムリソースを使用
- カスタムリソース使用時、スタック作成の一部に独自ロジックを実装
ユースケース
CloudFormationを使用する場合、環境構築を正確に実施する場合や効率的に展開したい時に使用します。
実装時のためのポイントは以下のものが挙げられます。
- AWSリソースの構築を効率化
- 開発/テスト/本番環境で利用するインフラの標準化
- 毎回小野路リソースやプロビジョニング設定を正確に利用
- ソフトウェアと同じように環境構築を管理
CloudFormationの構成
CloudFormationの構成は、テンプレートで定義された内容を読み込みAWSリソースの集合体であるスタックを作成します。
構成要素のポイントは以下のものがあります。
Cloud Formation
スタックの作成/変更/削除/エラー検知とロールバックやリソース間の依存関係を自動判定スタック
AWSリソースの集合体でスタック単位で管理可能。
スタックを削除すると関連したリソースも削除
CloudFormationの機能
CloudFormationの機能は、テンプレート自体を管理や便利に使うための機能を提供してます。
機能の要素は以下ものが挙げられます。
| 要素 | 概要 |
|---|---|
| 変更セット | ・スタックの更新を行うための概要 ・変更による影響度を確認するためのスタック ・スタック変更は直接更新と変更セットの実行で可能 |
| ドリフト | ・テンプレートによって展開したAWSリソースを展開語に変更した場合、元テンプレートとの差分を検出するチェック機能 |
| スタックセット | ・複数のAWSアカウント複数のリージョンに対しスタックを作成できる機能 |
| スタック間のリソース参照機能 | ・被参照添付レートの参照値をエクスポートし、値を抽出 ・参照先のテンプレートのインポートによりリソース参照を行うことで、連携したインフラ展開が可能 |
また、CloudFormationデザイナーを利用することで、視覚的にテンプレートを作成することが可能です。
テンプレート
実装する際のサンプルは以下のようなものがあります。
AWSTemplateFormatVersion:
Description:
Metadata:
Parameters:
Mappings:
Conditions:
Transform:
Resources:
FirstVPC:
Type:AWS::EC2::VPC
Properies:
CidrBlock:10.0.0.0/16
Tags:
-Key:Name
Value:FirstVPC
AttacheGateway:
Type:AWS::EC2::VPCGatewayAttachement
Properies:
DependOn:
VpcId: !Ref FirstVPC
InternetGatewayID: !Ref InternetGateway
Outputs:
実装要素の補足説明は以下となります。
| 項目 | 補足説明 |
|---|---|
| AWSTemplateFormatVersion | テンプレートのバージョンを指定 |
| Description | テンプレートの説明 |
| Metadata | テンプレートに関する追加情報 |
| Parameters | 実行時に必要なパラメーターとしてKeypairやユーザー名を記述。定義するとRef関数で値参照が可能 |
| Mappings | 条件パラメーターを指定するためのキーと値のマッピングを記述 |
| Conditions | リソース作成時の条件名と条件内容を記述 |
| Transform | サーバレスアプリのSAMバージョンを記述 |
| Resources | 実際にスタックを生成するリソースとそのプロパティを記述 |
| Outputs | スタック構築後に出力される値や出力先を記述 |
実際に作成するリソースの名称やプロパティの記述となります。
FirstVPC:
Type:AWS::EC2::VPC
Properies:
CidrBlock:10.0.0.0/16
Tags:
-Key:Name
Value:FirstVPC
任意にユーザー側でリソース間の依存関係を実装する記述となります。
Properies: DependOn:
組込関数：RefやFindInMapの活用部分となります。
AWS標準の設定値を参照する場合はRefを使用し、Mappingsで定義した値を参照する場合はFindInMapを使用します。
VpcId: !Ref FirstVPC
今回のテーマ以上です。
SAA学習-環境の自動化-AWSの環境自動化サービス
今回のテーマ：AWSの環境自動化サービス
主要サービスの公式資料
Auto Scaling： docs.aws.amazon.com
Cloud Formation： docs.aws.amazon.com
CodeCommit： docs.aws.amazon.com
CodeBuild： docs.aws.amazon.com
CodeDeploy： docs.aws.amazon.com
ECS： docs.aws.amazon.com
Elastic Beanstalk： docs.aws.amazon.com
OpsWorks： docs.aws.amazon.com
SystemManager Run Command： docs.aws.amazon.com
スコープ
5つの設計原則と11のベストプラクティスより環境の自動化のスコープの概略図は以下のようになります。
主要サービス
AWSで環境の自動化を行うサービスとして以下のものが挙げられます。
- Auto Scaling
- Cloud Formation
- Code シリーズ
- ECS
- Elastic Beanstalk
- OpsWorks
- SystemManager Run Command
目的
環境を自動化することで開発速度を高め、DevOpsとCI/CDによる開発を実現します。
クラウドファーストの時代背景
テクノロジー×ビジネスに柔軟に対応するため、クラウドファーストが必要不可欠となります。
概略図は以下のようになります。
また、リーンによる素早いサービス検討とCI/CDによる素早い開発をマイクロサービスに対し実施します。
概略図は以下のようになります。
環境自動化サービス
AWSでは、DevOpsを実現する環境自動化サービスを豊富に提供されております。
概略図は以下のようになります。
環境自動化サービスの概要は以下のようになります。
| サービス名 | 概要 |
|---|---|
| Codeシリーズ | 開発コードのgit上のコミット・実行・デプロイを自動。 PipelineはCloudFormation/ECSのデプロイ自動化にも利用可能 |
| Elastic Beanstalk | Webアプリやサービスを使い慣れたサーバーでデプロイやスケーリングをするサービス |
| OpsWorks | ChefやPuppetのマネージド型インスタンスのサーバー設定・デプロイ・管理を自動できるようになる設定管理サービス |
| CloudFormation | クラウド環境内のすべてのインフラストラクチャリソースを記述し、 プロビジョニングするためテンプレート化されたプロビジョニングサービス |
| Amazon ECS | AWS上でDockerコンテナによる環境構築のテンプレート化するサービス DockerFile開発イメージを設定したインフラ設定をコード化 |
| CloudWatch | EC2インスタンスやEBSボリューム・DBインスタンス、カスタムメトリクスなどリソースを簡単にモニタリング |
Codeシリーズ
Codeシリーズは、開発コードをgitベースのリポジトリ上で、コミット・実行・デプロイを自動化する一連のサービスとなります。 概略図は以下のようになります。
Elastic Beanstalk
Elastic Beanstalkは、Webアプリケーションの定番構成の構築・デプロイの自動化サービスとなります。
ポイントは以下のようなものがあります。
- 速く簡単にアプリをデプロイするサービス
- Java,PHP,Ruby,Python,Node,js,.Net,Docker,Goの開発言語に対応し、Webアプリを展開
- Apatch,Nginx,Passenger,IISなどのWebサービスでデプロイ
- コードをアップロードすれば、キャパシティのプロビジョニング、ロードバランシング、Auto Scalingからアプリケーションのヘルスチェックまでデプロイを自動化
Elastic Beanstalkの構成用途
Elastic Beanstalkの構成用途として、アプリケーション単位にバージョン・環境設定をコードし、保存されて環境にバージョンが展開されます。
項目としては以下のものが挙げられます。
| 項目 | 概要 |
|---|---|
| アプリケーション | ・トップレベルの論理単位でバージョン/環境/環境設定が含まれる要素 |
| バージョン | ・デプロイ可能なコードでS3で管理 ・異なる環境/異なるバージョンを展開可能 |
| 環境 | ・各環境(Webサーバー/ワーカー)に応じて構築されるインフラ環境 ・バージョン(ソースコード)をデプロイ |
| 環境設定 | その環境に関連するリソースの動作を定義する設定パラメータ ・永続データの格納場所はS3やRDSなどの外部サービスを利用 |
Elastic Beanstalkのユースケース
Elastic Beanstalkのユースケースは、Webアプリケーションのデプロイを容易にすることやタスクの長いワークロード展開に利用します。 Webサーバー環境とワーカー環境では以下のようになります。
Webサーバー環境
- ELB+Auto Scalingでスケーラブルな構成をコード化し、バージョン管理を実施
- スケーラブルなWebアプリケーションを実行の実現
- 単一コンテナのDockerコンテナを実行可能
- 複数コンテナはECSを使用した環境実行が可能
ワーカー環境
- SQS+Auto Scalingでスケーラブルなバッチ処理ワークを実現
- 定期的なタスク実行基盤の作成：毎日深夜1時に動作するバックアップ処理
- ワーカーホスト内でWebアプリケーションを動作させワークロードの時間がかかる処理を実行
OpsWorks
OpsWorksは、ChefやPuppetによるインフラ設定・運用の仕組みをAWS上でマネージド型サービスとして提供してます。
AWS上で使用できるサービスは以下になります。
- OpsWorksスタック
- OpsWorks for Chef Automation
- OpsWorks for Puppet Enterprise
OpsWorks for Chef Automation
OpsWorks for Chef Automationは、Chefサーバーを作成し、継続的なデプロイメントおよびコンプライアンスチェックの完全マネージド型サーバーサービスとなります。
サービスの概要としては以下のものがあります。
- Chef Automaionは、Chefのcookbookやレシピを利用しインフラ管理を自動化するサービス
- インフラおよびアプリの継続的なデリバリーパイプラインを構成することが可能
- リソースはChefサーバーから構成内容のアップデートを取得
- オペレーション/コンプライアンス/ワークフローイベントを可視化
- AWSでChefサーバを構築でき、Chef Automate APIやChef DKなどのツールを利用
OpsWorks for Puppet Enterprise
OpsWorks for Puppet Enterpriseは、フルマネージド側Puppetマスターにより、アプリケーションのテスト/展開/運用を自動します。
サービスの概要としては以下のものがあります。
- Puppetマスターは、インフラないノードを管理し、ノード情報を保存とPuppetモジュールの中央リポジトリ
- Puppetマスターは、以下のタスクを処理する全スタック自動可
- ソフトウェア
- OS設定
- パッケージのインストール
- データベース設定
- 変更管理
- ポリシー適用
- モニタリング
- 品質保障
- モジュールは、インフラストラクチャの設定方法に関する手順を格納したPuppetコードを再利用および共有が可能とするユニット
- Puppetを使用し、EC2やオンプレミスデバイスにあたるノードの設定/デプロイ/管理方法を自動化
OpsWorksスタック
OpsWorksスタックは、スタックとアプリケーションの作成/管理のため、シンプルで柔軟な方法を提供するAWSのオリジナルサービスとなります。
サービスの概要としては以下のものがあります。
- スタック/レイヤー/インスタンス/アプリケーションと呼ばれるコンポーネントによりモデル化を実施
- コードで構成管理やオートスケーリングが可能
- Linux/Windowsサーバをサポート
- ライフライクルイベントによるタスクの自動化が可能
- OpsWorksエージェントがChef Clientのローカルモードでレシピを実行
- スタックがOpsWorksのトップエンティティである全インスタンスの構成要素をJSON形式で管理
- AWS OpsWorksスタックはChefサーバ不要
Elastic BeanstalkとOpsWorksの違い
Webアプリのデプロイに特化したElastic Beanstalkに対し、OpsWorksは様々なアプリケーションに対応する高度なインフラ環境構築が可能です。
Elastic Beanstalk
アプリケーションのデプロイ自動化
Webアプリケーションやサービスを使い慣れたサーバーにおいてデプロイとスケーリングをするためのサービスとなります。OpsWorks
インフラの設定自動化
ChefやPuppetのマネージド型インスタンスのサーバー設定/デプロイ/管理を自動化できるようになるインフラの設定管理サービスとなります。
CloudFormation
CloudFormationは、AWSクラウド環境内の全インフラリソースを記述しテンプレート化して展開する環境自動設定サービスとなります。
ポイントは以下のものがあります。
- プロビジョニングされたリソースの変更/削除が可能
- 追加リソースは通常課金のみで追加料金なし(CloudFromationのみなら)
- JSON/YAMLで記述
- クロスリージョンとクロスアカウントで管理
- 直接サポートされていないリソースや機能を利用する場合、カスタムリソースでスタック作成の一部に独自ロジックを組み込むことが可能
コンテナ
コンテナは、ホストマシンのカーネルを利用し、プロセスやユーザーなどを蚊瓜する仮想化方式となります。 イメージ図としては以下のようになります。
Docker
Dockerは、コンテナ側の仮想環境を作成/配布/実行するためのプラットフォームとなります。
ポイントは以下のものが挙げられます。
- コード化されたファイルを共有するため誰でも同じ環境構築が容易に可能
- 作成した環境を配布教諭が容易
- 環境の即時構築/削除が容易なため、CI/CDによる開発が可能
AWSのコンテサービス
AWSで使用できるコンテナサービスとして以下のものがあります。
| 種別 | AWSサービス名 | 概要 |
|---|---|---|
| レジストリ | Amazon ECR | コンテナエンジンに実行されるイメージを保管 |
| コントロールプレーン | Amazon ECS/EKS | コンテナを管理するサービス |
| データプレーン | AWS Fargate | コンテナが実行される環境 |
Amazon ECS
Amazon ECS(Elastic Container Service)は、Dockerコンテナをサポートする拡張性とパフォーマンスに優れたコンテナオートストレーションサービスとなります。
ポイントは以下のものが挙げられます。
- コンテナ化されたアプリをAWSにおいて簡単に実行およびスケール可能
- Fargateを利用することでコンテナのデプロイと管理サーバーのプロビジョニングや管理は不要
- あらゆる種類のコンテナ可されたアプリケーションを簡単に作成可
- Dockerコンテナの数が多くても数秒で起動可能
- ELB/VPC/IAM/ECR/CloudWatch/CloudFormation/CloudTrailなどのAWSサービスを利用可
- VPCネットワークモードで、TaskごとにENIを自動割り当てし、Security GroupをTaskごとに設定可
- VPC内の他リソースへPrivete IPで通信が可能
- Fargate起動タイプとEC2起動タイプの2種類のモード
Amazon ECR
Amazon ECR(Elastic Container Registry)は、フルマネージド型のレジストリサービスでDockerコンテナイメージを簡単に保存/管理/デプロイすることが可能です。
ポイントは以下のものが挙げられます。
- ECSとDocker CLIに統合されており、開発から本稼働までのワークフローを簡略化
- IAMによる協力な認証管理機構
- エンドポイントにアクセスできるならAWS外からでも利用可能
- ライフサイクルポリシーでイメージの自動クリーンアップ
- VPCネットワークモードでタスクごとにENIを自動割り当てし、さらにセキュリティグループをタスクごとに設定可能
Amazon EKS
Amazon EKS(Elastic Kubernetes Service)は、コンテナ化されたアプリケーションのデプロイ/管理/スケールをオープンソースのKubernetesを使用し実行するサービスとなります。
ポイントは以下のものが挙げられます。
- Kubernetesは、自動デプロイ/スケーリング/アプリ/コンテナの運用自動化のため設計されたオープンソースプラットフォーム
- Kubernetesのパートナーやコミュニティが作成した既存のプラグインやツールを使用可能
- マネージド側サービスであり、コントロールプレーンの管理不要
- ワーカーノードとマネージドコントロールプレーンとの間に、暗号化処理された安全な通信チャネルを自動的にセットアップ
- Kubernetes環境で管理されるアプリケーションと完全な互換性
AWS Fargate
AWS Fargateは、サーバーやクラスターの管理なしにコンテナを実行するECSに対応したコンピュータエンジンとなります。 起動モードは2種類あり以下のものになります。
EC2起動モード
- ECSでEC2インスタンスを起動
- コンテナアプリケーションを実行するインフラストラクチャに対し、サーバーレベルの詳細なコントロールを実行可能
- サーバークラスタを管理し、サーバーでのコンテナ配置をスケジュール可能
- サーバークラスターでのカスタマイズの幅広いオプションの利用可能
Fargate起動モード
- ECSで設置できる専用のコンピューティングエンジン(2019年12月よりEKSも対応可)
- EC2インスタンスのクラスター管理は不要
- インスタンスタイプの選択/クラスタースケジューリング管理/クラスター使用の最適化は不要
- CPUやメモリなどアプリ要件を定義すると必要なスケーリングやインフラはFargateが管理
- 秒で数万個のコンテナを起動
CodePipeline × CloudFormation の連携
CloudFromationで設定したAWS環境に対し、CodePipelineを使うことでテンプレートの変更/実行/展開を自動化できます。
CodePipeline × ECS の連携
ECSで設定したDocker環境に対し、CodePipelineを使用することでテンプレートの変更/実行/展開を自動化できます。
今回のテーマは以上です。
