AWS Solution Architecture Associate

試験勉強メモ

Sep,28,2014 Tadayasu Yotsu

AWS Solution Architect Associate資格を取得する際に勉強したメモです。

以下のマイスターシリーズの資料などを参考にしてます。

http://aws.amazon.com/jp/aws-jp-introduction/

AWS(Amazon Web Services)のサービス一覧

区分 サービス 備考

Compute Networking

EC2 仮想マシン

Auto Scaling EC2のキャパシティを自動的に拡大・縮小する機能

ELB(Elastic Load Balancing) ロードバランサ

Route53 DNSサービス

VPC(Virtual Private Cloud) IPSecトンネルモードを使用して、データセンターにあるゲートウェイと AWS にあるゲートウェイ間のセキュアな接続を構築可能

Direct Connect

インターネットを介さずにAWSのクラウドを利用できるようになるため、通信の安定化やセキュリティの強化が期待できる。AWSのクラウドに直結した専用ゲートウエイのポートを、従量課金で利用できるというサービス。AWSはデータセンターの場所を顧客に開示していないため、ユーザー企業が直に接続することはできない。その代わりに用意したアクセス手段が、AWS Direct Connect。

区分 サービス 備考

Storage Content Delivery

S3 耐久性の高い分散型データストレージ

Glacier 低コストのストレージサービス。データのアーカイブやバックアップに向いている。おそらくテープシステム

Storage Gateway オンプレ上のデータをS3などに移動させるためのゲートウェイ。VMwareの仮想マシンアプライアンスとして提供されている。

EBS(Elastic Block Store) ブロックレベルのストレージボリューム。EBS ボリュームはアベイラビリティーゾーン内で自動的にレプリケートされる。

Cloud Frontコンテンツ配信(静的またはストリーミング）のウェブサービスで、S3 のオブジェクトのコピーを、世界中のエッジロケーションで分散してキャッシュし、配信できる

Import/Export AWS内外へ大容量データの転送を高速化

Database

DynamoDB NoSQLデータサービス

RDS MySQL,Oracle,SQL Server,PostgresなどRDBのサービス

RedShift

ペタバイト規模のデータウェアハウスサービス。クエリパフォーマンスを高速化するために列指向ストレージ技術が採用されており、複数のノードにまたがるクエリの I/O 効率と並列度が向上。Redshift では、PostgreSQL JDBC および ODBC の標準的なドライバが使用されているので、既存のさまざまな SQL クライアントをそのまま使用可能。

ElasticCache

キャッシュサービス。memcached or Redisを利用可能。データベースへの問い合わせ結果を一時的にキャッシュすることで，データベースへのアクセス回数を減らし，動的なウェブアプリケーションの高速化やスケーラビリティの向上のために利用。

区分 サービス 備考

Deployment Management

CloudFormationEC2やELBなどを使ったAWSサービスのシステム構築を、設定ファイル（テンプレート）を元に行えるサービス。テンプレートを自由に作成できるため、自分好みのシステム構成が可能

CloudTrail AWS APIに対するコールを記録し、指定したAmazon S3バケットにログファイルを保存することができるサービス。

CloudWatch AWSの各種リソースをモニタリングするためのWebサービス

Elastic Beanstalkアプリケーションをアップロードするだけで実行可能。コンテナが整備されている。EC2インスタンスが立ち上がるのでsshログイン可能。tomcatなどが動いてると思えばよい。

IAM AWS操作（javaなどでS3などのサービスを利用/アクセス）をセキュアに行うための認証・認可の仕組み。

OpsWorks開発者やシステム管理者向けの統合アプリケーション管理ソリューション。アプリケーション全体のライフサイクルをモデル化、コントロール、自動化が可能。Chef-soloが動いてる。

Analytics

EMR(ElasticMapReduce) Hadoopの環境が準備されたサービス。

Kinesis ストリームデータのリアルタイム処理を行うプラットフォーム

Data Pipeline

指定された間隔で、信頼性のあるデータ処理やデータ移動（AWS のコンピューティングサービスやストレージサービス、ならびにオンプレミスのデータソース間）を行うことができるウェブサービス。cronなどの実行コントロールをEC2やローカル端末などのOS内部ではなく、AWSのサービス上に持つことが可能になる。

区分 サービス 備考

App Services

AppStream

大量のリソースを使うアプリケーションやゲームをクラウドからストリーミングできるようにする、柔軟性が高く低レイテンシーのサービス。スマホなどの端末から受け取った情報を元に、サーバー側でゲームの映像などを処理して、処理した結果をストリーミングでモバイルに返すことが出来るサービス。サーバー側でゲーム映像のレンダリングなどの重い処理をやっておき、その結果だけを返す事により、貧弱な端末でも高度なアプリケーションを動かすことが出来る。

CloudSearchAWS クラウドにおける完全マネージド型サービスであり、ウェブサイトまたはアプリケーション向けの検索ソリューションを容易に設定、管理、拡張縮小できる。Apache Solrが使われている。

SWF(Simple Workflow Service) 分散システムにまたがる処理ステップをコーディネート

SES(Simple Email Service)

発信専用のメール送信サービス。Postfix や Sendmail のような MTA 的な機能を、API を使って利用できる。これまでメールを送るときは、MTA のセットアップや、外部の SMTP サーバを利用しないと送ることができなかったが、SES を使えば、プログラム的にメールを送信できるので、面倒なメールサーバの調達・準備から解放される。

SNS(Simple Notification Service)トピック(SNS の固有名詞であり、通知するメッセージを入れておく入れ物の名前)を作成しておけば、購読/配信といった手順が準備されているので、クラウドからアプリケーションまたは人に通知する簡単な方法を提供

SQS(Simple Queue Service) コンピュータとアプリケーションの間でメッセージをやりとりする際に、それらを保管するための、信頼性の高い、拡張性のある、キューサービス

Elastic Transcoder 高いスケーラビリティ、使いやすさ、経済性を実現し、様々なデバイスに対応した動画ファイルをトランスコードできるフルマネージドサービス

区分 サービス 備考

Applications

WorkSpaces VDI(VMware ViewやCitrixXenDesktopみたいなもの)

ZocaloAmazon Zocalo is a fully managed, secure enterprise storage and sharing service with strong administrative controls and feedback capabilities that improve user productivity.

Mobile Services

Cognito Amazon Cognito is a simple user identity and data synchronization service that helps you securely manage and synchronize app data for your users across their mobile devices.

Mobile Analytics Amazon Mobile Analytics is a service that lets you easily collect, visualize, and understand app usage data at scale.

SNSトピック(SNS の固有名詞であり、通知するメッセージを入れておく入れ物の名前)を作成しておけば、購読/配信といった手順が準備されているので、クラウドからアプリケーションまたは人に通知する簡単な方法を提供

その他 CloudHSM 鍵管理サービス。Luna SAが使われている。

AWSでよく利用されているサービス（基本サービス）について少し詳しく調べる。

Cloud Front:コンテンツ配信概要

ユーザからのアクセスを、最も近いエッジサーバに誘導することで、ユーザへの配信を高速化 エッジサーバでは、コンテンツのキャッシングを行い、オリジンに負荷をかけず効率的に配信する CFの名前解決をDNSに問い合わせ、CFのDNSが地理情報に応じた、最適な（地理的に近い）エッジサーバのアドレスを返す。 キャッシュされるコンテンツの1ファイルの最大サイズは20GB デフォルトでは、各オブジェクトはエッジロケーションに 24 時間保持された後に有効期限切れになる Distributionを作成　※Max100 1アカウントあたり、最大100 個の CloudFront オリジンアクセスアイデンティティ 1 つのオリジンアクセスアイデンティティを、必要な数のディストリビューションに追加できるため、通常は 1 つのオリジンアクセスアイデンティティで十分 信頼された署名者の登録はウェブディストリビューションの場合はキャッシュ動作ごとに最大 5、RTMPディシュとリビューションの場合はディストリビューション毎に最大５． Download（Web） or Streaming(RTMP)を選択 オリジンのドメインとしてS3のバケットを選択 HTTP/HTTPSをサポート GET, HEADはエッジにコンテンツがキャッシュされる GET, HEAD以外は、エッジがProxyとして動作し、毎回オリジンにリクエストが送信される オリジンはインターネット経由でアクセスできる必要がある

機能 マルチオリジン機能　※BehaviorsのPath Pattern(正規表現)を利用したオリジンの振り分け

オリジンはDistribution毎に10個まで登録可能 振り分けルール(Behaviors)もDistribution毎に10個まで登録可能 Behavior毎にキャッシュポリシーやオリジンへのアクセスルール指定が可能

署名付きURL 信頼された署名者のキーペアからプライベートキーを使用して、URL の一部を署名。 ユーザーが署名付き URL を使用してオブジェクトにアクセスすると、CloudFront は URL の署名部分を無署名部分と比較して、URL が改ざんされていないことを確認する。CloudFront は、URL が有効であることも確認します。例えば、URL 内の有効期限切れ日時が経過していないことを確認。 IAM ユーザーは CloudFront キーペアの作成を許可されてないので。信頼された署名者として IAM ユーザーを使用することはできない。CloudFront キーペアの代わりに Amazon EC2 キーペアを使用することはできない。AWSアカウントでキーペアを作成する。 設定手順

AWS Consoleからセキュリティ認証情報ページにあるCloudFront Key Pairsから鍵ペアを作成 信頼された署名者をディストリビューションに追加 ※ディストリビューション作成時に設定可能

Cloud Front:コンテンツ配信

Tips：オリジンアクセスアイデンティティを使用して Amazon S3 コンテンツへのアクセスを制限する ディストリビューション作成する際（後でも可能）にオリジンアクセスアイデンティティを作成し、S3バケットのパーミッションでオリジナルアクセスアイデンティティのみ許可し、他を拒否すれば、CloudFront経由しかアクセスさせないようにできる。 http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html 通常、Amazon S3 バケットを CloudFront ディストリビューションのオリジンとして使用する場合、すべてのユーザーにバケット内のオブジェクトの読み取り許可を与えます。これにより、すべてのユーザーが CloudFront URL または Amazon S3 URL を使用してオブジェクトにアクセスできます。CloudFront は Amazon S3 URL を公開しませんが、アプリケーションが何らかのオブジェクトを Amazon S3 から直接供給したり、Amazon S3 内の特定のオブジェクトへの直接リンクが公言されたりした場合、ユーザーは Amazon S3 URL を知ることができます。 !CloudFront 署名付き URL を使用して Amazon S3 バケット内のオブジェクトへのアクセスを提供する場合は、ユーザーが Amazon S3 URL を使用して Amazon S3 オブジェクトにアクセスできないようにすることが必要になる場合もあります。ユーザーが Amazon S3 内のオブジェクトに直接アクセスすると、ユーザーは CloudFront 署名付き URL によって提供される制御をバイパスします。これには、URL が有効期限切れになった場合の制御や、オブジェクトへのアクセスに使用可能な IP アドレスの制御が含まれます。また、ユーザーが CloudFront URL と Amazon S3 URL の両方を使用してオブジェクトにアクセスする場合、CloudFront アクセスログが不完全になり、役に立たなくなります。 !特別な CloudFront ユーザーであるオリジンアクセスアイデンティティを作成することで、Amazon S3 コンテンツへのアクセスを制限します。オリジンアクセスアイデンティティにオブジェクトへのアクセス許可を与え、他のすべてのユーザーから許可を削除するように、Amazon S3 許可を変更します。ユーザーが CloudFront URL を使用して Amazon S3 オブジェクトにアクセスすると、CloudFront オリジンアクセスアイデンティティがユーザーに代わってオブジェクトを取得します。ユーザーが Amazon S3 URL を使用してオブジェクトへのアクセスを試みると、ユーザーはアクセスを拒否されます。オリジンアクセスアイデンティティには、Amazon S3 バケット内のオブジェクトにアクセスするための許可はあるが、ユーザーにはない。 !①オリジンアクセスアイデンティティを作成してディストリビューションに追加 ②オリジンアクセスアイデンティティのみが読み取り許可（または読み取りとダウンロードの許可）を持つように、Amazon S3 バケットに対する許可またはバケット内のオブジェクトに対する許可を変更

Cloud Front:コンテンツ配信

Tips：署名付きのURLからのアクセスのみ受け付けるように制限することによって、コンテンツにアクセス制限をかける

署名用の鍵ペアを作る->Distribution作成時にSigned URLを有効化-> ロギング　※任意のS3バケットにアクセスログを格納 !ユースケース

Adobe FMSを使用したダウンロード、ストリーミング、ライブストリーミングをサポート 静的コンテンツ、動的コンテンツのプロキシ要求をオリジンサーバにキャッスすることによるウェブサイト全体またはウェブアプリの配布 ソフトウェアや大容量ファイルの配布 記録済みメディア及びライブイベントのストリーミングを使用したメディアファイルの配布 プライベートコンテンツの配信

http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html

特定の国からのみアクセス可能/不可能の設定もできる　※地理的ブロッキング http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/RestrictingCFDistributionsByLocation.html

コンテンツの配信場所に関して地理的な制限がある場合、CloudFront とサードパーティの位置情報サービスを使用して、コンテンツのディストリビューションをリクエストの場所に基づいてコントロールできる。例えば、著作権上の理由でコンテンツの配信が許可されない国からリクエストを受け取った場合、そのリクエストをブロックし、状況を説明するメッセージをリクエスタに表示できる。

Cloud Front:コンテンツ配信

S3:ストレージ概要

Webストレージ。オブジェクトストア、ファイルシステムではない ３箇所以上のDCに冗長に保持。 99.999999999％の耐久性 S3の廉価版であるRRSの耐久性は99.99% バケット（オブジェクト置き場）名はグローバルに一意　※最大100バケット/アカウント。バケット内には無制限にオブジェクトを置ける。 1オブジェクトのサイズは5TBまで。※オブジェクト毎にURLによるアドレスが付与。 Write Once Read Many(WORM) 結果整合性　※厳密な一貫性を要求する考え方ではなく、結果的に一貫性が保たれればよいという考え方。そのうち全体に反映されるよって考え方。 利用した容量だけ課金 リージョンに保存されたオブジェクトは明示的に転送されない限り他のリージョンには転送されない REST,SOAPインタフェースを提供 階層構造ではなくフラット構造 暗号化　※デフォルトではoff。アップロードする際に選択。onにすると自動的に暗号化される。 アクセスコントロール　※S3ポリシー、ACL,IAMを使用してルールを定義する。バケット及びオブジェクトにポリシーを適用する。 オブジェクトのライフサイクル管理　※オブジェクトの自動管理。有効期限切れのオブジェクトはS3から永久に削除。バージョニングとは併用不可。

機能機能 概要

マルチパートアップロード機能 巨大なオブジェクトを複数のチャンク/パートに分割してアップロード パートあたり5GBを上限としてアップロード。最大10,000パートをサポート。

Webホスティング機能 静的なWebサイト構築機能。スケールするWebサーバが構築の必要なくすぐに使える。データはS3にあるので消える心配がない。可用性が高くWebサーバのマネージが必要ない

バージョニング機能 重要なデータを保護する機能。バージョン管理下にあるオブジェクトは削除されない。バケットに対して行う。ユーザの誤操作による削除防止に有効

アクセスロギング S3バケットへS3のアクセスログを保存。　※デフォルトでは出力しない。

認証・認可

IAMポリシー、バケットポリシー、ACLでデータを保護する。 IAMポリシー：IAMユーザレベルでのコントロール。アカウント内で複数ユーザを作成し、セキュリティクレデンシャルや権限を付与することが可能。 S3バケットポリシー：バケットオーナだけが適用可能。バケットレベルでのAllow/Denyやオブジェクトの権限のDenyなど

オブジェクトの期限付き保存 バケット単位でオブジェクトの生存期間を指定可能

CORS クロスドメインでリソース取得が可能

Webページリダイレクト リダイレクトルールを渡して条件を満たす場合のみリダイレクトさせることができる。

S3-Glacier連携一定期間経過したS3上のファイルを自動的にGlacierへ退避。 インデックス情報はS3で管理 取り出しに3-5時間かかる

Pre-signed URL(期限付きURL)

オブジェクトのURLを引数に有効期限付きのURLを生成し、一時的に見せたいユーザには有効期限月のURLを通知する。AWSアクセスキーとシークレットキーが必要。

S3:ストレージTips キー名でハッシュをとってパーティションに分けているみたいなので、先頭部分にランダム文字列を入れ、パーティションをばらけさせると性能があがる。 レンジGETを利用すれば、マルチスレッド環境ではより高速にダウンロード可能。※CloudFrontはレンジGETをサポートしている。

IAM:認証認可概要

AWS操作（javaなどでS3などのサービスを利用/アクセス）をセキュアに行うための認証・認可の仕組み。 APIやマネジメントコンソールからの アクセスに対して、権限をチェックする AWS のリソースに対するどのリクエストにおいても、認証情報が必要になる。それにより、AWS はユーザリソースにアクセスできる権限があることを確認できる。ユーザはアクセスキー（アクセスキー ID およびシークレットアクセスキー）を使用し、AWS に対してプログラムによるリクエストをすることができる AWSの利用者に対する認証と、アクセスポリシーを管理 1AWSアカウントでユーザは5000、グループは10まで作成可能 権限はJSON形式で記述。 認証情報

Rest API ：　アクセスキー、秘密キー マネージメントコンソール： ユーザ名、パスワード SOAP API： X.509証明書

多要素認証（MFA）　※推奨オプション マスターアカウント　※root/Adminと同じ マスターユーザはマネージメントコンソールへのログイン、アクセスキー、秘密キーを保有。 マスターアカウントの運用方法 マスターカウントからアクセスキー/秘密キーを使用することは禁止　★ 物理的なMFAをマネージメントコンソールログインに適用 ★

機能 IAMポリシー AWSアクセスに対する権限設定 Action:操作自体に対する設定 Resource:操作対象に対する設定　※ARNで記述 Condition:Resourceに対するActionを許可/拒否するかどうか条件設定

アクセス制限は複数設定可能。優先順位は　default Deny < Allow < 明示的なDeny コマンドライン実行時にauth-dry-testオプションを付加することにより、実際のサービスを動かすことなく操作の実行可否を確認できる。 ユーザベースポリシー：ユーザに設定するポリシー（ユーザが何をできるか）

リソースベースポリシー：リソース（S3バケットやキューなど）に設定するポリシー　※特定のアドレスからしか許可しないなど。 クロスアカウントアクセス　※AWSアカウントを超したアクセス許可

機能 IAMロール

AWSサービスやアプリケーション等、エンティティに対してAWS操作権限を付与するための仕組み ※例えば実行するアプリケーションにロールを付与する事で、そのアプリケーションからAWSを操作出来るようになる IAMユーザーやグループには紐付かない 設定項目は、ロール名とIAMポリシー IAMロールを利用する事で、インスタンスと鍵管理を分離し、管理の簡素化とキーローテートによる、よりセキュアな運用が可能になる。 ※IAMロールを使わない時、プログラムに認証情報を埋め込みセキュアではない。 ex)IAMロール使わない時 AWSCredentials credentials = new BasicAWSCredentials(“アクセスキー”,”シークレットキーID”); AmazonEC2 ec2 = new AmazonEC2Client(credentials);” ec2.describeInstances(); ex)IAMロール使った時 ※IAM Role適用のインスタンス上では、認証情報の設定が不要 AmazonEC2 ec2 = new AmazonEC2Client();” ec2.describeInstances(); !IAM Role for EC2 instances EC2インスタンスに、指定のロールを付与する機能 EC2起動時にロールを指定すると、認証情報がメタデータに設定される。 認証情報はSTS(Security Token Service)で生成。※インスタンス毎に異なるキー。有効期限あり。 アプリケーションから認証情報を取得し、AWSサービスへアクセス　※アクセスキーID、シークレットアクセスキー、セッショントークンを取得

AWSCredentials credentials = new BasicAWSCredentials(

AmazonEC2 ec2 = new AmazonEC2Client(credentials);” ec2.describeInstances();

AmazonEC2 ec2 = new AmazonEC2Client();” AmazonEC2 ec2 = new ec2.describeInstances();

機能 Security Token Service(STS) 一時的に利用するトークンを発行するサービス 動的にIAMユーザーを作成し、ポリシーを適用できる STSはユーザー数制限なし IAM Role for EC2は、このSTSを利用

!Identity Federation 企業・組織の認証機能と、AWSの認証を紐づける機能 ※例えばLDAP認証したユーザーに対してS3のアクセス権をつける、といった連携が可能 認証したユーザーごとにTemporary Security Credentials（一時的なアクセスキー）を発行

Best Practice http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/IAMBestPractices.html AWS アカウントのアクセスキーをロックする。

アカウントに対する一連の AWS アクセスキーを持っている場合は、削除。削除せずに保持したい場合は、定期的にアクセスキー認証情報を変更。 AWS アカウントのパスワードやアクセスキーを決して他者に開示してはいけない AWSアカウントに対してMulti-Factor Authentication（MFA）を使う

!個々の IAM ユーザーを作成する

IAM ユーザーを作成し、IAM ユーザーに管理者特権を与え、それらの IAM ユーザーをお客様の全作業で使用する。お客様のアカウントにアクセスする人に対して個別 IAM ユーザーを作成することにより、IAM ユーザーそれぞれに一意の認証情報を設定することができる

!IAM ユーザーへのアクセス権限を割り当てるためにグループを使う

個々の IAM ユーザーに対してアクセス権限を定義するよりも、ジョブ機能に関連のあるグループを作成し（Admins、Developers、Accounting など）、各グループに関連のあるアクセス権限を定義して、IAM ユーザーをそれらのグループに割り当てる方が便利です。この場合、IAM グループ内のすべてのユーザーが、同じアクセス権限を共有します。そうすることで、グループ全体の変更を一括して行うことができます。

!最小限の特権を認める

IAM ポリシーを作成するとき、最小限の特権を認めるという標準的なセキュリティーアドバイスに従う。ユーザーが何をする必要があるのかを決定し、それから各ユーザーに見合ったポリシーを作成するようにする。同様に、それぞれのリソース（Amazon S3 バケットのような）ごとにポリシーを作成することにより、誰がそのリソースにアクセスできるのかをはっきりと識別することができ、各ユーザーに対し最小限のアクセス権限を与えることができる。最初は最小限のアクセス権限から開始し、必要な場合には追加のアクセス権限を認める方が、最初にあまりにも寛大にアクセス権限を許し、後に規制を厳しくしようとするより安全。

Best Practice ユーザーのために強度の高いパスワードを設定する

ユーザーが自分のパスワードを変更できるようにした場合、強度の高いパスワードを設定するよう確認。IAM コンソールの Password Policy セクションでは、パスワードポリシーのオプションを選択できるようになっており、パスワードの最小文字数やアルファベット以外の文字が必要かどうか等を設定できまる。

!特権ユーザーに対して、MFA を有効化する

特権のある IAM ユーザー（注意して扱うべきリソースにアクセスが許されているユーザー）に対して multi-factor authentication（MFA）を有効化することができる。MFA により、ユーザーは独自の認証コード（ワンタイムパススワード、または OTP）を作成するデバイスを使用することができる。その場合、ユーザーは自身の通常の認証情報（ユーザーネームやパスワードなど）および OTP を提供しなければならない。MFA デバイスは、ハードウェアの特定部品のほか、またはスマートフォンで作動するアプリのような仮想デバイスでも可能。

!Amazon EC2 インスタンスで作動するアプリケーションに対し、ロールを使用する

Amazon EC2 インスタンスで作動するアプリケーションは、他の AWS サービスにアクセスするために認証情報が必要。アプリケーションに認証情報を安全な方法で提供するには、IAM ロールを使用。IAM ロールは独自のアクセス権限を持ったエンティティではありますが、ユーザーまたは グループではありません。また、IAM ユーザーが持っているような永続的な自身の認証情報は設定されていません。その代り、IAM ロールは他のエンティティにより引き受けられます。認証情報は仮定のアイデンティティに関連付けられるか、IAM が動的に一時的な認証情報を提供するか（Amazon EC2 の場合）のどちらかです。Amazon EC2 インスタンスの起動時に、起動パラメータとしてインスタンスのロールを特定することができます。EC2 インスタンスで作動するアプリケーションは、AWS リソースにアクセスする際に、ロールの認証情報を使用できます。ロールのアクセス権限とは、アプリケーションを実施しても良いという決定することです。

Best Practice 認証情報を共有するのではなく、ロールを使って委託する 他の AWS アカウントからのユーザーが、お客様の AWS アカウントのリソースにアクセスできるようにする必要があるかもしれません。その場合、アクセスキーなどの認証情報をアカウント間で共有してはいけません。その代わりに、IAM ロールを使用します。ロールを定義し、他アカウントの IAM ユーザーが許可されるアクセス権限を特定します。また、IAM ユーザーが、どの AWS アカウントからロールを引き受けられるようにするかも特定することできます。

!認証情報を定期的にローテーションする !追加セキュリティに対するポリシー条件を使用する 実行可能な範囲内で、どのポリシーがリソースにアクセスできるかという条件を定義します。例えば、リクエストに対して許可される IP アドレスの範囲を特定する条件を書くこともできます。または、ある特定の日時範囲に限り、リクエストを許可すると特定することもできます。また、SSL や MFA の使用を要求する条件も設定することができます。例えば、Amazon EC2 インスタンスを終了できるようにするため、ユーザーに対し MFA デバイスの認証を要求することもできます。 リソースがアクセス可能なとき（またはアクセス不可能なとき）を明確に定義すればするほど、お客様のリソースはより安全になります。

VPC:仮想ネットワーク概要 AWS上にプライベートネットワーク空間を構築し、社内からVPN接続して閉域網でAWS利用が可能。仮想ネットワーキングのサービス。 VPN Gatewayを使ってオンプレのシステムと連携し、AWSが社内のシステムのように見える。 SubnetはAZ内をまたがって作成できない。 Default VPC VPCを指定せずにインスタンスを起動した際に利用されるVPC Default Subnet Default VPC内の各AZ毎に自動作成されるSubnet VPCの利用は無料。VPN Connectionを利用する場合、時間単位で課金。

DB Subnet Group ※VPC 内で RDS DB インスタンス用に指定するサブネットのコレクション

VPC:仮想ネットワークVPCで操作できる構成要素

VPC CIDR / Subnet ※Subnet作成後は、VPCのサイズやアドレスブロックは変更できないので注意 Route Table ※ルーティングテーブル Internet Gateway(IGW) ※ルーティングテーブルでゲートウェイをIGWに向けるとインターネットに接続できる。 VPC Security GroupとNetwork Access Control List (NACL)

Security Group:インスタンスレベルでI/Oを制御 Network ACL:サブネットレベルでI/Oを制御。Denyが記述できる。

EC2 Dedicated Instance ハードウェア専有インスタンス。ハードウェアレベルで確実に分離しながら、オンデマンド伸縮自在なプロビジョニング、従量課金制、プライベートの独立した仮想ネットワークといった、Amazon VPC と AWS クラウドの利点を活用できる。

Elastic Network Interface (ENI) VPC上で実現する仮想ネットワークインタフェースを複数持てる機能。EIP、Private IP, Mac Address、セキュリティグループを紐付けて維持可能。※1つのAZ内でしか利用できない。

Virtual Private Network (VPN) オンプレミスの環境もしくはオフィスとAWSのVPC環境を繋げる手段 ※BGPに対応していないVPN Routerも静的ルーティングすることで利用可能 AWS環境でVPN Gatewayを作成してVPCに紐付け -> Global IPやAS番号を指定してCustomer Gatewayを作成 ->VPN Connectionを作成後、Configurationファイルをダウンロードし、VPN Routerの設定を実施

SQS:キューイングサービス概要 分散マネージドキューであり、高い信頼性とスケーラブルなキュー SQSはゾーンを跨いで利用可能なサービス メッセージの順序は保障してない。※基本的にはFIFOだが、実際には分散キューだから。 一度に最大10通送信可能/送信者 ※バッファリングして1コールでまとめて送信。Send,Delete,Change Messageリクエストをまとめられる。 一度に最大10通受信可能/受信者 ※バッファリングして1コールでまとめて受信。Send,Delete,Change Messageリクエストをまとめられる。 削除されなければ、メッセージはデフォルトで4日保持される。※保持期間を60秒から14日の間で変更可能。 1つのキュー毎に最大12万通のInflightメッセージを保持。 最大メッセージサイズは256KB ACLが可能 一度以上のメッセージ到達を保障 メッセージ受信後デフォルト30秒は他の受信者は受信できない（Visibility Timeout） Inflightメッセージ：Visibility Timeoutによって他から見えない状態のメッセージ メッセージを削除しなければ、30秒経過後、再度1名のみ受信可能となる。

機能 Long Polling機能

メッセージが有効になるまで待つことができる機能 ReceiveMessageWaitTimeSecondsを設定するとロングポーリングでデキュー出来る。ロングポーリングにしておくとエンキューされたら即次実行され、キューが溜まっていないときには接続しっぱなしで受信処理を行うため余計なリクエストを行わなくて済む。 メッセージが無い場合は、最大Receive Message Wait TImeで指定した時間だけ処理が待たされ、キューにメッセージが送信された時点で、すぐにメッセージを取得し、処理が終了する形となっている。

Delay Queue機能 キューに送られた新しいメッセージをある一定秒の間見えなくすることが可能 120と設定すればキューにメッセージを送ってから2分後に見えるようになる。また、遅延メッセージは、個別のメッセージを送る際に、遅延秒数を設定することができる。遅延キューと遅延メッセージが両方設定されている場合には、遅延メッセージが優先される。

Message Timers機能 個々のメッセージが送信されてから見えるようになるまでの時間を設定可能

Dead letter Queue機能 キューから指定回数受信後に自動で別のDead Letter Queueにメッセージが移動される機能　※デフォルトでは無効 使いどころ。メッセージ自体に問題があった場合（例えばvisibility timeoutの期間内にアクセスできないようなリソースへのアクセスをメッセージが要求するケースや、同様にvisibility timeout期間内に処理しきれないようなメッセージの内容だった場合）、メッセージは再び取得可能な状態にもどり、何度も何度も取得されては処理が正常終了せずにまた取得可能な状態に戻ってしまい、永続的にキューの中に残り続けてしまう。Dead Letter Queueはこういった事象を過去のものにする。取得回数がMaximum Receiveで設定された値に達したメッセージはキューから取り除かれ、指定されたDead Letter Queueへと送られる。Dead Letter Queueに送信されたメッセージを処理するための専用のコンシューマーを用意することにより、問題をロギングや解析し、原因を突き止めることが可能となる。

Tips Batch APIにより1度に10メッセージを処理すると、SQSのリクエスト数を削減し、コスト削減ができる 多くのメッセージ送信者と受信者を配置しスケーリングさせる キューへのACLが可能　※ACLはJSON形式 他のAWSアカウントにSendMessageのみ許可、特定の時間のみアクセス許可、特定のAWSアカウントのアカウントを拒否、EC2インスタンスからのアクセスのみ許可などが設定可能。 CloudWatchを使ってSQSを監視できる。監視項目は以下のとおり。キューに追加されたメッセージ数

キューに追加されたメッセージの合計サイズ

ReceiveMessageコールによって返されたメッセージ数

ReceiveMessageによって返さなかったメッセージ数

キューから削除されたメッセージ数

Delayされすぐに読み込みができなかったメッセージ数

キューから利用可能になったメッセージ数クライアントから送信されたが、削除されていないか、visibility windowのendまで到達していないメッセージ数

Best Practice 一度のリクエストで複数のメッセージを送信または受信する方が速い　※最大10通まで 1つのキューに対する送信者または受信者は複数立てた方が全体の処理速度が向上する 複数のキューにLong Pollingするときには、キューごとに1スレッド使う　※最大20秒まで待つことができる 何度も同じメッセージを受信しても同じ結果になるように受信者側は実装する メッセージの受信順序が違ってても同じ結果になるように受信者側を実装する メッセージ受信側でPolling処理を継続して実行するような仕組みの実装が必要 !

CDP(Cloud Design Patern) 多くのバッチジョブを処理する必要があり、しかもジョブに優先順位があるケース

http://aws.clouddesignpattern.org/index.php/CDP:Priority_Queue %E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3 キューを優先順位に応じて複数用意し、ジョブリクエストを優先順位によってキューに入れ分け ることで、バッチ処理の優先順位を付ける。 キューに対応するバッチサーバーの性能（数）は、優先順位に応じたものにしておく。 実装

SQSを用いて優先順位ごとに複数のキューを用意する。 処理を急ぐもの（ジョブリクエスト）は、優先順位の高いキューに入れる。 優先順位に応じてキューのジョブリクエストを処理するバッチサーバーの台数を用意する。 キューには「メッセージの遅延送信」機能がある。それを利用することで、処理開始時間を遅延させることも可能である。

EC2:コンピューティング概要 仮想化されたサーバ。※ハイパーバイザーはXenをベースにAmazonが拡張。 オペレーティングシステム、アプリケーションソフトウェアおよび関連コンフィギュレーション設定を Amazon Machine Image (AMI)として組み込むことができる。※サーバーテンプレートのようなもの。 EC2インスタンスタイプの変更可能　※停止しているとき 停止-起動をするとGlobal IPアドレスが変更。※再起動では変更されない。停止->起動すると別のサーバに移るので変更されるのであろう。 EIPを使えばIPアドレスを固定できる。EIPは取得したまま割り当ててないと課金される。 Security Group ※FW

Tips Security Group

インスタンスの用途に応じたSecurity Groupを用意する アクセス元にSecurity Groupも設定して限定可能

故障のための設計 AMIを常にとっておく EBSスナップショットでバックアップ 複数アベイラビリティゾーンへの分散 ELBでサーバを冗長化、Auto Scalingで自動復帰 Reserved Instanceでキャパシティ保障

リザーブドインスタンスとスポットインスタンス ※デフォルトはオンデマンドインスタンス リザーブドインスタンス

予約金の支払いで、時間単価の割引・キャパシティの予約　※年間を通して大幅な費用削減が可能 予約金支払いによる、1年間/3年間の時間課金の割引　※一時金支払で、時間単価が安くなる仕組み 月額費用は割引単価での時間課金 必ずしも1年間使用し続ける必要はない ※ただし使用しない場合でも初期費用の返金はなし 稼働率の高い(多くの時間起動している)インスタンス (常時稼動のDBサーバ,最低限必要なWeb/APサーバ等)

スポットインスタンス 需要と供給の関係に基づいてリアルタイムで変動する 「スポット価格」が割当てられたインスタンス スポット価格(需要と供給によりリアルタイムに変動)で課金。最大で払ってもいい額を決定して「入札」 時間の制約がなく、中断しても支障のないタスクを実行するインスタンス (Webクローラ ,分散処理のタスクノード等)

Auto Scaling:スケーリング概要

AutoScalingは定義した設定に従って自動でEC2の台数を増減させるメカニズム。 １．CloudWatchがトリガーとなり、アラームが発動されたら、アラームに対応するAutoScalingPolicyを駆動する ２．AutoScalingがLaunchConfigurationに従ってインスタンスをグループに追加する

!設定項目コンポーネント 備考 設定項目

LaunchConfiguration 起動設定

AutoScalingがEC2インスタンスを起動する方法を定義 アクティブな起動設定は１つだけ。 AutoScalingは古い起動設定のインスタンスを停止する。

AMI ID インスタンスタイプ SecurityGroup リージョン KeyPaira

AutoScaling Group

AutoScalingがインスタンスを起動する場所（AZまたはVPCサブネット）を定義 AutoScaling管理のEC2インスタンスのグループ化 プールサイズ維持のための自動ヘルスチェック ELBとの自動統合 AZ間の自動配布と自動バランシング

LaunchConfiguration名 AZ 最小台数 最大台数 ELB名 リージョン

AutoScaling Policy

グループにいくつのEC2インスタンスを追加または削除するか説明するスケジューリングアクションの定義 AutoScalingアクションを実行するためのパラメータを設定。 ポリシーはCloudWatchのイベントでトリガーされる。

AutoScalingGroup名 タイプ 増減の台数 状態を監視している時間 リージョン

ELB(Elastic Load Balancing):ロードバランサ概要

AWSクラウド上のロードバランシングサービス 従量課金で利用可能

!設定項目コンポーネント 備考

Ping Protocol ヘルスチェックの際に利用するネットワークプロトコルの設定。

Ping Port ヘルスチェックの際に使用するポート番号

Ping Path ヘルスチェックの際に使用するファイルの場所

Response Timeoutヘルスチェックからの応答を受信した場合の処理の待ち時間。設定した時間を過ぎた場合は処理が中断する

Health Check Interval 実際にヘルスチェックをおこなう間隔

Unhealthy Threshold インスタンスが「異常な状態」という判断に至るまでに実施するヘルスチェックの回数

Health Thresholdインスタンスが「正常な状態」という判断に至るまでに実施するヘルスチェックの回数

機能 バックエンドのEC2インスタンスのリクエスト数やコネクション数を基に負荷分散 ※AZ内。AZ間はラウンドロビン。 ELB自体が負荷の増減に応じて自動でスケール。ELBがスケールするときには、IPアドレスが変化するため、ELBへアクセスするときには必ずDNS名にする必要がある。独自ドメインに割り当てる際はCNAMEを使う。 ELBは指定した設定に基づき、バックエンドのインスタンスのヘルスチェックを行う プロトコル、ポート, パス（Webサーバの場合）を指定できる。 ヘルスチェックの成功・失敗回数は指定可能

クライアント<->ELB のTCPコネクションはアイドル状態が60秒続くとそのコネクションを切断する ELBでSSL Terminationも可能 ※ELBで証明書を配置し、クライアントELB間をSSLで暗号化。 Stickyセッション：Stickyセッションを使うと、同じユーザから来たリクエストを全て同じインスタンスに送信可能

TIPS ヘルスチェックを意図的に失敗させることで特定のインスタンスへのリクエスト振り分けを止めることが可能 バックエンドサーバのアクセスログにはELBのIPアドレスのみが含まれる ※クライアント<->ELB, ELB<->バックエンドのコネクションはそれぞれ独立しているため(HTTPならX-Forwarded-Forリクエストヘッダで参照可) ELBは負荷に応じてスケールする 。但し、以下のような場合にELBがHTTP 503を返す ELBへの接続・リクエストが瞬間的に急増したために、ELBのスケーリングが間に合わない場合 回避方法 事前にELBをスケールさせておく 負荷をかける Pre-Warming（暖気運転）の申請を行う

EBS(Elastic Block Store):ブロックストア概要

Posix準拠、ネットワーク接続型のブロックストレージ　※Linuxは50,Windowsは20くらいまで接続可能 データの存続期間はEC2インスタンスの存続期間とは別 EBS StandardとEBS Provisioned IOPSがある。※AZに存在。 EBS-Optimized Instance：EBS用にネットワーク帯域を最適化　※PIOPSを利用する場合はOptimized Instanceにする（PIOPSが利用すること前提としているため）。 サイズ、期間、I/Oで課金される。 最大容量は1TB 単一AZの中で冗長化されている　※そのためRAIOを組んでも可用性は大きく向上しない。スナップショットの頻度を上げた方がよい。 ランダムI/Oに最適化 EBSのIOPS値は100を目標に定められている。※ベストエフォート。 ボリュームを拡大可能：スナップショット->スナップショットから大きなボリュームを作成->アタッチ OSブート用やデータ保存用としての利用が推奨されている ブロックサイズは:16KB以下が最適 アタッチ数が多いほど、総合的なI/Oは上がる。インスタンスタイプも上位のモノのほうが性能が上がる。

機能 スナップショット

S3に保存。AMIをスナップショットから作成可能。2回目移行のスナップショットは差分のみS3に保存する差分バックアップ。

スナップショットコピー 作成したスナップショットをコピーする機能。リージョン間もコピーできる。

Provisioned IOPS IOPS数が指定できるEBS IOPSの指定は100から2000まで。 合計20TB, 10,000IOPSの制限 IOPSはDiskサイズ(KB)の10倍を超える高い比率を指定できない

Auto Enable I/O機能 EBSのデータの整合性が取れなくなっても、 EBSへのI/O処理を中断しないで継続する機能 データの整合性よりディスクの可用性を優先する場合に使用する

EBS Volume Status for I/O performance 従来の整合性チェックのみではなく、I/Oのパフォーマンス状態もチェックする機能　※PIOPSのみ有効 I/Oパフォーマンスで発行されるイベントは以下の4種類|

Normal IOPS値が指定IOPSの90％以上の場合 Degraded IOPS値が指定IOPSの90％を下回る場合 Severely Degraded IOPS値が指定IOPSの50％を下回る場合 Stalled I/Oが発生しない状態の場合

CloudWatch連携　※EC2→EBS間の性能については、CloudWatchを利用する。 EBSボリュームのプロビジョンされたIOPSに対して実際に出たIOPSの割合、一定期間に実行された読み込みと書き込みの操作の合計量がCloudWatchで監視できる。

TIPS アンチパターン 一時的ストレージ：インスタンスストア（エフェメラルストレージ）が向いてる 耐久性の高いストレージ：S3が向いてる 静的ウェブコンテンツの格納：S3が向いてる 構造化データやKVS：DynamoDBやRDSが向いてる

インスタンスストア概要 揮発性のストレージ。ローカルの直接接続リソース。 EC2インスタンスが停止するか、障害が発生した際はデータが失われる。リブートではデータは失われない。 シーケンシャルI/Oに最適化されている。ランダムI/Oに最適化されてない。 スナップショット機能はなし EC2インスタンス利用料金以外の費用は不要 自動的に接続されない 一時データの保存用

!

Tips アンチパターン 永続的ストレージ：EBSが向いてる データベース/構造型ストレージ：EBS,DynamoDB,RDSが向いてる 共有可能ストレージ：EBSが向いてる。 バックアップ：　EBS(スナップショット機能)

RDS:データベース概要 クラウド上のRDBMSサービス。 MySQL,Oracle,MS SQL Server,PostgreSQL が利用可能。 使える容量は3TBまで。 バックアップ/スナップショットを自動で行ってくれる（１日１回、保存期間は最大３５日まで設定可能） 任意のタイミングで手動スナップショットもとれる。 スナップショットとトランザクションログを用いて最大５分前まで復元可能。 マイナーバージョン（選択可）、メジャーバージョンのパッチを管理/適用してくれる マルチAZ対応しており、同期レプリケーション、自動フェイルオーバをしてくれるので耐障害性を高められる スケールアップ可能（CPU：88ECUまで、Mem:244GBまで、ディスク:3TBまで。MS SQLは1TBまで） ディスク容量は増減できても削減できないので注意が必要 時間単位の課金※DBインスタンスのクラスとリージョンで価格は変動

Route53:DNSAWSの提供するDNS権威サービス 機能

AWS独自のレコード：エイリアスタイプ ELB、S3のウェブサイトバケット、CloudFrontのディストリビューションのDNS名をドメインだけの形にして割り当てできる。 ルートドメインでWebサイトをホストできる。 (例. http://mysite.com)

重み付けラウンドロビン レコードセットに重みを設定 0から255の間で設定可能

レイテンシベースルーティング ※バックエンドで継続的にレイテンシの計測データを収集しRDSに蓄積しているから可能

Route 53 はエンドユーザからのアクセスをレイテンシ最小のエンドポイントへ誘導する DNSフェイルオーバー

アプリケーションのエンドポイントがアップまたはダウンしているかを判断(ヘルスチェック)し、ウェブサイトが停止したことを検出した場合、サイトにアクセスしたユーザーをダウンしているエンドポイントからリダイレクトさせる。 フェイルオーバの動き

AWS各リージョン内からヘルスチェックを実施。 ヘルスチェックに際してRoute 53は指定したIPアドレス、URL、ELBに対して要求送信。成功応答を受けるとヘルスチェック合格、さもなければヘルスチェック失敗。 ヘルスチェックが失敗したら、関連づけられたDNSレコード全てがInactiveになり、バックアップとして構成されたレコードがActiveに。 ヘルスチェック対象のエンドポイントがフェイルしてからDNSフェイルオーバーまで3分程度

SNS:メッセージング概要 柔軟で高速なフルマネージドメッセージングサービス マルチプロトコル(HTTP,MAIL,SQS,Mobile Push)で簡単にメッセージを通知 SNSはメール内容をカスタマイズできない。 動作

 Topicの作成 TopicをSubscribe Topicへ向けてメッセージをPublish CloudWatchとの連携など

Cloud Watch:監視概要 AWSの各種リソースをモニタリングするためのWebサービス サービスごとに定義されたメトリクス（監視項目） メトリクスをベースにアラームを設定可能 メモリ、ディスク利用率などのOSでしか取得できない情報は標準メトリクスではとれないので、カスタムメトリクスで対応。※カスタムメトリクスは課金される。 基本的に無料。EC2インスタンスの標準監視（5分間隔）。ELB、RDSは1分間隔が無料 アラーム時に取れるアクション

SNSを使った通知を送る。Mail,HTTPのAPIを呼ぶなど。 Auto Scaling Policyをトリガーする インスタンスをStop/Terminateする

メトリクスの保存期間：2週間 監視できるサービス：EC2,DynamoDB,EBS PIOPS ボリューム/standardボリューム,ElastiCache ノード,RDS DB インスタンス,SNS トピック,SQS キュー,Elastic MapReduce ジョブフロー,Redshift,Route53 ヘルスチェック,Opsworks,Storage Gateway,Auto Scaling グループ,ELB,請求書の予想請求額

請求通知機能(ビリングアラート) AWSクラウドの利用料金を監視・通知。※料金を超えると通知をだすなどを行う機能