業務でawsを使っていたらCloudTrailを設定しよう

awsを使っていたらCloudTrailを設定しよう

CloudTrailとは

  • AWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を可能にするサービスです。(公式)

CloudTrail-01-HeaderPic-v2-small.png

できること

  • アカウントアクティビティをログに記録し、継続的に監視し、保持できます。
  • SDK やコマンドラインツール、その他の AWS のサービスを使用して実行されるアクションなど、AWS アカウントアクティビティのイベント履歴を把握できます。
  • このイベント履歴により、セキュリティ分析、リソース変更の追跡、トラブルシューティングをより簡単に実行できるようになります。

メリット

コンプライアンスの簡素化

  • アカウント内で行われた操作のイベントログが自動的に記録および保存されるため、コンプライアンス監査を簡素化できます。
  • Amazon CloudWatch Logs との統合により、ログデータを検索したり、コンプライアンス違反のイベントを特定したり、インシデントの調査と監査者の要求に対する応答を迅速化したりできます。

ユーザーとリソースのアクティビティの可視化

  • AWS マネジメントコンソールでの操作と AWS API コールを記録することにより、ユーザーおよびリソースのアクティビティを把握しやすくなります。
  • AWS を呼び出したユーザーとアカウント、呼び出し元 IP アドレス、および呼び出し日時を特定できます。

セキュリティのオートメーション

  • セキュリティの脆弱性を引き起こす可能性のあるイベントが検出されたときに実行されるワークフローを定義できます。
  • 例えば、 Amazon S3 バケットを公開する API コールが CloudTrail によってログに記録されたときに特定のポリシーをそのバケットに追加する、というワークフローを作成できます。

利用してみる

  • CloudTrailにアクセスするとすでにログが記録されているのがわかります
  • 誰が何時に何の操作をしたのかがわかります

Screen Shot 2017-09-16 at 21.28.41.png

  • すべてのイベントを表示してみると

Screen Shot 2017-09-16 at 21.28.56.png

  • 7日以上のログを保存する場合や、アラートを飛ばしたいときは「証跡情報を作成」します

Screen Shot 2017-09-16 at 21.29.17.png

  • s3バケットなどを細かく設定できます!!!!!!

料金

  • WS CloudTrail を使用すると、サポートされたサービスの作成、変更、削除のオペレーションに関する過去 7 日間分のアカウントアクティビティの表示とダウンロードを無料で実行できます。

  • 証跡情報を作成する際に AWS CloudTrail からの課金は発生しません。CloudTrail の証跡を作成すると、Amazon S3 バケットに 2 種類のイベントを送信できるようになります。

  • 詳しくは公式の料金表

サポートされているサービス

ほとんどサポートされていますね

  • AWS Marketplace
  • Amazon Athena
  • Amazon CloudSearch
  • Amazon EMR
  • AWS Data Pipeline
  • Amazon Kinesis Firehose
  • Amazon Kinesis Streams
  • Amazon QuickSight
  • Amazon API Gateway
  • Amazon Elastic Transcoder
  • Amazon Elasticsearch Service
  • Amazon Simple Workflow Service
  • AWS Step Functions
  • Amazon Machine Learning
  • Amazon Polly
  • Amazon WorkDocs
  • アプリケーションの Auto Scaling
  • Auto Scaling
  • Amazon EC2 Container Registry
  • Amazon EC2 Container Service
  • AWS Elastic Beanstalk
  • Amazon Elastic Compute Cloud
  • Elastic Load Balancing
  • AWS Lambda
  • Amazon Lightsail
  • Amazon DynamoDB
  • Amazon ElastiCache
  • Amazon Redshift
  • Amazon Relational Database Service
  • Amazon WorkSpaces
  • AWS CodeBuild
  • AWS CodeCommit
  • AWS CodeDeploy
  • AWS CodePipeline
  • AWS CodeStar
  • Amazon GameLift
  • AWS IoT
  • AWS Application Discovery Service
  • AWS CloudFormation
  • AWS CloudTrail
  • Amazon CloudWatch
  • Amazon CloudWatch Events
  • Amazon CloudWatch Logs
  • AWS Config
  • AWS マネージドサービス
  • AWS OpsWorks
  • AWS OpsWorks for Chef Automate
  • AWS Organizations
  • AWS Service Catalog
  • Amazon Simple Email Service
  • Amazon Simple Notification Service
  • Amazon Simple Queue Service
  • AWS Database Migration Service
  • AWS Server Migration Service
  • Amazon Cognito
  • AWS Device Farm
  • Amazon CloudFront
  • AWS Direct Connect
  • Amazon Route 53
  • Amazon Virtual Private Cloud
  • AWS Certificate Manager
  • Amazon Cloud Directory
  • AWS CloudHSM
  • AWS Directory Service
  • AWS Identity and Access Management
  • Amazon Inspector
  • AWS Key Management Service
  • AWS Security Token Service
  • AWS WAF
  • Amazon Elastic Block Store
  • Amazon Elastic File System
  • Amazon Glacier
  • Amazon Simple Storage Service
  • AWS Storage Gateway
  • AWS Personal Health Dashboard
  • AWS サポート

サポートされていないもの

サポートされていないものもありますので注意が必要です。

Amazon AppStream
Amazon AppStream 2.0
Amazon Connect
Amazon Lex
Amazon Mobile Analytics
Amazon Pinpoint
Amazon Rekognition
Amazon WorkMail
AWS Batch
AWS Greengrass
AWS Shield
AWS Snowball
AWS X-Ray
Amazon Chime
Amazon WorkSpaces Application Manager
AWS Artifact
AWS Mobile Hub
AWS Snowball Edge
AWS Snowmobile
AWS Trusted Advisor

便利なリンク先

こちらいろいろやっていらっしゃる方がいます

まとめ

  • これでアカウントのガバナンス、コンプライアンス、運用監査、リスク監査を可能になりました。
  • 案外かんたんなので、設定触ってみることをおすすめします!

続きを読む

AWSのGPUインスタンスでjupyterを使う

機械学習の試行錯誤でGPUを使いたくなったとき、自前のPCにはGPUがないのでAWSを使います。
その時のやり方。

環境
– OS: Windows 10
– ターミナル: TeraTerm
– キー変換ツール: PuTTYgen

手順

  1. GPUインスタンスを借りる

    1. AWS Marketplaceで”Deep Learning AMI”と検索して出てくるAMIを選択。(今回はUbuntsuを使う)
    2. インスタンスタイプで”g2.2xlarge”を選択
    3. インスタンスの詳細の設定。
      ここでIAMロールは適切なものを。できればスポットインスタンスにすると安く済む
    4. セキュリティグループの設定
      SSHの接続元が初期設定0.0.0.0/0になっているのを’マイIP’に変更する
    5. 作成する。
  2. SSH転送の設定をする

    1. キーペア(*.pem)をダウンロードして、PuTTYgenで.ppk ファイルへ変換する。
    2. TeraTermのメニューから[設定] > [SSH転送]を開く
    3. [追加]から、[ローカルのポート]のほうへ8888, [リモート側ホスト]へlocalhost、[ポート]に8888を入力。[リッスン]には何も入力しない。
      (リモート側ホストがlocalhostというのが大事。SSHで接続したところから転送する先がそのマシンそのものということ)
  3. ターミナルでログインする

    1. ホスト名のところに ubuntsu@ec2-なんたらかんたら.compute.amazonaws.com といれる。
    2. 認証方式に [RSA/・・・鍵を使う]を選択して、秘密鍵に (PuTTYで変換した).ppkファイルを指定する。
    3. ログインできたら、jupyterを起動する。
      $ jupyter notebook
  4. ブラウザで表示
    ターミナルにログインURLが出てくるので、そのURLをブラウザに入力して開く

続きを読む

Streaming Serverを利用したライブストリーミング

やりたいこと

監視カメラなどの映像をスマートフォンで確認する場合、カメラのIPアドレスを指定したり、WebRTCを利用したりしてP2Pで直接メディアストリームを受信する方法が利用できます。ただ、カメラ映像を複数ユーザーが同時視聴したい場合、ネットワークやカメラのスペック上難しい場合がありサーバーで経由する必要があります。

今回はStreaming ServerをAWS上に立ててサーバー経由でのライブストリーミングを試作し、遅延時間を実測してみたいと思います。

Streaming Server

以下にStreaming Serverの比較が掲載されている。
https://en.wikipedia.org/wiki/Comparison_of_streaming_media_systems

今回は対応プロトコルが多いWowza Streaming Engineを利用して試作を行う。
https://www.wowza.com/

スクリーンショット 2017-08-15 10.34.08.png

Wowza Streaming Engineの立ち上げ

Wowzaのページで試用版のライセンスを購入します。アカウントの作成が必要です。
https://www.wowza.com/free-trial

登録が完了すると以下のようなメールでライセンスキーが発行されます。
スクリーンショット 2017-08-15 9.44.08.png

Market Placeで”Wowza”と入力して検索。
https://aws.amazon.com/marketplace

試用ライセンスを利用するので、2段目の”Bring Your License”を選択します。
スクリーンショット 2017-08-15 9.49.56.png

セットアップウィザードを進めて、デフォルトでインスタンスを起動。デフォルトではWowzaで推奨の”m3.large”が選択されます。
スクリーンショット 2017-08-15 9.59.43.png

Wowza Streaming Engineの設定

http://[EC2のPublic DNS]:8088/enginmanagerで設定画面に接続可能です。

スクリーンショット 2017-08-15 10.33.17.png

初期IDは”wowza”、パスワードは起動したインスタンスのID(i-xxxxxx)となります。

スクリーンショット 2017-08-15 10.35.07.png

ログイン直後にSouce Authenticationの設定が求められると思います。これは、カメラが映像をStreaming Engineに送信するための認証設定で後に必要となります。設定した情報は、Sever -> Source Authenticationで確認できます。

スクリーンショット 2017-08-15 11.04.06.png

Applicationを選択し、Liveを選択します。今回はiPhoneをカメラとして利用しますので、GoCoderを選択し、Host Server / Host Portの情報を確認しておきます。

スクリーンショット 2017-08-15 11.31.32.png

スクリーンショット 2017-08-15 11.38.51.png

GoCoderの設定

iPhoneもしくはAndroidでGoCoderアプリケーションをインストールします。アプリケーション起動後にWowza Streaming Engineの以下の3項目の設定を入力して下さい。

  • Host – 先ほど確認したサーバーのIPアドレスとポートナンバー
  • Application – liveとストリーム名を選択
  • Source Authentication – 先ほど設定したユーザ名とパスワード

上記の設定完了後に赤丸を押して配信を開始して下さい。

動作確認

まずRTMPのストリームが1本入っていることを確認します。

スクリーンショット 2017-08-15 12.04.16.png

右上のTest Playersを選択し、About HLSを選択するとURLが表示されるので、URLでブラウザで確認します。そうするとライブ映像の確認ができました。

スクリーンショット 2017-08-15 12.17.30.png

遅延時間の計測

両方向のネットワークがLTEであることもありますが、Camera ==RTMP==> Wowza Streaming Engine ==HLS==> Web Browserの経路ではほぼ40秒の遅延があることがわかりました。

HLSの場合もともと通信の安定性を考慮したプロトコルで低遅延のプロトコルではありません。10秒ごとのチャンクに切られて、遅延が15秒から45秒という仕様通りの挙動が確認できました。

HLS以外のプロトコルを選択することで遅延は減らせられそうです。以下のWowzaのページにも詳細が記述されています。RTMPもしくはWebRTCを選択するということになりそうです。

https://www.wowza.com/products/capabilities/low-latency

続きを読む

AWS節約術 4GiBのCentOS7ボリュームを作成

この記事ではAWS ec2上のCentOS7を使っています。

通常8GiB必要なCentOS7を、4GiBのボリュームで作成できるようにして、AWSの費用を削減しました。

なお、EC2 EBS縮小 (というより CentOS ディスク縮小) の流れを、大変参考にさせていただきました。

1. 背景

AWS ec2のインスタンスをたくさん作ると、EBSボリューム費用が莫迦にならなくなってきました。インスタンスそのものは、利用する時以外は落としておくことで、費用を節約することが可能です。一方、EBSボリュームは恒久的に利用しますので、ひと月の費用がまるまるかかってしまいます。

スクリーンショット 2017-07-31 21.21.10.png

こんな感じて、EBSの料金の比率が結構高いです。

CentOS7を使っていると、実際のディスク使用量は2GB〜3GBなのですが、最小のディスクサイズが8GiBであり、半分以上を無駄にしていることになります。Amazon Linuxであれば、最小2GiBからインスタンスが作れるのですが、やっぱりCentOSが使いたいですよね。

ボリュームを増やすことは、ec2のボリュームメニューから簡単にできるのですが、減らすことは簡単にできません。よって、小さいサイズで作っておいたほうが、使い回しが容易です。小は大を兼ねるのです。

ということで、4GiBボリュームでCentOS7が動作する環境を構築してみました。

2. 全体の流れ

全体の構成要素と流れは以下のようになります。

スクリーンショット 2017-07-31 22.19.20.png

3. 構築手順

3.1. 作業用インスタンスの作成

  • AWS MarketplaceからCentOS7を選択してインスタンス作成します。

    • 移行元用(ec2-old)、作業用(ec2-work)の2つを作成します。
    • 後の作業がやりやすいので、ボリュームにもインスタンスに対応するNameタグ(vol-old、vol-work)をつけておきます。
  • インスタンスを両方とも停止させます。
  • ec2のボリュームメニューで、vol-oldをデタッチします。
  • 移行先ボリューム(vol-new)を4GiBで新規作成します。
  • ec2-workに、vol-old、vol-newをアタッチします(デバイスIDはデフォルト値をそのまま利用します)。
  • ec2-workを起動してログインします。
$ sudo su -
# lsblk (確認)
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk 
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk 
└─xvdf1 202:81   0   8G  0 part 
xvdg    202:96   0   4G  0 disk 

3.2. 新ボリュームのパーティション作成とフォーマット

  • fdiskを使う例が多いのですが、ここでは非対話的にやりたいので、partedのコマンドラインでパーティションを作成し、フォーマットします。
# parted -s /dev/xvdg -- mklabel msdos mkpart primary xfs 1 -1 set 1 boot on
# parted -s /dev/xvdg print (確認)
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvdg: 4295MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  4294MB  4293MB  primary               boot

# mkfs.xfs /dev/xvdg1
meta-data=/dev/xvdg1             isize=512    agcount=4, agsize=262016 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=1048064, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
  • マウントして結果を確認します。
# mkdir -p /mnt/old /mnt/new/boot
# mount -t xfs -o nouuid /dev/xvdf1 /mnt/old
# mount -t xfs -o nouuid /dev/xvdg1 /mnt/new
# lsblk (確認)
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk 
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk 
└─xvdf1 202:81   0   8G  0 part /mnt/old
xvdg    202:96   0   4G  0 disk 
# df -kT (確認)
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/xvda1     xfs       8.0G  941M  7.1G  12% /
devtmpfs       devtmpfs  477M     0  477M   0% /dev
tmpfs          tmpfs     496M     0  496M   0% /dev/shm
tmpfs          tmpfs     496M   13M  483M   3% /run
tmpfs          tmpfs     496M     0  496M   0% /sys/fs/cgroup
tmpfs          tmpfs     100M     0  100M   0% /run/user/1000
tmpfs          tmpfs     100M     0  100M   0% /run/user/0
/dev/xvdf1     xfs       8.0G  941M  7.1G  12% /mnt/old
/dev/xvdg1     xfs       4.0G   33M  4.0G   1% /mnt/new

3.3. 新旧ボリュームのコピー

  • 新旧ボリュームをコピーして確認します。xvdg1の使用済みサイズがxvdf1と同じになったことがわかります。
# yum install xfsprogs xfsdump -y
(snip)
# cd /mnt/old/
# xfsdump -J - /mnt/old | xfsrestore -J -p 60 - /mnt/new
(snip)
xfsdump: Dump Status: SUCCESS
xfsrestore: restore complete: 17 seconds elapsed
xfsrestore: Restore Status: SUCCESS
# df -hT (確認)
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/xvda1     xfs       8.0G  1.1G  7.0G  13% /
devtmpfs       devtmpfs  477M     0  477M   0% /dev
tmpfs          tmpfs     496M     0  496M   0% /dev/shm
tmpfs          tmpfs     496M   13M  483M   3% /run
tmpfs          tmpfs     496M     0  496M   0% /sys/fs/cgroup
tmpfs          tmpfs     100M     0  100M   0% /run/user/1000
tmpfs          tmpfs     100M     0  100M   0% /run/user/0
/dev/xvdf1     xfs       8.0G  941M  7.1G  12% /mnt/old
/dev/xvdg1     xfs       4.0G  941M  3.1G  24% /mnt/new

3.4. ブートローダーのインストール

  • /mnt/new/ にチェンジルートします。
# mount -t proc /proc /mnt/new/proc
# mount -t sysfs /sys /mnt/new/sys
# mount --bind /dev /mnt/new/dev
# chroot /mnt/new/
# df -hT (確認)
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/xvdg1     xfs       4.0G  941M  3.1G  24% /
devtmpfs       devtmpfs  477M     0  477M   0% /dev
  • ブートローダーをインストールします。
# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-514.16.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-514.16.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-8bd05758fdfc1903174c9fcaf82b71ca
Found initrd image: /boot/initramfs-0-rescue-8bd05758fdfc1903174c9fcaf82b71ca.img
done
# grub2-install /dev/xvdg
Installing for i386-pc platform.
Installation finished. No error reported.
  • vol-newには新しいUUIDが付与されていますが、/etc/fstabはvol-oldからコピーしたため、不整合が残っています。UUIDを確認して、/etc/fstabの記述を正しいUUIDに修正します。
# blkid
/dev/xvda1: UUID="29342a0b-e20f-4676-9ecf-dfdf02ef6683" TYPE="xfs" 
/dev/xvdg1: UUID="96726bba-3ec0-4c18-a2d2-ef77f40c1837" TYPE="xfs" 
/dev/xvdf1: UUID="29342a0b-e20f-4676-9ecf-dfdf02ef6683" TYPE="xfs" 
# vi /etc/fstab (9672... に書き換える)
  • アンマウントしてシャットダウンします。
# exit
# cd /
# umount /mnt/old/ /mnt/new/proc /mnt/new/sys /mnt/new/dev /mnt/new/
# shutdown now

3.5. 新ボリュームでの起動確認

  • ec2-workから、vol-old、vol-newをデタッチします。
  • ec2-oldに、vol-newを/dev/sda1としてアタッチします。
  • 起動してログインできれば大成功!! 確かにファイルシステムのサイズが半減していますね。
$ df -kT (確認)
Filesystem     Type     1K-blocks   Used Available Use% Mounted on
/dev/xvda1     xfs        4182016 963300   3218716  24% /
devtmpfs       devtmpfs    487880      0    487880   0% /dev
tmpfs          tmpfs       507488      0    507488   0% /dev/shm
tmpfs          tmpfs       507488  12920    494568   3% /run
tmpfs          tmpfs       507488      0    507488   0% /sys/fs/cgroup
tmpfs          tmpfs       101500      0    101500   0% /run/user/1000
  • 作業に使ったec2-work、vol-work、vol-oldは削除してかまいません。
  • せっかく作ったインスタンスですので、ec2-old、vol-newの名前は適切に変更して、マイAMIとして登録しておきましょう。

続きを読む

AWS EC2やEBS周りの勉強メモ

EC2

AMIを検索

CLIで確認。
表示される結果が多いのでマネジメントコンソールで探したほうがいいか。

aws --output table --profile [profile] ec2 describe-images \
    --filters "Name=architecture,Values=x86_64" \
              "Name=root-device-type,Values=ebs" \
              "Name=virtualization-type,Values=hvm" 

ec2を作成・起動する

成功すれば、dry-runオプションを消して実行。

aws --region us-west-2 --profile [profile] ec2 run-instances \
    --image-id [AMI Id] \
    --key-name [key name] \
    --instance-type t2.micro \
    --user-data file://PATH/my_script.txt \
    --subnet-id [Subnet Id] \
    --dry-run

ユーザーデータはインスタンス作成時に実行するシェルスクリプトのファイル。
デフォルトだと作成したEC2インスタンスは停止して起動するたびに物理ホストが変わる。

インスタンスからメタデータへのアクセス

インスタンス内からそのメタデータを参照できる。
ユーザーデータなどの初期化スクリプトで参照するのに便利。

取得先は下記。
http://169.254.169.254/latest/meta-data

例えば、instance-idは下記で取れる。
http://169.254.169.254/latest/meta-data/instance-id

参考: http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

起動時のStatusチェック

下記の2つのチェックが行われる。

  • System Status Checks: インフラ側
  • Instance Status Checks: OS側

T2系のCPUクレジット

ベースライン性能以上のCPU利用率時にバーストする。
ベースライン性能は

  • t2.nano 5%
  • t2.micro 10%
  • t2.small 20%
  • t2.medium 40%

と低い値。

参考: http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/t2-instances.html

仮想化方式

  • 準仮想化(Paravirtual, PV)
  • 完全仮想化(Hardware-assisted VM, HVM)

VM Import/Export

VMWareやVirtualBoxのイメージからインポートできる。
http://dev.classmethod.jp/cloud/aws/vm-import-image-import/
HVMのみ対応。

AWS Marketplace

AWS上で実行されるソフトウェアやサービスを見つけて購入し、すぐに使用開始できるオンラインソフトウェアストア。

ボリューム

  • インスタンスストア
    EBSと異なり無料。
    揮発性で停止すると、書き込んでいた内容は消える。
    利用するには対応するインスタンスタイプを使用する必要がある。
    下記表のInstance Storageで”EBS only”になっていないインスタンスタイプで利用可。
    instance store.png
    タイプによって、利用できるインスタンスストアのサイズ等は決まっている。
    http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/InstanceStorage.html
    スワップ領域としても活用可能。
    CloudWatchで確認するときはEC2のDisk Metricを確認する。
  • EBS
    CloudWatchで確認するときはEBSのDisk Metricを確認する。

intance-store-backedインスタンスとEBS-backedインスタンス

intance-store-backedインスタンスはルートボリュームにインスタンスストアを指定したもの、
EBS-backedインスタンスはルートボリュームにEBSを指定したもの。
intance-store-backedインスタンスはs3-backedインスタンスとも呼ばれる。
intance-store-backedインスタンスは再起動と終了しかできない。

ルートボリュームはAMIの時点で決まっているので、intance-store-backedインスタンスを利用するにはそれ専用のAMIを利用する必要がある。

その他

  • EBS最適化インスタンス
    EBSとの接続時はDiskI/OよりNetworkのI/Oがボトルネックになる。(Provisioning EBS)
    これを解決するオプションで有効可していると帯域が確保される。
    m4, c4といった最近のタイプだとデフォルトオン。
  • プレイスメントグループ
    インスタンス間のネットワーク接続を高速化する。
    同一AZで使用できる。
  • Dedicatedインスタンス, EC2 Dedicated Host
    物理ホストを他者と共存させない仕組み。
  • Private IP
    VPCであれば、Stop/StartしてもIPは変わらない。
  • EC2が利用するIPアドレスレンジ
    http://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-ranges.html
    EC2の価格変更時にSNSで変更通知を受け取ることができる。
    AWS_SNS.png
    参考: http://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/price-notification.html

EBS

EBSはAZサービス。そのためあるAZ用に作成したEBSは別のAZからは利用できない。
別のAZから利用するためには一度Snapshotにしてから、別のAZ用に復元する。(別のリージョンで使用するときも同様)

ebs_snapshot_copy.png

EBSスナップショット

EBSのバックアップをとること。
結果はS3に保存する。(ただし、保存先を見ることはできない。EC2のダッシュボードから確認できる)

取得の際、I/Oを停止する必要があり、対象のEBSボリュームをアンマウントしてから取得開始することが推奨されている。
ただし、開始後はそれ以降の書き込みはキャプチャ対象外となるため、完了を待たずに再マウントして使用できる。
作成を指示し、レスポンスが返ってきたらその時点で開始されている。この時点でI/Oを再開して問題なし。
1世代目は実データをすべてバックアップ。2世代目以降は差分バックアップ。
ちなみに、復元の際はもとのボリュームのサイズを大きくすることも可能。

データボリュームの暗号化

暗号化を指定するとAES-256によって暗号化される。(Snapshotも同様)
暗号/復号にはハードウェア機能が用いられるため、パフォーマンスへの影響は極めて小さいとのこと。

その他

EC2はタイプごとにサポートできるIOPSが決まっている。EBSもIOPSが決まっている。ボトルネックの解決はそこに注意。

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSOptimized.html
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

続きを読む