AWS認定ソリューションアーキテクト – プロフェッショナルに合格するまで【管理&ガバナンス篇】

AWS認定ソリューションアーキテクトプロフェッショナル試験合格に向けての資料集。以下の資料を何度も読み込んで、手を動かしながら実践を繰り返すことが合格の近道となる。管理ガバナンス に関するサービスはこちら。

カテゴリ サービス名
コンピューティング EC2, ECS, Lambda, Batch, Elastic Beanstalk
ストレージ S3, EFS, Storage Gateway
データベース RDS, DynamoDB, ElastiCache, Redshift
移行と転送 Database Migration Service, Application Discovery Service, Migration Hub, Server Migration Service, Snowball
ネットワーク VPC, CloudFront, Route53, API Gateway, Direct Connect
開発者用ツール CodeCommit, CodeBuild, CodeDeploy, CodePipeline
管理とガバナンス Organizations, Config, CloudWatch, Auto Scaling, CloudFormation, CloudTrail, Config, OpsWorks, Systems Manager
分析 Athena, EMR, CloudSearch, Elasticsearch, Kinesis, QuickSight
セキュリティとコンプライアンス IAM, RAM, Cognito, GuardDuty, Inspector, CloudHSM, AD&SSO, WAF&Shield
モバイル Amplify, Mobile Hub
アプリケーション統合 SNS, SQS

AWS WAF(1)WAFの概要

AWS WAF

AWS WAFは、Amazon API GatewayAmazon CloudFrontApplication Load Balancer に転送される HTTP および HTTPS リクエストをモニタリングできるWAF。

  • 指定したリクエスト 以外の全てのリクエストを許可する
  • 指定したリクエスト 以外の全てのリクエストをブロックする
  • 指定したプロパティに一致するリクエストを カウントする

ことができる。これらを設定する際には、

  • リクエストの発生元の IP アドレス
  • リクエスト送信元の
  • リクエストヘッダーの値
  • リクエストに含まれる 文字列
  • リクエストの 長さ
  • 悪意のある 可能性がある SQLコード の有無
  • 悪意のある 可能性があるスクリプトの有無

などを条件として指定できる。また、 DDoS攻撃の影響を最小限に抑えることが可能な AWS Shield と組み合わせて使用することもでき、これらのサービスを簡単に管理可能な AWS Firewall Manager が用意されている。WAFは、ルールの複雑性が加味された Web ACl Capacity Unit 単位で課金される。

CloudFrontと併用する際には、WAFが返却したレスポンスに応じてカスタムエラーページを表示 したり、 CloudFrontの地理的ブロッキング機能と同時に使用する ことができる。

ACLとルール

Web ACLは、表示された リスト順に評価 され、ルールに一致するリクエストを 許可 , ブロック , カウント することができる。また、どのルールにも一致しないリクエストをどのように処理するかを定める デフォルトアクション を指定することができる。

WEB ACLに追加可能なルールセットである、ルールグループ を規定することができ、あらかじめAWSやベンダーが作成した、マネージドルールグループ を使用/購入することもできる。ルールグループにはデフォルトアクションが設定されておらず複数のWEB ACLに同一のルールグループを適用することができる。

グループ名 WCU 内容 利用シーンと効果
Admin protection 100 公開されている管理ページへの外部アクセスをブロックするためのルール サードパーティーのソフトウェアを実行している場合や、悪意のあるアクターがアプリケーションへの管理アクセスを得るリスクを軽減したい場合
Amazon IP reputation list 25 ボットやその他の脅威に関連付けられている IP アドレスをブロック ボットを軽減したい場合
Core rule set 700 ウェブアプリケーションに一般的に適用可能なルール
Known bad inputs 200 脆弱性の悪用または発見に関連するリクエストパターンをブロックするルール 悪意のあるアクターが脆弱なアプリケーションを発見するリスクを軽減
Linux operating system 200 Linux 固有の脆弱性の悪用に関連するリクエストパターンをブロック 攻撃者がアクセスしてはならないファイルの内容を公開したり、コードを実行したりする攻撃を防ぐ
PHP application 100 安全でない PHP 関数のインジェクションなど、PHP プログラミング言語の使用に固有の脆弱性の悪用に関連するリクエストパターンをブロックするルール 攻撃者が許可されていないコードまたはコマンドをリモートで実行できる脆弱性の悪用を防ぐ
POSIX operating system 100 POSIX および POSIX と同等のオペレーティングシステムに固有の脆弱性の悪用に関連するリクエストパターンをブロックするルール アクセスしてはならないファイルの内容を公開したり、コードを実行したりする攻撃を防ぐ
SQL database 200 SQL Database ルールグループには、SQL インジェクション攻撃などの SQL データベースの悪用に関連するリクエストパターンをブロックするルール 不正なクエリのリモートインジェクションを防ぐ
Windows operating system 200 PowerShell コマンドのリモート実行など、Windows 固有の脆弱性の悪用に関連するリクエストパターンをブロックするルール 悪意のあるコードを実行したりする脆弱性の悪用を防ぐ
WordPress application 100 WordPress サイト固有の脆弱性の悪用に関連するリクエストパターンをブロックするルール

ロギング

ログ記録を有効化することで、WEB ACLで分析されるトラフィックの詳細情報を取得することができる。ログ記録を有効化すると Kinesis Firehose経由で指定した場所にログが保存される

また、CloudWatchアラームで特定のメトリクスをモニタリング することができるほか、CloudTrailによるアクションレコードの保存にも対応している。

FireWall Manager

FireWall Managerを用いることで、AWS WAF Classic ルール、AWS Shield アドバンスド 保護、 Amazon VPC セキュリティグループ を有効化することができ、これにより組織全体の保護を行ったり、リソースの頻繁な追加に対応し、組織全体のDDoS攻撃を一元的に監視することができる。 FireWall Managerを使用するためには、AWS Organizationのメンバーである必要 がある。

AWS認定(2)デベロッパー(アソシエイト)に合格するまで

AWS認定デベロッパー試験合格に向けての資料集。以下の資料を何度も読み込んで、手を動かしながら実践を繰り返すことが合格の近道となる。

出題範囲と学習法

AWS認定デベロッパー試験の問題は、システムを構築する際に、可用性や拡張性コストなどを考慮した上で、実際どのような手法で実装するかについて問われることが多い。AWSが提供するサービスは100を超えるが、本試験を受講する上では、API Gateway, Cognito, DynamoDB, S3, SQS, IAM(STS), Elastic Beanstalk, Elastic Beanstalk, Lambdaなどのデプロイツールやサーバレスアーキテクチャの理解。また、CloudFormation, CodeBuild, CodeCommit, CodeDeploy, CodePipeline, CloudFront, CloudWatch, ElastiCache, Kinesis, RDS, X-Rayなども理解しておくことが必要である。

勉強法は、

  1. サンプル問題集に目を通してレベルを確認する
  2. 以下の資料を読みながら実際に各サービスに触れる
  3. 模擬試験を受講する

で十分合格ラインに行くかと。ちなみに学習時間は2週間ほど。なお、各サービスのドキュメントにベストプラクティスの項目が存在する場合は、該当部分を理解しておく

対策本

対策本はほとんど発売されていない。以下の本が唯一の試験対策本。この本には、各サービスの概要や特徴が簡潔に書かれており、AWSの各サービスの概要を学ぶためには非常に有効。一方で、章末問題と実際の試験問題は異なるので、実際の問題に慣れるためには、模擬試験の受講が必要である。

AWSの概要とセキュリティ

AWS(1)AWSの概要とメリット
AWS(4)Well-Architectedフレームワーク
AWS(5)セキュリティのベストプラクティス

AWS Identity and Access Management

AWS(2)セキュリティの概要
AWS Identity and Access Management(1)IAMの概要
AWS Identity and Access Management(4)STS

AWSの基本サービスの概要

Amazon S3

AWS S3(3)S3の概要
AWS S3(4)使用する上で注意すること

Amazon RDS

AWS RDS(1)Relational Database Serviceの概要

Amazon DynamoDB

AWS DynamoDB(1)DynamoDBの概要

Amazon ElastiCache

AWS ElastiCache(1)ElastiCacheの概要

AWS Lambda

AWS Lambda(1)Lambdaの概要
AWS Lambda(3)使用する上で注意すること

Amazon Kinesis Data Streams

AWS Kinesis(1)Kinesisの概要

Amazon SQS

AWS SQS(1)Amazon Simple Queue Serviceの概要

AWS Elastic Beanstalk

AWS Elastic Beanstalk(1)Elastic Beanstalkの概要

Amazon CloudWatch

AWS CloudWatch(1)CloudWatchの概要

Amazon SNS

AWS SNS(1)Simple Notification Serviceの概要
AWS SNS(2)モバイルプッシュ通知

Amazon Cognito

AWS Cognito(1)Cognitoの概要

AWS API Gateway(3)カスタムログの出力


API Gatewayは、詳細のアクセスログをCloudWatch Logsに吐き出すことができる。CloudWatch Logsへのログ書き込みを行うためには、書き込み権限の取得とログを書き込むロググループの指定が必要となる。

IAMロールの指定

IAM上でAPI GatewayからCloudWatch Logsへの書き込み許可を持つIAMロールを作成する。IAMでは、あらかじめAmazonAPIGatewayPushToCloudWatchLogsと呼ばれるポリシーが用意されているため、このポリシーがアタッチされたIAMロールを作成する。この作成したIAMロールをAPI Gatewayの設定画面上で指定することで、API GatewayはCloudWatch Logsへの書き込み権限を取得する。

ログの指定

次にAPI Gateway上の各APIのログ/トレース設定画面にて、カスタムアクセスのログ記録を有効化する。入力項目は、CloudWatchロググループのARNと、ログ形式の2種類。ログ形式は、JSONやCLFなどの中から選ぶと自動的に入力される。

AWS API Gateway(1)API Gatewayの概要

API Gatewayとは

API Gatewayは、完全マネージドのAPI作成サービス。受信したAPIコールと送出したデータ量に対して課金される。スロットリングによるトラフィック管理ができるため、DDoSやトラフィックの激増にも対応することが可能であり、リミットを超えたリクエストにはHTTPステータス 429が返却される。また、レスポンスはキャッシュ可能であり、レイテンシやトラフィック等を低減することができる。

API Gatewayは、IAMやCognitoを用いたアクセス認証署名付きAPIコールなどを使用することができるために柔軟にセキュリティ管理ができる。また、CloudWatchやCloudWatch Logsを用いた監視が可能で効率的なデバッグとモニタリングを実現している。

![API Gateway]https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/images/BackplaneArch.png

エンドポイント

API Gatewayは、特定のリージョンにデプロイされる。エンドポイントは以下の3種類がサポートされている。エンドポイントは、HTTPSのみサポートされている。

種類 内容
エッジ最適化 CloudFrontネットワークにデプロイ
リージョン リージョンにデプロイ。EC2 インスタンスまたは API と同じリージョン内のサービスから送られる場合に使用すると良い。
プライベート VPCからのみアクセス可能

リソースとメソッド

APIは階層構造となっており、リソースやメソッドをネストすることも可能。指定可能なメソッドは以下の通り。

種類 実行内容
POST 子リリースの作成
PUT 既存リソースの更新
DELETE リソースの削除
PATCH リソースの更新
HEAD テストシナリオに使用
OPTIONS 通信オプションに関する情報を取得する度に使用できる

CROSを有効にするためには、OPTIONSメソッドのプリフライトリクエストに対してAPIが応答することが必要であり、このリクエストに対して、HTTPステータス 200Access-Control-Allow-Method, Access-Control-Allow-Headers, Access-Control-Max-Ageヘッダを含んだレスポンスを返す。これらの挙動には、統合リクエスト/レスポンスのMockタイプを使用する。

リクエストに対して、 URLクエリ文字列パラメータHTTPヘッダHTTPボディを検証し、必須の項目が含まれているかやキャッシュを行うかなどを指定することができる。HTTPボディがapplication/json形式である場合は、JSON Schemaを用いてJSON形式を指定することもできる。

統合リクエスト/レスポンスとマッピングテンプレート

API Gatewayとバックエンドとを接続する内部インタフェース。マッピングテンプレートを用いることで、フロントエンド(API Gateway)とバックエンドのデータ形式を変換することができる。

  • Lambda関数の呼び出し
  • 他のAWSサービスの呼び出し
  • HTTPウェブサイトのアクセス

の3つのバックエンドへのアクセスに対応している。Lambdaプロキシ統合を用いることで、API GatewayとLambdaがより協力に結合され、リクエストヘッダやパス変数などがLambdaに渡される。また、HTTPプロキシとして使用することも可能である。

デプロイ

APIを利用可能とするためには、APIのリソースおよびメソッドのスナップショットであるAPIのデプロイを実施する必要がある。APIをバージョン管理できるために、新しいバージョンを簡単にテストしリリースすることが可能である。

1アカウント1リージョンあたりのAPIの上限は、10000RPSである。これ以上のアクセス負荷にも耐えうる値とする場合は上限緩和申請が必要となる。

エラーコード

API Gateway の代表的なレスポンスコードは以下の通り。

エラーコード レスポンスタイプ 内容
400 BAD_REQUEST_PARAMETERS リクエストパラメータの不整合
400 BAD_REQUEST_BODY リクエストボディの不整合
401 UNAUTHORIZED 認証の失敗
403 EXPIRED_TOKEN トークンの期限切れ
403 ACCESS_DENIED 認証の失敗
403 INVALID_API_KEY APIキーの不整合
403 INVALID_SIGNATURE 署名の不整合
403 MISSING_AUTHENTICATION_TOKEN トークンが見つからない
403 WAF_FILTERED WAFによるブロック
404 RESOURCE_NOT_FOUND リクエスト先が存在しない
413 REQUEST_TOO_LARGE リクエストが大きすぎる
415 UNSUPPORTED_MEDIA_TYPE メディアタイプの相違
429 QUOTA_EXCEEDED クオータの超過
429 THROTTLED スロットルの発生
500 API_CONFIGURATION_ERROR API 設定が無効
500 AUTHORIZER_CONFIGURATION_ERROR オーソライザーへの接続が失敗
500 AUTHORIZER_FAILURE オーソライザーの認証が失敗
504 INTEGRATION_FAILURE 統合に失敗
504 INTEGRATION_TIMEOUT 統合のタイムアウト

AWS RDS(1)Relational Database Serviceの概要

RDSとは

RDSは、AWS内でRDBSを簡単に設定、運用、スケールできるサービスで、データベースのセットアップやパッチ適用、バックアップなどの管理タスクを自動化している。対応しているRDBSは、Amazon AuroraMySQLMariaDBOracleMicrosoft SQL ServerPostgreSQLの6種類である。一部制限事項も存在するため、この制限事項とのトレードオフが許容できない場合は、EC2上でRDBSを稼働させることも検討する。

管理負荷を軽減

RDBSにわずか数分でアクセス可能で、CloudWatchによる監視にも対応しているため、パフォーマンスの問題を簡単に検出することが可能である。また、ソフトウェアのパッチが自動的に適用されるために、常に最新の状態が維持されている。

パフォーマンス

汎用(SSD)ストレージプロビジョンドIOPS(SSD)ストレージから選択することが可能である。

スケーラビリティ

最大32vCPUおよびRAM244GiBまで拡張することが可能で、数分以内にスケーリングすることができる。また、ストレージサイズも柔軟に拡大が可能で、稼働中にダウンタイムなしに最大16TBまでストレージの拡張を行うことができる。また、リードレプリカを使用(=Amazon AuroraMySQLMariaDBPostgreSQLのみ対応)することで、読み込み負荷の高い処理をスケールアウトすることができる。

可用性と耐久性

自動バックアップ機能によって自動的(=1日に1回)に、もしくは任意の時点のスナップショットを保存することもでき最大35日(デフォルトは7日間保持)まで保存可能。また、RDは、5分に1回トランザクションログを保存しているため、これを用いて新たなインスタンスを起動(ポイントインタイムディカバリ)が可能。マルチAZ配置オプションを使用することで、異なるAZのスタンバイインスタンスにデータを複製し、可用性を向上させることができ、ハードウェア障害が発生した場合には、自動でフェールオーバされる。DNSでCNAMEが書き換えられ切り替えには数分要する。なお、スナップショット実行時は、短時間I/Oが停止することに注意が必要

セキュリティ

KMSを使用してデータベースを暗号化することが可能。また、VPC上で稼働させることで独自のネットワーク上で外部と隔離された状態で稼働できる。

AWS S3(3)S3の概要

S3 (Simple Storage Service)とは

S3は、どこからの、どのような量のデータ(通常100バケットまで1ファイル5TBまで)でも保存と取得が可能なオブジェクトストレージ。データは3箇所以上のデータセンタへ自動複製され、
99.999999999% の耐久性を提供している。高い耐久性、可用性、スケーラビリティー、数多くのセキュリテイ機能を持つ。AWS AthenaやS3 Selectを用いることで簡単に、S3内のデータに対してビッグデータ解析を行うことが可能で、さまざまな方法でS3へのデータ転送を行うことができる。

S3には、S3 StanderdS3 Standerd(低頻度アクセス)S3(1ゾーン/低頻度アクセス)Amazon Glacierの4つのストレージが用意されている。S3(1ゾーン/低頻度アクセス)は、地震や洪水といった災害によるアベイラビリティーゾーンの物理的な損失時にデータを失う可能性がある。S3 Standerd(低頻度アクセス)とS3(1ゾーン/低頻度アクセス)は、他の手法で復元可能なデータや原本のコピーを保存する目的で使用する。VPCエンドポイントを用いることで、同一リージョンのVPC内からセキュアにファイル転送を行うことが可能である。また、複数の暗号化、監査ログ、バージョニングにも対応している。

S3は、キーバリュー型のストアであるので、フラットな構造であり、ディレクトリや階層構造は存在しない。フォルダやファイル名に相当するのがキーであり、スラッシュ文字によってディレクトリ構造のように見せることができる。

タイプ 堅牢性 備考
Standard 99.999999999% 3箇所以上にデータ複製
Standard(低頻度アクセス) 99.999999999% 安価だが読み出しに課金される
1ゾーン(低頻度アクセス) 99.99% 低い堅牢性。オブジェクト毎に指定可能。
Glacier 99.999999999% 取り出しに時間(3-5時間)とコストを要する

S3は、ファイルを複数のチャンクに分割して並列アップロードを行う、Multipart Uploadに対応している。ファイルサイズが100MBを超える場合は、このMultipart Uploadを使用することが奨励されている。AWS CLIでは、ファイルサイズによって自動判別されてこの機能が利用される。Glacierに格納されたデータの復元時には、迅速(Expedited)(=1-5分)、標準(Standard)(=3-5時間)、大容量(Bulk)(=5-12時間)の3種類が用意され、それぞれ実行単価が異なる。

また、静的なファイルをS3のみでホステイング可能なWEBサイトホスティング機能を有している。独自ドメインの指定クロスドメインCloudFrontとの連携なども可能。

セキュリティ

アクセス管理

S3はデフォルトでは全てプライベートアクセス権限となっている。アクセス権限は、バケットやオブジェクト単位で指定可能である。IAMユーザ単位でS3へのアクセス権限を指定できる「ユーザポリシー」(=IPアドレスも指定可能)、バケット毎にアクセス権限を指定できる「バケットポリシー」(=IPアドレスレンジやMFA等も指定可能)、バケットやオブジェクト単位で指定可能な「ACL」などが存在する。バケットポリシーは、バケットの所有者のみが設定でき、またACLは、バケットACLよりもオブジェクトACLが優先される。

暗号化

サーバサイド暗号化、クライアントサイド暗号化の両方に対応している。デフォルト暗号化を指定することも可能である。

Pre-signed Object URL

一定時間のみアクセスを許可するURLを発行できる。

通知

バケットにイベントが発生した際に、SNS、SQS、Lambdaに対して通知を行うことが可能。

モニタリング

CloudWatchとCloudTrailによるモニタリングが可能。

料金

通常ははストレージおよびデータ転送に掛かるコスト全ては、バケットの所有者が負担する。しかし、リクエスタ支払いバケットに指定した場合は、リクエストおよびバケットからのデータダウンロードに掛かるコストは、 所有者ではなくリクエストを実行したリクエスタが支払う

バージョニング

バージョニングが有効となったオブジェクトに対してDELETE処理を行った場合、全てのバージョンはストレージに残り削除マーカーが付加される。当該オブジェクトをGETしようとすると404 Not Foundが返されるが、オブジェクトバージョンを指定すると当該オブジェクトを取得可能である。

ライフサイクル

ライフサイクルと呼ばれる、オブジェクトに対するアクションルールをXMLにより規定できる。ライフサイクルによって、オブジェクトを異なるストレージクラスに移行したり、オブジェクトを削除したりすることができる。Glacierは削除や上書き、アーカイブリクエスト、復元に対して費用が発生する。ただし90日以上アーカイブされているオブジェクトに対する削除および上書きは無料である。

AWS CloudWatch(2)システム運用における監視項目

AWSでシステム構築を行う場合、基本的にはこのCloudWawtchのみの監視で十分なことが多い。様々な監視項目が存在するが、システム運用を行う際に特に監視する必要のある項目は以下の通り。

DynamoDB

多くの項目がデフォルトで 1 分ごとにデータを送信するが、5 分間隔で送信されるデータも存在する。事前に設定した容量(スループット)が十分であるかを監視しておくと良い。

  • ProvisionedReadCapacityUnits
  • ConsumedReadCapacityUnits
  • ProvisionedWriteCapacityUnits
  • ConsumedWriteCapacityUnits

EC2

Amazon EC2 はデフォルトで 5 分ごとに CloudWatch にデータを送信する。インスタンスを作成する際に、「詳細モニタリングを有効」にチェックを入れることでこれを 1 分ごとに変更することができるCPU使用率を監視しておくと良い。メモリやディスクのメトリクスを取得するためには、CloudWatch Agentをインストールする必要がある

  • CPUUtilization

Kinesis

事前に設定した容量(シャード数)が十分であるかを監視しておくと良い。

  • PutRecords.Records
  • IncomingRecords
  • GetRecords.Bytes
  • IteratorAge

AWS CloudWatch(1)CloudWatchの概要

CloudWatchとは

CloudWatchは、AWSの各リソースを監視することのできるサービスである。AWSでシステム構築を行う場合、基本的にはこのCloudWawtchのみの監視で十分なことが多く、Zabbixなどの他の監視環境を構築する必要がない。フルマネージドのサービスの場合は自ら監視環境を構築することができないため、CloudWatchによる監視が必須となる。また、CloudWatch Logsを用いることで、各リソースのLogデータをCloudWatchで監視することが可能になる。CloudWatch Logsは、ログデータを無期限で保存する

CloudWatchの概要

CloudWatchは、NameSpace(AWS/service)と呼ばれるAWSサービス単位の項目とMetricsと呼ばれる時系列のデータポイントセットから構成され、これらを組み合わせて指定することで任意の項目を確認することが可能となる。CloudWatch上のデータ(CloudWatch Logsのデータを除く)は削除することはできず、15ヶ月経過したデータポイントは自動的に削除される。データポイントに付随するタイムスタンプは、UTC時刻であることが望ましく、データの更新間隔は最短1分となっている。

開発環境か本番環境か、実行しているリージョンはどこかなど、同じMetricsであっても環境によってデータが異なる。同一名称のMetricsの中から特定のMetricsを一意に識別するためにDimentionと呼ばれる名前と値のペアを持つことができる。CloudWatchは、ソースが異なっていてもNameSpaceとMetricsが同一のMetricsは1つのMetricsとして扱う

データポイントの種類 保持期間
60秒間隔未満 3時間
1分 15日間
5分 63日
1時間 455日

アラームを使用することで、単一のMetricsを監視し、一定期間における閾値とMetrics値に応じてアクションを実行することができる。アクション機能を用いることで、各アラームに対する通知やAutoRecovery, AutoScaleなどのアクションを規定することも可能である。

CloudWatch Agent

統合 CloudWatch エージェントを使用することで、EC2やオンプレミスサーバからより多くのメトリクスを取得することができる。例えば、通常のCloudWatchでは計測できないサーバのメモリ量ディスク量などのメトリクスを追加で取得できる。また、メトリクスだけでなくサーバ内のログを収集して、CloudWatch Logsに送信することもできる。

EC2には、デフォルトではCloudWatchエージェントはインストールされていないため、Systems ManagerやCloudFormationなどを用いて追加でインストールする必要がある。なお、過去にはCloudWatch Logs エージェントが使用されていたが、現行バージョンは統合 CloudWatch エージェントであるため、特段の理由がなければ統合 CloudWatch エージェントを使用する。

AWS EC2(3)AMIとインスタンス

AMI

AMI(Amazon Machine Image)は、EC2インスタンスの起動に必要な情報を提供するイメージファイルで、

  • OSやアプリケーションなどのルートボリュームのテンプレート
  • 起動を許可するAWSアカウント
  • インスタンスにアタッチするボリュームのマッピング

などの情報が含まれている。

AMIは、AWSや様々な組織が公開しており、これを利用することができる。特にAmazon Linuxは、AWSが提供しているRHEL系のAMIで、AWS CLI Amazon EC2 API 等がパッケージに含まれているため便利で使い勝手が良い。また、自身が作成したインスタンスから生成したAMI(カスタムAMI)を登録/利用することもできる

なお、AMIは同一リージョン内や別のリージョンにコピーを作成することや、他のAWSアカウントとイメージを共有することが可能である。別リージョンにバックアップシステムを構築する場合、AMIのコピーはシステム構築の有用な手段となる。AMIの共有は、公開範囲をパブリックに指定するか、「イメージパーミッションの変更」設定から、許可するAWSアカウントの追加を行う。他者が公開しているAMIを利用する際は、機密データが第3者に送信されていないかや、認証情報が事前に設定されていないかなどを十分に検証する必要がある。

リージョンをまたがるコピー

作成したAMIを別リージョンで使用する際は、AWS CLIのリージョン設定やプログラムのデフォルトリージョン設定をハードコーディングせずに、シェルスクリプト等で変更できるようにしておくと良い。自身のリージョン情報を取得するには、AWS CLIから以下のコマンドを入力する。

 $ curl -s https://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//g' 

AMIの作成

既存のインスタンス、もしくはスナップショットからAMIを作成することが可能である。AMIの作成は、インスタンス上のすべての動作を停止し、作成プロセス中に一貫した状態が保たれるようにするために、インスタンスをシャットダウンしてから行う。自身で作成したAMIを共有する場合は、以下のように、共有キーやコマンド履歴の削除等の対策を行う。

$ sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub
$ shred -u ~/.*history
$ history -c
$ exit

インスタンスからの Linux AMI の作成

ストレージ

ストレージは以下の2種類が存在する。どちらのデバイスから起動させるか選択することも可能であるが、高速で永続的なEBS-basedの起動方法が奨励されている。

Instance Store

  • EC2と不可分の内蔵ディスクで、EC2をTERMINATEするとクリアされる。ただし、再起動ではクリアされない
  • インスタンス停止(STOP)することができない。
  • 無料

instance store-backed のインスタンス

Elastic Block Store

  • ネットワークで接続されたディスクで、EC2とは独立しており、別途課金される。同じアベイラビリティゾーン内でレプリケーションされるため、高い可用性を有している。
  • デフォルトでは、DeleteOnTermination フラグが true に設定されているので、TERMINATEすると消去されてしまうことに注意が必要である。消去されたボリュームは、ゼロで上書きされて他のアカウントで使用される。機密データを有している場合は、暗号化の検討が必要である。
  • スナップショットを取ることが可能である。スナップショットは、過去のスナップショットとの差分として記録される。スナップショットを取得する際には、EBSをアンマウントすることが望ましい。一方で、スナップショットが開始されれば、スナップショット取得処理中であってもEBSをアタッチして使用して問題ない
  • インスタンスとEBSボリュームはネットワーク経由で接続されているため、他の通信の影響を受ける。EBS最適化インスタンスを利用することで、インスタンスとEBSとの間のスループットが保証され、他の通信の影響を受けない。

Amazon EBS-backed インスタンス

容量と性能

汎用SSD(gp2)のパフォーマンスは、ボリュームサイズに比例する。つまり、小さい容量のEBSの場合は、I/O性能も低い。したがって、高頻度のI/Oが発生する可能性があるアプリケーションが動作する場合などは、使用する容量が低くても、I/Oの性能を向上させるために、大きな容量を設定しておく必要がある。

各ボリュームは、最初に540万I/Oクレジットを受け取り、標準性能を超えたI/O処理(バースト)は、このクレジットから消費されていく。一方、標準性能を下回るI/Oであった場合はクレジットに加算されていく。ただし、加算できるクレジットは、初期値と同じ540万I/Oクレジットまで。クレジットが枯渇するとバースト性能を利用できなくなり、標準性能で頭打ちとなる。なお、汎用SSD(gp2)は、

  • 容量が33.4GB以下であれば、標準性能100IOPS
  • 容量が1000GB以下であれば、3000IOPSのバースト性能を利用可能
  • 容量が3333GBに標準性能10000IOPSに達して、容量16TBまでこの性能を維持

と定義されている。また、スループットは、170GB以下では128 MB/秒170GBを超えると160MB/秒である。

インスタンス

概要

  • EC2は、1500MTUに加えてジャンボフレームをサポートする。
  • ルートデバイスがEBSの場合は、インスタンスタイプを変更することが可能である。このときインスタンスIDは変更されない。パブリックアドレスは変更される。インスタンスタイプを変更する場合は、インスタンスを一度停止する必要がある。

インスタンスのライフサイクル

インスタンスは、以下のライフサイクルで動作する。インスタンスがStopのときは課金されない。ただし、EBSボリュームに対する課金は継続される。時期やタイミングによっては、EC2のリソースが枯渇し新たなインスタンスが起動できない場合もあるので、リソースを確保しておきたい場合は、インスタンスを作成し、使用するまで停止しておくとよい。

インスタンスのライフサイクル

インスタンスを再起動した場合は、同一ハードウェアで起動し、ボリュームやネットワーク設定等は前回起動の情報を保持する。一方、インスタンスを一度停止し起動した場合は、別のハードウェアで起動し、これらの情報は引き継がれない。ハードウェア障害が発生した場合など、明示的に別のハードウェアでインスタンスを起動する必要がある場合には、再起動ではなく停止と開始を行う

インスタンスの公開鍵

EC2に使用するSSHキーペアは、リージョンごとに別管理であるため、他のリージョンでEC2を使用する場合、通常は別途新たにキーペアを作成する必要がある。ただし、これでは管理する際に問題が生じるので、共通のキーペアで運用すると良い。手元の秘密鍵から公開鍵を生成し、AWSマネージメントコンソールから登録を行う。

キーペアのインポート

インスタンスの時刻

デフォルトでは UTC(協定世界時間)時間帯に設定されている。他のタイムゾーンを設定する場合は、起動時に以下を実行する。

vi /etc/rc.local
ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

インスタンスの復旧

ハードウェア障害が発生した場合に、自動的に再起動を行うことが可能なCloudWatchアラームを作成することができる。復旧したインスタンスは、ボリュームやネットワーク設定等は前回起動の情報を保持する。自動復旧は、1インスタンスにつき1日3回までである。

また、AWSがインスタンスの再起動や停止/開始、メンテナンスを事前に予告して実施する場合がある。再起動には、自身でスケジューリング可能なインスタンスリブートと、強制的に再起動されてしまうシステムリブートがある。また、ネットワークや電源のメンテナンスが実施される場合もある。

インスタンスメタデータ

実行中のインスタンスのメタデータは、以下のURLから取得することが可能である。AMIのIDや、ホスト名、リージョン、ネットワーク設定、セキュリティグループ名などを取得することができる。

https://169.254.169.254/latest/meta-data/