目的として
AWSソリューションアーキテクトアソシエイトの資格取得のため、また、知識を蓄えて案件参画時に活かせるようにしたい！！
ということで、いつでも見返せるように以下にまとめる(量が多いため検索して該当の部分を参照できることをひとまず目的とする)
ネットワーキングとコンテンツ配信
・VPC Endpoint
VPC内のEC2などからAWSの各サービスにアクセスする際にインターネットへのアクセスを制限したい場合に利用することによりインターネットへのアクセス無しでAWSサービスを操作可能
・PrivateLink
VPC Endpointのインターフェイスエンドポイントであり、専用のENIが作製されることによりプライベートアドレスが割り振られる
・VPC Peering
VPC間の通信を確立するサービス
・AppMesh
コンテナ化によってマイクロサービス化されたアプリケーションを可視化し、トラフィックを制御するサービスで、サービスメッシュによるサービス内のエラー発生時のトラフィックの再ルーティングの困難を可視化により回避できる
・Global Accelerator
グローバルのユーザに提供するアプリケーションの可用性およびパフォーマンスを改善するサービス
・Transit Gateway
AWS内のVPCやオンプレミスネットワークを接続するサービスであり、VPC Peeringとの違いとして中央のハブ方式でルーティングするためネットワークやルーティング設定が簡素化される
サーバレス
・Event Bridge
様々なアプリケーションやAWSサービスから送られてきたイベントをターゲットとなる別のアプリケーションやAWSサービスなどに配信できるサーバーレスのイベントバスサービス
・Step Functions
一連の処理フローをステートマシンとしてJSON形式の定義ファイルで定義し、処理を実行する基盤を提供。定義された処理フローはマネジメントコンソール上で可視化されるためユーザーが確認可能
開発ツール
・CodeGuru
開発者が作成したアプリケーションのプログラムコードについて機械学習の技術を活用してパフォーマンスの問題を起こす可能性のあるコードを見つけて、コードの保守性を向上させるツール。改修案を提示してくれる
・Corretto
様々なプラットフォームで利用可能な無料のOpenJDKディストリビューション
・AWS CDK
様々なプログラミング言語を使用して、AWS上で構築したいインフラ基盤をコードで定義し、CloudFormationを通じてデプロイするためのOSSの開発フレームワーク
・Cloud9
クラウドデータベースの統合開発環境(IDE)であり、JavaScriptやPython、PHPなどのプログラミング言語によるアプリケーション開発においてはブラウザのみでコードの記述、実行、デバックが可能
・CloudShell
ブラウザからAWSリソースやツールにコマンドラインで直接アクセスあうるためのシェル
・CodeArtifact
ソフトウェアのパッケージ、ソースコードをコンパイルして生成されたバイナリの保存、公開、共有を容易にするフルマネージドなアーティファクトリポジトリ
・CodeBuild
ビルドとデプロイの一連の処理フローからデプロイ用のパッケージを生成することができるフルマネージド型のビルドサービスであり、コンパイルや単体テストにおいてサーバー、ソフトウェアの設定を省略できる
・CodeBuild
ビルドとデプロイの一連の処理フローからデプロイ用のパッケージを生成することができるフルマネージド型のビルドサービスであり、コンパイルや単体テストにおいてサーバー、ソフトウェアの設定を省略できる
続いて以下に設計等についてまとめる
レジリエント(弾力性がある)アーキテクチャの設計について
ここでいうレジリエントとはサービス中断から素早く復帰できる能力が高いことであり、システム設計においてはDesign for Failureの原則に基いて設計することが基本
①多層アーキテクチャソリューションの設計
⇒AZ全体が影響を受ける障害が発生した場合の検討を行う
⇒EC2を複数のAZに配置し、ELBを利用してリクエストを複数のAZに分散
⇒さらにAuto Scalingと組み合わせるとELBのヘルスチェックに失敗したサーバーは自動的に削除され正常なインスタンスに置き換えられてシステムの自動復旧が実現
②高可用性・高耐障害性のアーキテクチャの設計
⇒リージョン全体が影響を受ける障害が発生した場合の検討を行う
⇒複数リージョンに同一構成のシステムを構築し、Route53を利用してリクエストをルーティングするマルチリージョン構成により高可用性実現
⇒Route53のヘルスチェックとルーティングポリシーの設定により、リージョン障害時に自動でセカンダリリージョンにフェイルオーバー可能
③疎結合なメカニズムの設計
⇒1つのコンポーネントで起きた障害が他に影響を与えないように出来るだけ疎結合にすることにより可用性の向上が実現
⇒疎結合なアーキテクチャの一つとしてコンポーネント間をSQSキューで繋ぎ、メッセージの直接的な送受信を避けて可能な限りコンポーネント間のやり取りを非同期にすることでスケーラビリティも向上
④適切な回復力のあるストレージの選択
⇒目標復旧時間(RTO)と目標復旧辞典(RPO)に合わせて適切なバックアップ方法を選択する
⇒S3、Storage Gatewayなどの選択肢あり
高パフォーマンスアーキテクチャの設計について
AWSにおいてアプリケーションの開発・運用をする場合は適したサービスの選択と、システムのパフォーマンスを監視してボトルネック、または過剰なキャパシティとなっているリソースの把握が重要であり、その問題が起きているリソースに応じた対策を実施することによりパフォーマンスを最適化
①コンピューティングソリューション
⇒EC2を利用するにあたり、インスタンスタイプ、ネットワーキングオプション、ストレージオプションから最適解を選択
⇒Lambdaにおいては１つのリクエストを処理している間に再度呼び出されると別のインスタンスが割り当てられ、同時実行数の上限まで自動でスケールアウトする。また、CPUリソースについてはメモリ容量に比例して割り当てられるためスケールアップしたい場合はメモリ容量を追加する
②ストレージソリューション
⇒アクセス方法、パターン、頻度に応じて最適解を選択
⇒主にブロックストレージ、ファイルストレージ、オブジェクトストレージに分類される
③ネットワーキングソリューション
⇒レイテンシー、スループット要件、ジッターに応じて最適解を選択
⇒主にCDN、DNS、ネットワーク経路、オンプレミス接続に分類される
⇒特にネットワーク経路のGlobal Accelertorについては以下にまとめる
Global Accelertor・・・ユーザはグローバルに配置されたエッジロケーションからAWSグローバルネットワーク経由でシステム接続可能であり、LBとEC2と組み合わせて利用可能
④データベースソリューション
⇒データベースサービスはクエリパターン、クエリ頻度、パフォーマンス要件などに応じて最適なものを選択
⇒以下に代表的なデータベースサービスを分類/サービス名にて示す
リレーショナル/RDS、Aurora
NoSQL/DynamoDB
データ分析/Redshift
インメモリ/ElasticCache
AWSリソースへのセキュアなアクセス設計
セキュリティ対策として「ID管理とアクセス管理」「インシデントの検出」「インフラストラクチャの保護」「データ保護」「インシデント対応」について検討する必要がありその際に、システムの重要度に合わせてリスク管理策を策定するリスクベースアプローチの考え方を適用する
①OrganizationsによるAWSアカウントの統合管理
⇒ Organizationsを使用することで増大した複数のAWSアカウントを本番環境や開発環境といった用途ごとグループ化してポリシーベースで階層的に管理可能
②IAMによるユーザ管理
⇒AWSのサービスやリソースへのアクセスを管理するためのサービスでありIAMグループにIAMポリシーをアタッチすることによりグループ単位で権限管理可能
⇒ポリシー定義は許可定義(Allow)よりも拒否定義(Deny)の方が優先される
⇒AWSではタグをAWSリソースに付与してそのタグを条件にしてアクセス許可を適用可能であり、ルール通りにタグが付与されているかのチェックにはConfigRulesを活用できる
③IAMロールによる一時的認証情報の発行
⇒IAMロールはAWSサービスやアプリケーションに対してAWSの捜査権限を付与するための仕組み
セキュアなアプリケーション階層の設計
VPCのネットワーク制御について以下にまとめる
⇒ネットワーク(インスタンス)間の通信制御にはセキュリティグループを用いる
⇒サブネット間の通信制御にはACLを用い、ステートレスなファイアウォールのためインバウンド、アウトバウンドルールの両方を定義する必要あり
インターネットとの接続について以下にまとめる
パブリックサブネット・・・インターネット接続可能
プライベートサブネット・・・VPC内のみ通信可能でありRDSのようなインターネット接続を必要としないサービスを配置する
AWSサービスとの接続について以下にまとめる
⇒PrivateLink(VPCエンドポイント)を使うとVPC内のリソースはインターネットを介さずにAWSリソースにアクセス可能であり、エンドポイントポリシーと組み合わせて接続先のサービスへのアクセスを特定のVPCからの接続に制限してインターネットからはアクセス不可にするなどの制御が可能
外部攻撃からの保護について以下にまとめる
⇒AWSシールドはUDPリフレクション攻撃、SYNフラッド攻撃といってDDoS攻撃からリソースを保護でき、デフォルトでStandardレベルの保護が有効であり、AdvancedではEC2、Route53などで実行中のアプリケーションを標的とする高度な攻撃からも保護可能
AWSWAFはAPI Gateway、CloudFront、LBと関連付けることによりこれらのサービス上のHTTP/HTTPSトラフィックを双方向で監視して一般的な攻撃からアプリケーションを保護
データセキュリティオプションの選択
サーバーサイド暗号化とクライアントサイド暗号化について
⇒どちらのモデルを採用するかはデータの分類結果に応じて決める
①サーバーサイド暗号化・・・AWSの機能を用いてサーバー側で暗号化し、メリットとしてアプリケーション側は暗号化の意識の必要性無し
②クライアントサイド暗号化・・・ユーザのアプリケーションで暗号化し、メリットとしてAWSがデータを受信する特にすでに暗号化されているため、ユーザの管理下で確実なデータ保護の実現可能
保管中のデータの保護
AWSのサービスには、KMSと統合された暗号化の仕組みが提供されている
暗号化されていないEBSボリュームやRDSを暗号化するには一度スナップショット取得してスナップショットから復元、コピー作成の際に暗号化可能
暗号鍵の管理
KMSで管理されたCMKにアクセスするにはキーポリシーにてアクセス許可を行う
CloudHSM・・・クライアントサイド暗号化のカギ管理で用いられるハードウエアセキュリティモジュール(HSM)であり、業界規制によりハードウエアを他アカウントと共有することが許容されないなど、より高いレベルのコンプライアンスへの対応可能
転送中のデータ保護
HTTPリクエストはCloudFrontまたはALBでHTTPSに自動的にリダイレクトできる
TLS証明書はAWS Ceertificate Managerを使うことでELB、 CloudFront、Amazon API Gatewayと統合管理可能
ストレージソリューションのコスト最適化
S３のライフサイクルポリシーを活用することによりオブジェクトがS３に格納されてから、その経過時間に応じて保存するストレージクラスをGlaicerに変更したり削除が可能となるのでコスト最適化を測れる
S３ Intelligent-Tieringを活用すると使用パターンに基づいて高頻度、低頻度アクセスの２つでデータを自動的に移動可能
コンピューティングおよびデータベースサービスのコスト最適化
Cost Explorerのレコメンデーションツールを使用して現在の利用状況からどれくらいのコミットメントでコスト削減が見込めるかの確認可能
コストと使用状況レポートデータを使用することにより高度な分析を行うことも可能
料金モデルについて以下に要点を絞ってまとめる
①オンデマンドインスタンス・・・デフォルトの従量課金オプションであり、利用期間のコミット無し
②リザーブドインスタンス・・・常時起動しているキャパシティ予測のしやすいワークロードむけであり、長期(1or3年)利用のコミットによりオンデマンド料金に比べて最大72%割引が適用される。また、インスタンスタイプやリージョン等の指定を行いそれを利用する必要あり
③スポットインスタンス・・・中断可能なスケールをするワークロード向けであり、AWSクラウド内の使用されていないEC2を最大90%割引の低価格で利用可能
④Saving Plans・・・長期(1or3年)利用のコミットによりオンデマンド料金に比べて最大72%割引が適用され、時間当たりの利用料をコミットする
ネットワークアーキテクチャのコスト最適化
CloudFrontはユーザの近くにデータをキャッシュするためデータ転送量の削減に役立つ
VPCエンドポイントの利用によりVPC内のリソースはインターネットを介さずにAWSサービスへの接続が可能になり、結果としてパブリックデータ転送コストとNATゲートウェイのコスト削減可能
DirectConnectはオンプレミス接続において有用であり、複数のVPCで共有することによりコスト最適化可能でありインターネット経由の接続よりも安定化が可能
可用性の高いアーキテクチャやフォールトトレラントなアーキテクチャの設計
Lambdaの利用によりユーザからの要求をトリガーに画像を即座にカスタマイズ
S3の利用により静的コンテンツの保存可能
CloudFrontの利用によりコンテンツURL提供可能
DynamoDBはNoSQL型のデータサービスであるため画像データの保存に適していない
AMIの利用により同一のEC2インスタンス生成可能。具体的には起動済みのEC2インスタンスからＡＭＩを作成し、作成したＡＭＩを利用して別のリージョンでEC2インスタンス起動可能
S3GlaicerはS3に一定期間保管されているデータをバックアップするためのサービスでありリストア作業には時間がかかる
オンプレミスのデータをクラウドに保存する際の適切なソリューション選択について
Storage Gatewayを用いたオンプレミスデータのクラウドへの保存手順
①オンプレミスサーバーにStorage GatewayのVMをインストールしてAWSと接続
②クラウドに保存したいデータをNFSやiSCSIなどのファイルプロトコルを利用してVMをインストールしたサーバーに保存
③Storage Gateway VMがデータをS3に保存
※Storage GatewayのファイルゲートウェイはNFS、SMBを利用可能
ハードウエアアプライアンスはVMをインストールするサーバーをAWSから購入する仕組みであり、購入したサーバーにはすでにStorage Gateway VMがインストールされており接続設定を行うだけでStorage Gateway利用可能
EC2インスタンスの自動復旧に基づくダウンタイムを最小にする方法
CloudWatchアラームでEC2インスタンスを監視して障害発生時に自動でEC2インスタンスの復旧をトリガーする
Lambdaにおいてのトリガーでの対応も同様に可能だが３０分に1回しかトリガーされないためダウンタイムを最小にするという意味で最適ではない
CloudTrailはAPIの使用状況は記録できるが障害の発生は検知不可のため不適切
オンプレミスからAWSへのデータベース移行においてマルチAZ構成のコスト対効果の高さの所以
マルチAZ設定を有効にするだけで実現可能であるためDBインスタンスは稼働系、待機系と２倍かかるが追加の運用コストが不要
オンプレミスとAWSのデータの整合性が取れてダウンタイムがより小さいソリューションの実現
①Route53のヘルスチェック機能により障害発生時のフェイルオーバー可能
②StorageGatewayによりオンプレミスからAWSのストレージサービスに接続してデータやファイルのバックアップが可能
⇒①、②を組み合わせることにより再現可能
今後のVPC増加に対応できるような拡張性に対するソリューションの実現
このようなケースの最適解としてVPCやDirectConnectの中継ハブとして機能するTransitGatewayの利用
TransitGatewayはルートテーブルを持ち複数のVPCやDirectConnect間の接続を単一のゲートウェイで管理可能
TransitGatewayの差異よにより接続先VPCの追加に伴うぴあリングや古メッシュなどの複雑なネットワーク設計を省略化でき拡張性向上
メッセージングアーキテクチャの一般的な使い方
RDSのイベント通知からSNSのトピックを送信してさらに並列非同期処理のためにSQSのキューに格納するという方法がある
上記のアーキテクチャを採用してデータベースの更新をトリガーとして基幹システムの連携を実現する
トリガーについて、LambdaはRDSの更新をトリガーとして直接起動不可であり可能なものとしてはSQSやDynamoDB
画像ファイルがS3に格納されたことをトリガーとしてアプリケーションを実行する疎結合なソリューション
LambdaによりS3にファイルが格納されたことをトリガーとしてLambda関数で実行可能
Lambda関数からDynamoDBテーブルにアイテム挿入可能
メッセージングアーキテクチャの一般的な使い方
RDSのイベント通知からSNSのトピックを送信してさらに並列非同期処理のためにSQSのキューに格納するという方法がある
トリガーについて、LambdaはRDSの更新をトリガーとして直接起動不可であり可能なものとしてはSQSやDynamoDB
画像ファイルがS3に格納されたことをトリガーとしてアプリケーションを実行する疎結合なソリューション
LambdaによりS3にファイルが格納されたことをトリガーとしてLambda関数で実行可能
Lambda関数からDynamoDBテーブルにアイテム挿入可能
・
・
・
・
・
現段階での忘備録は以上とする。
毎日学習は進めているので、最終的にはこの記事を見ることにより試験対策や案件理解の手助けとなるようにまとめていきたい。
やはり実務が一番効率的にマスターできると思うので最初は苦労するかもしれないがAWSの案件についてみたい。。。