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(3)CloudWatch Logsのインストール

EC2インスタンスにCloudWatch Logs Agentをインストールすることで、任意のログをCloudWachに送信することが可能となる。AmazonLinuxを使用する場合には、以下の手順でインストールする。

CloudWatch Logs Agentのインストール

CloudWatch Logs Agentのインストール

CloudWatch Logs Agentはyumから簡単にインストールできる。

yum update -y
yum install -y awslogs

CloudWatch Logs Agentの設定

監視対象のログはconfファイルで設定する。

sudo vi /etc/awslogs/awslogs.conf

標準で/var/log/messagesの情報は送られる設定になるようである。
その下に下記のように設定を追記することで、任意のログを送ることが可能となる。

[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/messages

[test-app-log]
file = /home/ec2-user/test-app/process_log
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /home/ec2-user/test-app/process_log

CloudWatch Logsのログデータをエクスポートする

CloudWatch Logsに蓄積したログデータは、S3に一括エクスポートすることができる。詳しくは、「CloudWatch コンソールを使用してログデータを Amazon S3 にエクスポートする」を参照のこと。

AWS(3)監視およびログサービス

AWS Configとは

AWS Configは、リソースごとの設定項目を生成し、履歴としてこれを保持するため、全ての変更を追跡することが可能で、AWSリソース間の関係と設定の履歴などを確認することができる。また、設定が最適であるかの評価設定のスナップショットの取得設定変更時の通知IAMポリシーの確認などを行うことが可能である。

設定項目は、S3バケットに蓄積することが可能で、データはJSON形式でS3に6時間ごとに送信される。また、リソースが変更されたタイミング等で、Amazon SNSを用いてEメール等で通知することも可能である。

設定履歴と設定項目、設定レコーダ

設定履歴は、特定期間の特定リソースに関する設定項目のコレクションである。設定項目は、アカウント内のサポートされているAWSリソースの属性を記録したものである。設定レコーダは、これらのリソースの設定を設定項目としてアカウントに保存する。

設定スナップショットと設定ストリーム

設定スナップショットは、設定項目のコレクションで記録対象のリソースの全体像を示す。また、設定ストリームは、これらの記録しているリソースの設定項目の自動更新リストを示す。

AWS Configの仕組み

AWS Configは、サポートされているAWSリソースを検出し、リソースごとに設定項目を生成し、その記録を履歴として保持する。Configはリソースごとに、DescribeもしくはListのAPIコールによって、リソースの全ての変更を追跡するConfigルールを利用することで、定期的にこのルールに照らして、リソースの設定の評価を行うことができる。

AWS Configルール

AWS Configルールは、各リソースの望ましい設定を確認することが可能で、事前に定義済みのルールが用意されている。また、各ユーザがカスタムルールを作成することも可能となっている。AWS Configは、このルールを参照して、現在の設定を評価する。

マネージドインスタンスの記録

AWS Configを用いて、EC2やオンプレミスサーバのソフトウェアインベントリの変更を記録可能である。

課金

記録される設定項目ごとに 0.003 USDの課金が発生し、これに加えてS3やSNSを使用する場合には、これらのサービスの使用料金が課金される。

AWS Cloudtrailとは

AWSサービスによって実行されたアクションを記録するサービス。この記録を基にAWS アカウントのアクティビティの分析を行い、これらに対応することが可能である。デフォルトで有効にされており、90日間のログが履歴として保持される。また、それ以上保持したい場合には、トレイル機能を用いて、S3やCloudWatch Logs等にイベント配信することも可能である。トレイルは、全リージョンに対して、もしくは特定のリージョンの情報のみを保持することが可能で、作成後に設定内容を変更することもできる。デフォルトではS3の暗号化機能を用いて暗号化され、アクションの15分以内にデータが送信される。

Cloudtrailイベントとトレイル

Cloudtrailイベントには、管理イベントとデータイベントの2種類が存在するが、トレイルにはデフォルトでは管理イベントのみが記録される

課金

デフォルトでは無料で90日間のログを保持しており、これに加えて1つのトレイル作成までは無料となっている。S3やSNSを使用する場合には、これらのサービスの使用料金が課金される。

AWS(2)セキュリティの概要

AWSのセキュリティ

ユーザのデータは、安全性が高いデータセンターに保存される。また、複数のコンプライアンス要件に準拠している。SOC1 ISAE 3402などの複数のITセキュリティ基準に対応しており、その状況は、AWS Articraftから参照することが可能となっている。

AWSのコンプライアンスとセキュリティは、高度な自動化と、高い可用性高度な認定によって実現されている。

責任共有モデル

AWSは、クラウドのセキュリティを管理する。具体的には、AWSはCPU、メモリなどの物理マシンをはじめとしたインフラストラクチャの保護を行う。一方、ユーザは、クラウド内のセキュリティを管理する必要がある。

AWSの組み込みセキュリティ

AWSは、データの暗号化やアクセス管理などのセキュリティサービスを提供しており、Trusted Advisorは、AWS ベストプラクティスに従ってリソースをプロビジョニングするのに役立つ、リアルタイムガイダンスを行う。また、AWS Inspectorは、自動化されたセキュリティ評価サービスで、AWS にデプロイしたアプリケーションのセキュリティとコンプライアンスを向上させることができる。EC2上にエージェントをインストールすることで診断可能となる。

AWS Shieldは、マネージド型の分散サービス妨害 (DDoS) に対する保護サービスで、追加料金なしで AWS Shield Standard の保護の適用を自動的に受けることができるAWS Shield Advancedは、大規模で洗練された DDoS 攻撃に対する追加の検出および緩和策と、ほぼリアルタイムの可視性を提供し、AWS WAFと統合されている。

AWS(1)AWSの概要とメリット

クラウドとは

クラウドとは、従量課金でWEB上からオンデマンド提供されるITリソースである。

AWSのメリット

AWSのメリットは、先行投資となる先行投資資本となるインフラコストを、ユーザのビジネス拡大にあわせた低額の変動費に移行できることである。また、スケールによる大きなコストメリットを享受することが可能で、自社環境よりも低い低額コストを実現できる。スケールアップおよびスケールダウンがわずか数分で実現できることから、キャパシティーの推測が不要となる。1クリックでITリソースを手に入れることが可能となるため、リソースを用意する時間が大幅に短縮され、組織の速度と迅速性が向上する。またこれらのことから、ユーザはデータセンターの運用や保守への投資が不要となり、ビジネスを差別化するプロジェクトに集中できる。また複数のリージョンに簡単にデプロイできることから、グローバル化も容易である。

グローバルインフラストラクチャ

リージョン

リージョンとは、世界中の物理的場所であり、リージョンに複数のアベイラビリティゾーン(AZ)が配置される。他のリージョンとは完全に分離されている

アベイラビリティゾーン(AZ)

独立したデータセンターで、冗長性ある電源とネットワーク、接続性を実現している。洪水の影響が及ばない場所に設置され、複数のTier1プロバイダに接続されている。各AZ間は低遅延リンクで接続されている。

サービス

AWSの各種サービスには、次の3つのサービスレベルがある。

種類 サービスの例
AZサービス EC2, RDS, ELB, ElastiCache
リージョンサービス S3, DynamoDB, SQS
グローバルサービス IAM, Route 53, Cloudfront

AWS導入の道のり

AWSを導入するためには、まず調査を行う。移行対象は非クリティカルなアプリケーションとし、セキュリティとユーザロール、VPCをセットアップ、開発/テスト環境をデプロイする。次に本番環境へアプリケーションを移行し、分析ワークロードをデプロイする。

本番環境に移行後に検討チームを結成し、プラットフォームの検討とAWSを拡張を行う。また、IT戦略を見直しクラウドに一致させる。また、DevOpsの導入オートメーションとコードリファクタリングを行う。

ベストプラクティス

AWSでは、オンプレミスとは異なるベストプラクティスが存在する。

  1. 故障に備えた設計で障害を回避
  2. コンポーネント間を疎結合で柔軟に
  3. 伸縮自在性を実装
  4. 全ての層でセキュリティを強化
  5. 制約を恐れない
  6. 処理の並列化を考慮
  7. さまざまなストレージの選択肢を活用

APNパートナーに提供されるサービス

APNパートナーは、AWSを導入する企業をサポートすることができる。APNパートナーには以下のツールが提供される。

AWSクイックスタート

人気の高いソリューションの AWS へのデプロイを支援するために、AWS ソリューションアーキテクトおよびパートナーによって構築されたもの

AWS コンピテンシープログラム

習熟した技術を持ち、専門的なソリューションエリアでお客様を成功させられることを実証した APN パートナーに付与

AWS Marketplace

AWSに最適化されたITおよびビジネスソフトウェアのカタログ

費用

AWSの費用体系は従量課金である。どの程度費用が掛かるかは簡易見積もりツールで計算できる。

総所有コスト

オンプレミス環境とクラウド環境の費用を比較する場合は、総所有コスト(TCO)を比較する必要がある。これは、購入と運用、撤去と廃止、機会コスト、サーバ、ストレージ、ネットワーク、人件費、機会コストなどを含む。施設のデフォルトコストは1ラックあたり月25万円+電気代とAWSでは考えている。総所有コストを計算し正しくオンプレミス環境とクラウド環境の費用を比較するためには、TCO計算ツールを利用する。

 

AWS Identity and Access Management(3)ルートアカウントとIAMユーザ

アカウント設定と請求情報

ルートアカウントは極力使用しないことが望ましいため、AWSのリソースにアクセスする際には、AWS Identity and Access Managementで作成したIAMユーザを使用する。各IAMユーザには、ポリシーと呼ばれる各リソースへのアクセス権限が付与可能で、アカウント管理者向けには、ルートアカウント並みの権限を持つAdministratorAccessと呼ばれるポリシーが用意されている。なお、 PowerUserAccessには、IAM権限とOrganaizations権限が付与されていない

権限 ルートアカウント IAMユーザ (AdministratorAccess) IAMユーザ (BillingFullAccess) IAMユーザ (Billing)
ルートアカウントの設定情報の変更 × × ×
サポートプランの変更 × × ×
アカウントの解約 × × ×
CloudFront のキーペアの作成 × × ×
リソースベースポリシーの見直し × × ×
AWSサービス全般へのアクセス許可 × ×
AWSアカウント設定(支払い方法等)の参照 △ (※) △ (※) ×
AWSアカウント設定(支払い方法等)の変更 △ (※) △ (※) ×
請求情報の参照 △ (※) △ (※) △ (※)

BillingFullAccessというポリシーは事前に用意されていないため、各IAMユーザごとに以下のようなカスタムポリシーを付与する必要がある。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "StmtXXXXXXXXXXXXXXXX",
            "Effect": "Allow",
            "Action": [
                "aws-portal:*"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

参考情報

AWS EC2(6)Elastic Load Balancing

ELBとは

ELBとは複数のアベイラビリティゾーンのEC2インスタンスに負荷を分散させるロードバランサである。ELBには、Classic Load BalancerApplication Load BalancerNetwork Load Balancerの3種類が存在する。特段の理由がなければ、Clasic Load Balancerは使用せず、Application Load Balancer、Network Load Balancerを使用する。

ロードバランサは、登録されているEC2のうち正常なものだけを選んで負荷を分散する。Clasic Load Balancerは、EC2のインスタンスを直接登録するが、Application Load BalancerとNetwork Load Balancerは、ターゲットグループをまず生成し、その中にインスタンスを登録する形となる。クライアントから接続があった場合は、作成したリスナーがそれを確認し、EC2へとトラフィックをルーティングする。EC2にルーティングをクロスゾーン負荷分散を無効にしていると、インスタンスがどのようなバランスで配置されていたとしても、アベイラビリティゾーンの数で均等に配分されてしまうので注意が必要である。なお、Application Load Balancerでは、クロスゾーン負荷分散はデフォルトで有効になっている。

ロードバランサに紐付けられているドメイン名に紐づけられたIPアドレスは、負荷に合わせて動的に変化する。DNSエントリは、TTLが60秒に設定されている。内側のインスタンスとの通信では、EC2にKeep Aliveを設定しておくことが望ましい。

特徴

HTTPS

SSLの終端に対応している。また、同じIPアドレスには1つのドメインしか割り当てられないSSL/TLSを拡張し、複数のドメインに対応したSNIにも対応している。

 

 

 

Application Load Balancer とは

Application Load Balancerは、OSI参照モデルのレイヤー7で動作するロードバランサで、負荷に合わせて自動的にスケールする。HTTP/2やWebSocketに対応している。EC2でクライアントの送信先アドレスを取得するためには、x-forwarded-forヘッダフィールドを参照する。ALBが負荷に追従できずスケーリングが間に合わなかった場合は、503を返す。リクエストタイムアウト値は60秒

スティッキーセッション

ALB(およびClassic Load Balancer)では、スティッキーセッションを利用できる。ALBは、レスポンスにCookieを含め、 同一のCookieを受信した場合にはリクエストを同じターゲットに送信するターゲットグループ単位 で、スティッキーセッションを有効化できる。

アベイラビリティゾーン

ALBが対象とするアベイラビリティゾーンを有効化/無効化することができる。 無効化されたアベイラビリティゾーンのターゲットは、ALBに登録された状態のままであるが、トラフィックはルーティングされない

ルーティング

IPアドレスベースのルーティングに対応しているため、オンプレミス上の任意のサーバをターゲットとして指定することができる。また、Lambdaをターゲットにすることも可能。ホストベース、パスベース、ヘッダーベース、メソッドベースなどのコンテンツベースルーティングにも対応している。

ELB基本コンポーネント

Network Load Balancerとは

Network Load Balancerは、OSI参照モデルのレイヤー4で動作するロードバランサで、必要に応じて1つのElastic IPをサブネットごとに紐づけることができる。また、NLBを作成するときには耐障害性を向上させるために、複数のAZを有効にすることができる。ただし、NLB作成後にAZを有効化したり無効化したりすることはできない。また、割り当てたサブネットに1つ以上のターゲットが存在する必要がある。割り当てたサブネットには最低8個の利用可能なIPアドレスが必要となる。

送信元のIPアドレスを保持することが可能で、Pre-Warmingなしに急激なスパイク(数百万requests/秒)に対応可能。また、NGとなったAZのIPアドレスは自動的にDNSとの紐付けから削除されるなど高い可用性を持つ。

リスナーは、TCP 1-65535ポート、およびWebSocketに対応している。ログは、VPCフローログを利用する。

クロスゾーン負荷分散

NLBでクロスゾーン負荷分散を有効にすると、同一AZ(同一サブネット)のターゲットだけではなく、有効な全てのAZの登録済みのターゲットに対してトラフィックを分散することができる。

AWS EC2(5)ユーザデータによる起動時のコマンドの実行

cloud-init

EC2が起動する際に、cloud-initを使って任意のスクリプトを実行させることが可能である。実行する際に渡すことのできるデータ(ユーザデータ)は、プレーンテキスト・ファイル・Base64エンコードされたテキストで、通常は初回起動時のみ実行されるため、再起動時などは実行されない。スクリプトは、シェルスクリプト形式もしくはcloud-initディレクティブ形式で記述することが可能である。なお、スクリプトは、インタラクティブに動作させることはできないことに注意が必要である。また、このスクリプトは、rootユーザとして実行される。

シェルスクリプトによる実行

シェルスクリプトを実行させるためには、通常のシェルスクリプト同様にインタプリタのパスを最初に記述する必要がある。

#!/bin/bash

その他の処理も、通常のシェルスクリプトと同様に記述することができる。

ユーザデータの登録

ユーザデータの登録は、AWSマネージメントコンソール上、もしくはAWS CLIから行うことが可能である。

AWSマネージメントコンソールから登録

AWSマネージドコンソールで行う場合は、インスタンス作成画面の中で、ユーザデータを登録できる。

ユーザデータの登録

また、登録したユーザデータは、「インスタンスの設定」より確認することが可能である。

ユーザデータの確認

実行中のインスタンスから値を取得することも可能である。

curl https://169.254.169.254/latest/user-data

AWS CLIから登録

AWS CLIからEC2を起動する際に、user-dataオプションを付与することで、ユーザデータを指定することができる。指定するファイルは、シェルスクリプトが記述された通常のテキストファイルでよい。

aws ec2 run-instances --cli-input-json file:///tmp/ec2_settings.json --user-data file:///tmp/cloud-init_userdata.txt

AWS EC2(4)AWS CLIからEC2インスタンスを起動する

JSONファイルから起動する

EC2をAWS CLIから起動する際、JSONファイルに設定情報を記述しておくと、複雑なオプションコマンドを書き連ねる必要がなく、設定の管理もラクである。JSON形式の設定ファイルの雛形は、

<br>
aws ec2 run-instances --generate-cli-skeleton &gt; /tmp/ec2_settings.json<br>

で取得することが可能であるが、不要な設定も多く含まれているので、どの設定を有効とするかは精査が必要である。AWSマネージメントコンソールで設定可能な項目と同程度の設定であれば、以下の設定で起動することが可能である。

<br>
{<br>
    "DryRun": false,<br>
    "ImageId": "ami-XXXXXXXX",<br>
    "KeyName": "XXXXXXXX",<br>
    "SecurityGroups": [<br>
        "XXXXXXXX"<br>
    ],<br>
    "InstanceType": "t2.micro",<br>
    "BlockDeviceMappings": [<br>
        {<br>
            "DeviceName": "/dev/xvda",<br>
            "Ebs": {<br>
                "VolumeSize": 8,<br>
                "DeleteOnTermination": true,<br>
                "VolumeType": "gp2"<br>
            }<br>
        }<br>
    ],<br>
    "Monitoring": {<br>
        "Enabled": true<br>
    },<br>
    "DisableApiTermination": true,<br>
    "InstanceInitiatedShutdownBehavior": "stop",<br>
    "IamInstanceProfile": {<br>
        "Name": "XXXXXXXX"<br>
    }<br>
}<br>

それぞれの設定項目と、AWSマネージメントコンソール上の表示との対応は、以下の通り。

JSON項目名 AWSマネージメントコンソール上の名称 内容
DryRun 設定ファイル作成時は、DryRunで確認する
ImageId Amazon マシンイメージ AMIのID
KeyName キーペアの選択 キーペア
SecurityGroups セキュリティグループの設定 セキュリティグループ名
InstanceType インスタンスタイプの選択 インスタンスタイプ
BlockDeviceMappings/DeviceName デバイス AWSマネージメントコンソールは、通常/dev/xvdaが指定される
BlockDeviceMappings/EBS/VolumeSize サイズ(GiB) ボリュームサイズ
BlockDeviceMappings/EBS/DeleteOnTermination 合わせて削除 インスタンス削除時にボリュームも削除するか否か
BlockDeviceMappings/EBS/VolumeType ボリュームタイプ
Monitoring モニタリング CloudWatch 詳細モニタリングを有効化
DisableApiTermination 削除保護の有効化 誤った削除からの保護
InstanceInitiatedShutdownBehavior シャットダウン動作 シャットダウン時にインスタンスを削除するか停止するか
IamInstanceProfile IAM ロール IAM インスタンスプロファイル

なお、Tagはインスタンスを起動しないと指定できない
この設定ファイルを用いてEC2インスタンスを起動する場合は、以下のコマンドを実行する。

<br>
aws ec2 run-instances --cli-input-json file:///tmp/ec2_settings.json<br>

この際、設定ファイルに誤りがある場合には、

<br>
Parameter validation failed:<br>
Invalid type for parameter SecurityGroups, value: XXXXXXXX, type: &lt;type 'unicode'&gt;, valid types: &lt;type 'list'&gt;, &lt;type 'tuple'&gt;<br>

などのように、エラーメッセージが返される。