https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/RootDeviceStorage.html

-> EBS 볼륨만 어태치 되어 있는 ec2에서 lsblk 커맨드와 메타데이터를 불러오는 커맨드를 실행하면 위와같은 정보를 보여준다.  ebs 볼륨만이 표시된다.

->instance store 볼륨만 어태치 되어 있는 ec2에서 lsblk 커맨드를 실행하면 ephemeral이라는 디스크가 나오는데 이게 instance store이다.

RDS

Amazon RDS では、お客様の DB インスタンスの自動バックアップはデフォルトで Amazon S3 に作成され、指定した期間安全に保存されます。さらに、スナップショットを作成することも可能です。スナップショットはユーザー起動型のインスタンスバックアップで、明示的に削除するまで保持されます。

ご希望の際にいつでも、データベーススナップショットから新しいインスタンスを作成できます。データベーススナップショットはフルバックアップとして動作しますが、ストレージ使用の増加分に対してのみ課金されます。

vpc

퍼블릭 서브넷에 위치하면 외부로 리퀘스트는 보낼 수 잇지만, 인스턴스가 퍼블릭 ip를 가지고 있지 안으면 레스폰을 받을 수 없기 때문에 외부와 통신이 안된다. 

RDS

EC2

VPC

EBS

スループット(Throughput)：일정시간 얼마만큼의 데이터 처리가 가능한지

レイテンシ(Latency)：리퀘스트 송신후 실제 레스폰스가 들어올때 까지의 시간

Amazon EC2 인스턴스 구성(https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-ec2-config.html)

애플리케이션에 맞게 EBS 볼륨을 계획하고 구성할 때는 볼륨을 연결할 인스턴스의 구성을 고려해야 합니다. EBS 볼륨의 성능을 최대한 활용하려면 EBS에 최적화된 인스턴스 또는 10Gb 네트워크 연결이 있는 인스턴스와 같이 볼륨을 지원할 수 있는 충분한 대역폭을 갖춘 인스턴스에 볼륨을 연결해야 합니다. 이것은 RAID 구성에서 여러 볼륨을 함께 스트라이프할 때 특히 중요합니다.

EBS에 최적화된 인스턴스 또는 10Gb 네트워크 인스턴스 사용

프로덕션 데이터베이스 또는 비즈니스 애플리케이션과 같이 가변성을 최소화하고 Amazon EBS 트래픽 전용 Amazon EC2를 사용해야 하는 성능에 민감한 작업은 EBS에 최적화된 인스턴스나 10Gb 네트워크 연결이 있는 인스턴스에 연결되는 볼륨을 사용해야 합니다. 이 기준에 맞지 않는 EC2 인스턴스는 네트워크 리소스에 대한 보증을 제공하지 않습니다. EC2 인스턴스와 EBS 볼륨 간에 지속적이고 안정적인 네트워크 대역폭을 보장하는 유일한 방법은 EC2 인스턴스를 EBS에 최적화된 인스턴스로 시작하거나 10Gb 네트워크 연결이 있는 인스턴스 유형을 선택하는 것입니다. 10Gb 네트워크 연결이 있는 인스턴스 유형을 확인하려면 Amazon EC2 인스턴스 유형 단원을 참조하십시오. EBS 최적화 인스턴스 구성에 대한 자세한 내용은 Amazon EBS 최적화 인스턴스를 참조하십시오.

Amazon EBS 최적화 인스턴스(https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/EBSOptimized.html)

Amazon EBS 최적화 인스턴스는 최적화된 구성 스택을 사용하며 Amazon EBS(EBS) I/O를 위한 추가 전용 용량을 제공합니다. 이러한 최적화를 통해 인스턴스에서 Amazon EBS I/O와 기타 트래픽 간의 경합이 최소화되어 EBS 볼륨의 성능이 극대화됩니다.

EBS 최적화 인스턴스는 Amazon EBS에 전용 대역폭을 제공하며, 사용하는 인스턴스 유형에 따라 425Mbps와 14,000Mbps 사이의 범위에서 선택할 수 있습니다. EBS 최적화 인스턴스에 연결된 범용 SSD(gp2) 볼륨은 연중 99%의 시간 동안 기본 성능 및 버스트 성능을 10% 이내의 오차로 제공하도록 설계되며, 프로비저닝된 IOPS SSD(io1) 볼륨은 연중 99.9%의 시간 동안 프로비저닝 성능을 10% 이내의 오차로 제공하도록 설계됩니다. 처리량에 최적화된 HDD(st1) 및 Cold HDD(sc1)는 모두 연중 99%의 기간 동안 90%의 버스트 처리량에 성능 일관성을 보장합니다. 매 시간 총 처리량 목표 99%를 달성하기 위해, 준수하지 않는 기간은 대략적으로 균등하게 분산됩니다. 자세한 내용은 Amazon EBS 볼륨 유형 단원을 참조하십시오.

RDS

IAM

EBS

RDS

RDS DB 인스턴스 세부 설정입니다(그림 13-8).

• License Model: MySQL은 general-public-license만 선택할 수 있습니다.
• DB Engine Version: 사용할 MySQL의 버전입니다. 특정 버전을 사용해야 하는 환경이 아니라면 기본값 그대로 사용합니다.
• DB Instance Class: 생성할 DB 인스턴스 클래스입니다. 프리 티어에서 무료로 사용할 수 있는 마이크로 인스턴스(db.t1.micro)를 선택합니다.
• Multi-AZ Deployment: 장애에 자동으로 대처하는 Failover 기능을 위한 다중 가용 영역(Multi Availability Zone) 복제 옵션입니다. No를 선택합니다.
• Allocated Storage: DB에서 데이터를 저장할 스토리지의 용량입니다. 최소 5GB에서 3072GB(3TB)까지 설정 할 수 있습니다. 5GB로 설정합니다.
• Use Provisioned IOPS: 고성능 I/O 옵션입니다. 이 옵션을 사용하면 스토리지의 읽기/쓰기 성능을 원하는 대로 조절할 수 있습니다. 단 추가비용을 지불해야 합니다. 기본값 그대로 사용합니다.
• DB Instance Identifier: DB 인스턴스의 이름입니다(이름은 같은 리전 안에서 중복되면 안됩니다). exampledbinstance로 설정합니다.
• Master Username: MySQL DB 관리자 계정입니다. admin으로 설정합니다.
• Master Password, Confirm Password: MySQL DB 관리자 계정의 비밀번호입니다. 여러분이 사용하고 싶은 비밀번호를 설정합니다.

설정이 완료되었으면 Next Step 버튼을 클릭합니다.

그림 13-8 RDS DB 인스턴스 설정

DB 인스턴스 추가 설정입니다(그림 13-9).

• VPC: DB 인스턴스가 위치할 네트워크(VPC)입니다. 기본값 그대로 사용합니다.
• DB Subnet Group: DB 인스턴스가 위치할 서브넷입니다. 위에서 Default VPC이외의 VPC를 선택했을 때 이 서브넷을 설정할 수 있습니다. 기본값 그대로 사용합니다.
• Publicly Accessible: DB를 외부에서 접근할 수 있게 하는 옵션입니다. No로 설정하면 VPC 내부에서만 접근할 수 있습니다. 기본값 그대로 사용합니다.
• Availability Zone: DB 인스턴스가 생성될 가용 영역(Availability Zone)입니다. EC2 인스턴스에서 DB에 접속한다면 같은 AZ에 있는 것이 좋습니다. 기본값 그대로 사용합니다.
• VPC Security Group: 방화벽 설정인 Security Group입니다. 기본값 그대로 사용합니다. 이 Security Group은 나중에 DB 인스턴스 전용으로 따로 생성해야 합니다.
• Database Name: 생성할 DB 이름입니다. ExampleDB로 설정합니다. 아무것도 입력하지 않으면 DB 인스턴스에서 MySQL 서버만 실행되고 DB는 생성되지 않습니다.
• Database Port: DB 접속 포트 번호입니다. 기본값 그대로 사용합니다.
• Parameter Group: MySQL을 실행할 때 필요한 파라미터 집합입니다. DB 인스턴스 생성 후 Parameter Group을 추가할 수 있습니다(my.cnf 파일을 생성하는 것과 동일합니다.) 기본값 그대로 사용합니다.
• Option Group: DB 옵션입니다. MySQL은 특별히 지정하지 않아도 됩니다. 기본값 그대로 사용합니다.

그림 13-9 RDS DB 인스턴스 추가 설정

이어지는 DB 인스턴스 추가 설정입니다(그림 13-10).

• Backup: 자동 백업 옵션입니다. 이 자동 백업을 사용하면 원하는 시점으로 데이터를 복구할 수 있는 PIT(Point in Time) 복구를 사용할 수 있습니다. PIT 복구는 최근 5분 전 상태로 되돌릴 수 있으며 1초 단위로 설정이 가능합니다.
• Backup Retention Period: 백업 데이터 유지 기간입니다. 최대 35일까지 설정할 수 있습니다. 여기서 지정한 날짜 이전까지 되돌릴 수 있습니다.
• Backup Window: 백업 시간입니다. 기본값은 No Preference입니다. 여기서는 Select Window를 선택하고 Start Time을 00:00, Duration을 0.5로 설정합니다. UTC 기준으로 00시 00분에 백업을 시작하며 백업 시간은 0.5시간(30분)입니다. 데이터의 용량이 크면 설정한 백업 시간을 넘길 수도 있습니다. 이 Duration을 설정하는 이유는 아래 Maintenance Window의 시간과 겹치지 않게 하기 위해서 입니다.
• Auto Minor Version Upgrade: 자동으로 마이너 버전을 업데이트하는 옵션입니다. 보안 패치나 버그가 수정된 버전을 자동으로 업데이트합니다. 예를 들면 MySQL의 경우 5.6.13을 사용하고 있는데 5.6.14가 나오면 5.6.14 버전으로 업데이트하게 됩니다. 기본값 그대로 사용합니다.
• Maintenance Window: 점검 시간입니다. 기본값은 No Preference입니다. 여기서는 Select Window를 선택하고 Start Day를 Monday, Start Time을 03:00, Duration을 0.5로 설정합니다. UTC 기준으로 03시 00분에 점검이 시작되며 시간은 0.5시간(30분)입니다. Duration을 설정하는 이유는 위 Backup Window의 시간과 겹치지 않게 하기 위해서 입니다. 점검은 Duration에 설정한 시간보다 일찍 끝날 수 있습니다.
  • 이 시간에 Auto Minor Version Upgrade를 설정했다면 DB 버전 업데이트 또는 패치가 적용됩니다. DB 버전 업데이트 또는 패치는 필수적인 것(보안 패치)만 적용되며 자주 발생하지 않고 몇 달에 한 번 발생합니다. DB 업데이트 또는 패치가 적용되는 시간 동안에는 DB 인스턴스의 실행이 중지됩니다.
  • DB 인스턴스 클래스를 변경했다면 이 시간에 적용됩니다. DB 인스턴스 클래스를 변경하는 동안에는 DB 인스턴스의 실행이 중지됩니다.

설정이 완료되었으면 Launch DB Instance 버튼을 클릭합니다.

EC2

EC2

インスタンスを基盤となるハードウェアに配置する方法を決定するプレイスメントグループで､インスタンスを起動または開始できます。プレイスメントグループを作成するときは、グループの次のいずれかの戦略を指定します。

■クラスタプレイスメントグループ

クラスタープレイスメントグループは、単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。</b>ネットワークレイテンシーが低い場合、ネットワークスループットが高い場合、またはその両方の場合にメリットがあるアプリケーションでは、プレイスメントグループの使用をお勧めします。プレイスメントグループで、最も低いレイテンシーと最も高いネットワークパフォーマンス (1 秒あたりパケット数) を実現するためには、拡張ネットワーキングをサポートするインスタンスタイプを選択します。<br>

単一の起動リクエストでは、プレイスメントグループ内で必要な数のインスタンスを起動することと、プレイスメントグループ内のすべてのインスタンスで同じインスタンスタイプを使用することをお勧めします。後でプレイスメントグループにさらにインスタンスを追加しようとした場合、またはプレイスメントグループ内で複数のインスタンスタイプを起動しようとした場合、容量不足エラーが発生する可能性が高くなります。

プレイスメントグループ内のインスタンスを停止して再起動しても、そのインスタンスは同じプレイスメントグループ内で実行されます。ただし、インスタンスに対して十分な容量がない場合、起動は失敗します。

既にインスタンスを実行中のプレイスメントグループ内のインスタンスを起動するときに容量エラーを受け取った場合は、プレイスメントグループ内のすべてのインスタンスを停止して開始し、もう一度起動を試みてください。インスタンスを再起動すると、リクエストされたすべてのインスタンスの容量があるハードウェアに移行される場合があります。<br>

<br>

■スプレッドプレイスメントグループ

スプレッドプレイスメントグループは、それぞれ異なるハードウェアに配置されるインスタンスのグループです。

スプレッドプレイスメントグループは、少数の重要なインスタンスが互いに分離して保持される必要があるアプリケーションに推奨されます。スプレッドプレイスメントグループでインスタンスを起動すると、インスタンスが同じ基本ハードウェアを共有するときに発生する可能性のある､同時障害のリスクが軽減されます。スプレッドプレースメントグループは、異なるハードウェアへのアクセスを提供するため、長時間のインスタンスタイプの混合やインスタンスの起動に適しています。

スプレッドプレイスメントグループは複数のアベイラビリティーゾーンにまたがることができ、グループごとにアベイラビリティーゾーンごとに最大 7 つの実行インスタンスを持つことができます。

スプレッドプレイスメントグループでインスタンスを開始または起動し、リクエストを実行するための固有のハードウェアが不足している場合、そのリクエストは失敗します。Amazon EC2 では、時間の経過とともにより明確なハードウェアを利用できるようになりますので、後でリクエストを再試行できます。

S3

米国東部 (バージニア北部)リージョンの Amazon S3 バケットは、結果整合性を提供します。それ以外のリージョンでの Amazon S3 バケットは、新しいオブジェクトの PUT については「書き込み後の読み込み」整合性、PUT および DELETE の上書きについては結果整合性を提供します。<br>

<br>

■データ整合性モデル<br>

•３つのデータセンターにデータを同期するため以下の整合性モデルとなる<br>

•新規ファイルをアップロード時は、「書き込み後の読み込み」整合性→書き込み後すぐ読み込みを行っても問題なく読み込まれる<br>

•既存ファイルの上書き・削除時は、古いデータを参照または削除ファイルを参照できる状態となり、結果整合性となる→更新後すぐに読み込みを行うと、更新前の情報が返される可能性がある。時間が立つと更新後の状態を返すモデル

RDS

ETC

RDS

EBS

EC2Configを用いることで、すべての Amazon EBS ボリュームおよびインスタンスストアボリュームをフォーマットおよびマウントし、ボリューム名をドライブ文字にマップすることができます。<br>

インスタンスが起動するたびに次のタスクを実行します。

■16 進数表記のプライベート IP アドレスと一致するようにコンピュータのホスト名を変更する（このタスクはデフォルトでは無効になっているので、このタスクを有効にしてインスタンスの起動時に実行する必要があります）。

■key management server （KMS）を構成し、Windows アクティベーションのステータスを確認して、必要に応じて Windows のアクティベーションを行います。

■すべての Amazon EBS ボリュームおよびインスタンスストアボリュームをフォーマットおよびマウントし、ボリューム名をドライブ文字にマップします。

■イベントログエントリをコンソールに出力し、トラブルシューティングに役立てる（このタスクはデフォルトでは無効になっているので、このタスクを有効にしてインスタンスの起動時に実行する必要があります）。

■コンソールに Windows の準備が完了した旨の通知を出力する。

■複数の NIC がアタッチされているとき、プライマリネットワークアダプタにカスタムルートを追加して、IP アドレス 169.254.169.250、169.254.169.251、および 169.254.169.254 を有効にする。これらのアドレスは Windows ライセンス認証が使用し、またユーザーがインスタンスのメタデータにアクセスする際にも使用します。

EC2

RDS

RDS

DB 파라미터 그룹의 파라미터를 사용하여 DB 엔진 구성을 관리합니다. DB 파라미터 그룹은 하나 이상의 DB 인스턴스에 적용되는 엔진 구성 값의 컨테이너 역할을 합니다.

고객이 생성한 DB 파라미터 그룹을 지정하지 않고 DB 인스턴스를 생성할 경우 기본 DB 파라미터가 생성됩니다. 각 기본 DB 파라미터 그룹에는 인스턴스의 엔진, 컴퓨팅 클래스 및 할당된 스토리지에 따른 데이터베이스 엔진 기본값과 Amazon RDS 시스템 기본값이 들어 있습니다. 기본 DB 파라미터 그룹의 파라미터 설정을 수정할 수 없습니다. DB 파라미터 그룹을 직접 생성하여 해당 기본값에서 파라미터 설정을 변경해야 합니다. 고객이 생성한 DB 파라미터 그룹에서 모든 DB 엔진 파라미터를 변경할 수 있는 것은 아닙니다.

사용자 고유의 DB 파라미터 그룹을 사용하는 경우 새 DB 파라미터 그룹을 만들고, 원하는 파라미터를 수정하고, 새 DB 파라미터 그룹을 사용하도록 DB 인스턴스 를 수정하면 됩니다. 특정 DB 파라미터 그룹과 연결된 모든 DB 인스턴스는 해당 DB 파라미터 그룹에 대한 모든 파라미터 업데이트를 가져옵니다.

동적 파라미터(dynamic parameter)를 변경하고 DB 파라미터 그룹을 저장하면 즉시 적용 설정과 관계없이 변경 내용이 바로 적용됩니다. 고정 파라미터를 변경하고 DB 파라미터 그룹을 저장하면 DB 인스턴스를 수동으로 재부팅한 후에 파라미터 변경 내용이 적용됩니다. RDS 콘솔을 사용하거나 명시적으로 RebootDbInstance API 작업을 호출하여 DB 인스턴스를 재부팅할 수 있습니다(DB 인스턴스가 다중 AZ 배포에 있는 경우 장애 조치 없음). 고정 파라미터(static parameter) 변경 후 연결된 DB 인스턴스를 재부팅하도록 하면 ModifyDBInstance를 호출하여 DB 인스턴스 클래스를 변경하거나 스토리지를 조정하는 경우와 같이 잘못된 파라미터 구성이 API 호출에 영향을 주는 위험을 완화할 수 있습니다.

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html#USER_WorkingWithParamGroups.Creating

EC2

네트워크 인터페이스란 쉽게 이해하자면 랜선을 꼽는 포트로, 랜선을 꼽는 포트는 물리적 네트워크 개념이고, aws에서 말하는 네트워크 인터페이스는 논리적 개념을 말한다. 보통 랜선포트는 물리적으로 하나의 컴퓨터에 하나밖에 존재하지 않기 때문에 각 컴퓨터는 하나의 퍼블릭아이디와 하나의 프라이뱃 아이피를 갖지만, 논리 네트워크 인터페이스를 통해서는 하나의 머신에 여러개의 아이피를 어태치 할 수 있다.

aws에서 복수의 ip를 네트워크 인터페이스에 추가하는 방법 : https://recipe.kc-cloud.jp/archives/6513

인스턴스 유형별/네트워크 인터페이스당 IP 주소:https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-eni.html#eni-basics

EBS

Amazon EBS 스냅샷 생성(https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html)

EBS 볼륨의 특정 시점 스냅샷은 새 볼륨 또는 데이터 백업의 기준으로 사용할 수 있습니다. *볼륨의 스냅샷이 주기적으로 생성되는 경우 스냅샷은 증분식이므로 마지막 스냅샷 이후 변경된 디바이스의 블록만 새 스냅샷에 저장됩니다. 스냅샷은 증분식으로 저장되지만 스냅샷 삭제 프로세스는 전체 볼륨을 복원하기 위해 *가장 최근의 스냅샷만을 유지할 수 있도록 설계됩니다.

스냅샷은 비동기적으로 생성됩니다. 특정 시점 스냅샷은 즉시 생성되지만 스냅샷이 완료될 때까지, 즉 *수정된 블록이  Amazon S3로 모두 이동할 때까지 스냅샷 상태는 pending입니다.(볼륨이 펜딩인게 아니라 스냅샷이 팬딩이므로 볼륨의 사용에는 영향을 받지않음) 따라서 크기가 큰 최초의 스냅샷이나 변경된 블록이 많은 후속 스냅샷의 경우 몇 시간씩 시간이 걸릴 수 있습니다. 완료하는 동안 진행 중인 스냅샷은 볼륨에 대한 지속적인 읽기 및 쓰기의 영향을 받지 않습니다.

암호화된 볼륨으로 생성한 스냅샷은 자동으로 암호화됩니다. 암호화된 스냅샷으로 생성한 볼륨도 자동으로 암호화됩니다. 암호화된 볼륨 및 모든 연관 스냅샷의 데이터는 사용되지 않을 때와 사용될 때 모두 보호됩니다. 자세한 정보는 Amazon EBS 암호화 단원을 참조하십시오.

기본적으로 사용자는 자기 소유의 스냅샷에서만 볼륨을 생성할 수 있습니다. 하지만 암호화되지 않은 스냅샷은 특정 AWS 계정과 공유하거나 공개 상태로 지정하여 전체 AWS 커뮤니티에서 공유할 수 있습니다. 자세한 정보는 Amazon EBS 스냅샷 공유 단원을 참조하십시오.

암호화된 스냅샷은 특정 AWS 계정과만 공유할 수 있습니다. 다른 계정의 사용자가 암호화된 공유 스냅샷을 사용할 수 있도록 하려면 해당 스냅샷을 암호화할 때 사용했던 CMK 키도 공유해야 합니다. 암호화된 스냅샷에 대한 액세스 권한이 있는 사용자는 개인적으로 자체 복사본을 만들고 이를 사용해 볼륨을 복원해야 합니다. 암호화된 공유 스냅샷의 복사본을 다른 키로 다시 암호화할 수도 있습니다. 자세한 정보는 Amazon EBS 스냅샷 공유 단원을 참조하십시오.

AWS Marketplace 제품 코드를 가진 볼륨에서 스냅샷을 만들면 해당 제품 코드가 스냅샷으로 전파됩니다.

연결되어 사용 중인 볼륨의 스냅샷을 만들 수 있습니다. *하지만 스냅샷은 snapshot 명령을 실행할 때 Amazon EBS 볼륨에 기록된 데이터만 캡처합니다. 이때 애플리케이션이나 운영 체제에 의해 캐시된 데이터가 제외될 수 있습니다. 스냅샷을 만들기에 충분한 시간 동안 볼륨에 대한 파일 쓰기 작업을 일시 중지할 수 있는 경우 스냅샷이 완전해야 합니다. 하지만 볼륨에 대한 모든 파일 쓰기를 일시 중지할 수는 없는 경우에는 인스턴스 내에서 볼륨을 분리하고 snapshot 명령을 실행한 다음, 볼륨을 다시 마운트하여 일관되고 완전한 스냅샷이 되도록 해야 합니다. 스냅샷 상태가 pending인 상태에서 볼륨을 다시 마운트하고 사용할 수 있습니다.

*루트 디바이스 역할을 하는 Amazon EBS 볼륨의 스냅샷을 만들려면 인스턴스를 중지한 후 스냅샷을 만들어야 합니다.

Linux에서 볼륨을 분리하려면 다음 명령을 사용합니다. 여기에서 device_name은 장치 이름입니다(예: /dev/sdh).

umount -d device_name

스냅샷을 보다 쉽게 관리하기 위해 생성 중에 스냅샷에 태그를 지정하거나 나중에 태그를 추가할 수도 있습니다. 예를 들어, 스냅샷이 생성된 원래 볼륨 또는 원래 볼륨을 인스턴스에 연결하는 데 사용된 디바이스 이름을 설명하는 태그를 적용할 수 있습니다. 자세한 정보는 Amazon EC2리소스에 태그 지정단원을 참조하십시오.

S3

분할해서 올린 후 S3 위에서 하나로 합쳐진다.

【AWS】S3のマルチパートアップロードで簡易サスペンド／レジュームを実装してみた：https://dev.classmethod.jp/cloud/aws/aws-s3-multipart-upload/

RDS

EBS

RDS

Backup Retention Period を 0 にすることで自動バックアップが無効になります。無効にすることによってリードレプリカの作成(Create Read Replica)と時刻指定のリストア(Restore To Point In Time)のボタン自体も無効になります。

無効にした自動バックアップをすぐに有効にするには以下の操作を行います。

1.AWS マネジメントコンソールにサインインし、Amazon RDS コンソール（https://console.aws.amazon.com/rds/）を開きます。

2.ナビゲーションペインで、[DB Instances] をクリックし、変更する DB インスタンスの横にあるチェックボックスをオンにします。

3.[Modify] ボタンをクリックするか DB インスタンスを右クリックして、コンテキストメニューから [Modify] を選択します。

[Modify DB Instance] ウィンドウが表示されます。

4. [Backup Retention Period] ドロップダウンリストボックスで [3（0以外）] を選択します。 

5. [Apply Immediately] チェックボックスをオンにします。 

6. [OK] ボタンをクリックします。 </div>

RDS

RDS

EC2

料金がかかる場合とかからない場合があります。最低料金の設問ですので、答えは無料になります。以下の料金表をご確認ください。パブリックまたは Elastic IP アドレスの使用した場合は料金は発生しますので、プライベートIPアドレスを使用した方が良いですね。

料金（リージョン：バージニア 2016/11時点）

■Amazon EC2 へのデータ転送受信（イン）

同じアベイラビリティーゾーンの Amazon EC2、Amazon RDS、Amazon Redshift および Amazon ElastiCache インスタンスまたは Elastic Network Interface

・プライベート IP アドレスの使用　　　　　　　$0.00 /GB

・パブリックまたは Elastic IP アドレスの使用　$0.01 /GB

■Amazon EC2 からのデータ転送送信（アウト）

同じアベイラビリティーゾーンの Amazon EC2、Amazon RDS、Amazon Redshift または Amazon ElastiCache インスタンス、Amazon Elastic Load Balancing、または Elastic Network Interface

・プライベート IP アドレスの使用　　　　　　　$0.00 /GB

・パブリックまたは Elastic IP アドレスの使用　$0.01 /GB

補足：

同じ AWS リージョンの別のアベイラビリティーゾーンまたはピアリング接続された VPC 上間の通信料は有料になります。

参考URL:<a href="https://aws.amazon.com/jp/ec2/pricing/" target="_blank">料金

VPC

CLOUDTAIL

DIRECT CONNECT

CLOUDFRONT

IAM

【STSとは？】

AWS Security Token Service (AWS STS) を使用して、AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。一時的セキュリティ認証情報の機能は、IAM ユーザーが使用できる長期的なアクセスキー認証情報とほとんど同じですが、次の相違点があります。

【AWS Security Token Service(STS)を利用してIAMとLDAPを連携すること】

 AWS Security Token Service(STS)を利用してIAMとLDAPを連携することが可能です。STSの利用ケースは以下の通りです。

・オンプレID（SAML,LDAP）との認証連携

・Web ID（Amazon,Google等）との認証連携

・クロスアカウントアクセス（他のAWSアカウントからアクセス可能）

・EC2ロール（一時IDをロールに与えたEC2上に発行する）

1.従業員がAWSベースのレポーティングアプリケーションを用いて、情報をAmazon S3に保存しようとします

2.アプリケーションは、身元確認ブローカー(仮名、右参照)をコールします。ブローカーは、従業員のIDをインプットとして受け取ります

3.身元確認ブローカーは、企業のLDAPディレクトリを使い、従業員の身元確認を行います

4.身元確認ブローカーは、IAMのセキュリティ証明書を用いて、新しいGetFederationToken関数を呼び出します。このコールは、IAMポリシーと期間(1時間～36時間)を含んでいる必要があり、発行する一時発行セキュリティ証明書に与えるべきパーミッションを指定したポリシーも付け加えます

5.Security Token Serviceは、この関数をコールしたIAMユーザーのポリシーが、新しいトークンを作成するのに十分なパーミッションを満たしているか確認したのちに、アクセスキー、シークレットキー、トークン、有効期限(トークンの生存期間を返します。

6.身元確認ブローカーは、一時発行セキュリティ証明書をレポーティングアプリケーションに返します

7.レポーティングアプリケーションは、一時発行セキュリティ証明書(トークンを含んだ)を用いて、Amazon S3にリクエストを作成します

8.Amazon S3は、この一時発行セキュリティ証明書が、指定したS3バケットとオブジェクトに対するアクセス権を持っているか、IAMを用いて確認します

9.IAMは、S3に問題が無いことを告げます

<img src="//aws.koiwaclub.com/wp-content/uploads/2015/12/id-federation.png">

参考URL:

http://aws.typepad.com/aws_japan/2011/08/aws-identity-and-access-management-now-with-identity-federation.html

ROUTE53

EC2

Amazon EC2で利用できるプラットフォームには、EC2-VPCとEC2-Classicの2種類があります。EC2-Classicが利用できる環境ではデフォルトVPCが存在しません。そのような環境でデフォルトVPCを作成するには、AWSサポートへの依頼が必要になります。

ただし、デフォルトVPCを作成するためには、そのリージョンに存在するEC2-Classicリソースを終了する必要があり、今後そのリージョンでEC2-Classicを使用することができなくなります

CLOUDWATCH

CLOUDTAIL

ETC

すべての侵入テストに許可が必要です。

また、AWS のポリシーではお客様が所有する以下のリソースが許可されます。

・EC2

・RDS

・Aurora

・CloudFront

・API ゲートウェイ

・Lambda

・Lightsail

・DNS Zone Walking

AWS の他のサービスや、AWS で所有しているリソースに対するテストは禁止されています。詳細は以下のURLをご確認ください。

参考URL：<a href="https://aws.amazon.com/jp/security/penetration-testing/" target="_blank">AWS のポリシーでは、以下のリソースに対するテストのみが許可されます。</a> </div>

AWS CloudFormation は テンプレート(JSON方式)のファイルを記述して、Amazon EC2を自動で構築するサービスになります。

その他の選択肢については以下のサービスになります。

AWS Direct Connect は、AWS クラウドサービスを利用するのにインターネットを使用する代わりの方法を提供するネットワークサービスです。

Amazon Simple Email Service (Amazon SES)は、企業や開発者のための、非常にスケーラブルで、コスト効率のよい E メールサービスです

AWS Elastic Beanstalk は、AWS クラウド内でのアプリケーションのデプロイと管理をさらに簡単にするサービスです。開発者は単にそのアプリケーションをアップロードするだけで、Elastic Beanstalk が自動的に容量のプロビジョニング、負荷分散、Auto-Scaling、およびアプリケーション状態モニタリングといったデプロイの詳細を処理します。

Amazon ElastiCacheはAmazon ElastiCacheは、AWSが提供するMemcached サーバでメモリ内キャッシュの縮小・拡張を容易にするサービスで、メモリ内キャッシュシステムから情報を取得できるようにすることで、Webアプリケーションのパフォーマンスを向上することも可能です。</div>

EBS

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html

IAM

ENI

Elastic Network Interface を使用して管理用ネットワークを作成できます。このシナリオでは、インスタンスのセカンダリ Elastic Network Interface でパブリック側のトラフィックを処理し、プライマリ Elastic Network Interface でバックエンドの管理用トラフィックを処理します。プライマリ Elastic Network Interface はアクセス制御を強化した VPC 内の個別のサブネットに接続されます。パブリック側のインターフェイス（ロードバランサーの背後に置かれる場合とそうでない場合があります）には、インターネットからサーバーへのアクセスを許可するセキュリティグループが関連付けられます（たとえば、0.0.0.0/0 またはロードバランサーからの TCP ポート 80 および 443 を許可します）。プライベート側のインターフェイスには、VPC 内またはインターネットからの許容範囲の IP アドレス、VPC 内のプライベートサブネット、または仮想プライベートゲートウェイからの SSH アクセスのみを許可するセキュリティグループが関連付けられます。

フェイルオーバー機能が確実に動作するように、Elastic Network Interface の受信トラフィックに対して<b>セカンダリプライベート IP </b>を使用することをお勧めします。インスタンスに障害が発生した場合は、インターフェイスまたはセカンダリプライベート IP アドレスあるいはその両方をスタンバイ用のインスタンスに移行できます。

RDS

DB スナップショットの作成

Amazon RDS は DB インスタンスのストレージボリュームのスナップショットを作成し、個々のデータベースだけではなく、その DB インスタンス全体をバックアップします。Single-AZ DB インスタンスでこの DB スナップショットを作成すると、I/O が短時間中断します。この時間は、DB インスタンスのサイズやクラスによって異なり、数秒から数分になります。マルチ AZ DB インスタンスは、スタンバイ側でバックアップが作成されるため、この I/O 中断の影響を受けません。

【利用可能なホスト数が16個より少ない理由】

15の部分は、「0番～255番」までの256個の番号を割り当てることができます。
ただ、実際には、0番はネットワークアドレス、1番はルーターなどの出入り口の機器、最後の255番は一斉通信に使われてしまうので、パソコンやスマホ・ネットワークプリンタ等々に対しては実質、256-3=253台分（2番から254番まで）のホストアドレスが割り当てられる（＝接続できる）格好となります。

ELB

EBS

ボリュームは、ランダムアクセス I/O スループットにおけるストレージパフォーマンスと整合性が重要な、I/O 集約型ワークロード（特にデータベースワークロード）のニーズを満たすように設計されています。ボリューム作成時に IOPS レートを指定します。Amazon EBS は 1 年間のうちの 99.9%、プロビジョンド IOPS をパフォーマンスの 10% 内で提供します。

<b>Provisioned IOPS (SSD) ボリュームのサイズは 4 GiB ～ 16 TiB であり、ボリュームあたり最大 20,000 IOPS をプロビジョニングできます。</b>指定されたボリュームサイズに対してサポートできるプロビジョンド IOPS の比率は最大 30 倍です。たとえば、3,000 IOPS のボリュームは、100 GiB 以上である必要があります。サイズの拡張とパフォーマンスの向上をご希望の場合、複数のボリュームを 1 つにまとめてストレイプ構成にすることができます。

Provisioned IOPS (SSD) ボリュームにはプロビジョニングされる IOPS ごとに 256 KiB、（1,280 IOPS で）最大 320 MiB/秒のスループット制限範囲があります。

ELB

HTTP および HTTPS リスナーを使用する場合は、インスタンスで HTTP キープアライブのオプションを有効にすることをお勧めします。インスタンスのウェブサーバー設定で キープアライブを有効にできます。キープアライブを有効にすると、ロードバランサーがインスタンスへの接続を再利用できるようになり、CPU 使用率が削減されます。ロードバランサーがインスタンスへの接続を確実に閉じるようにするには、HTTP キープアライブ時間の値をロードバランサーのアイドルタイムアウト設定よりも大きい値に設定する必要があります。-> 킵어라이브 (http의 연결을 websocket처럼 유지하는 것, 인스턴스 쪽에서 설정함)을 자동 타임아웃보다 길게 해놓아야지 중간에 타임아웃되지 않는다.

ELBタイムアウトとは？

ELBは、ロードバランサのサービスとして一般に言うリバースプロキシの機能を持ちます。処理の流れを以下に示します。

1. ELBはクライアントからのリクエストを受信し、EC2インスタンスに転送する
2. EC2インスタンスはELBが転送したリクエストに対応する処理を実行する
3. EC2インスタンスはレスポンスとしてELBに処理の結果を返送する
4. ELBはEC2インスタンスのレスポンスをクライアントに転送する

今回のタイムアウト値は、上記手順の2と3にかかった時間の合計値を指します。デフォルトは60秒で、60秒を経過するとELBはEC2インスタンスのレスポンスを待たずに、エラーとしてクライアントにHTTP 504: Gateway Timeoutを返します。EC2でのリクエストに対する処理がJavaやPHPなどの動的処理で時間がかかったり、EC2の処理性能が足りないというケースで起こりうるトラブルです。→ELB가 인스턴스에 리퀘스트 보낸 후 레스폰스가 올때까지 연결을 끊지 않고 기다려주는 시간

 httpd.confを下記のように編集

 

KeepAlive On
KeepAliveTimeout 120

TCP キープアライブのプローブはペイロードのデータを送信しないため、ロードバランサーが接続を終了する妨げにはならないことに注意してください。

CLOUDFRONT

<div class="mtq_explanation-text"> Amazon CloudFront からの配信設定した場合、ユーザーがウェブページ・コンテンツをリクエストすると、コンテンツ処理に最適なエッジロケーションを決定して配信します。リクエストしたファイルのコピーがエッジロケーションにない場合、Amazon CloudFront はオリジンサーバーからコピーを取得して、将来のリクエストで利用できるようにエッジロケーションに保有します。

エッジロケーションで、CloudFront は要求されたファイルがキャッシュにあるかどうかをチェックし、ファイルがキャッシュにある場合、CloudFront はファイルをユーザーに返しますが、ファイルがキャッシュにない場合は、次のように処理します。

a.CloudFront は、ディストリビューションに指定された内容とリクエストを照合し、ファイルのリクエストを、対応するファイルタイプに応じて該当のオリジンサーバーに転送します。たとえば、イメージファイルの場合は Amazon S3 バケット、HTML ファイルの場合は HTTP サーバーです。 

b.オリジンサーバーは、CloudFront エッジロケーションにファイルを返します。

c.オリジンから最初のバイトが到着した直後に、CloudFront はユーザーへのファイルの転送を開始します。また、CloudFront はキャッシュにファイルを追加し、次にこのファイルがリクエストされた場合に備えます➡오리지날 서버에서 엣지로케이션으로 카피를 진행하면서 진행하는 파일은 파일대로 유저리퀘스트에 응해서 전해주고, 동시에 엣지로케이션에 파일을 저장함.

参考URL:<a href="http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html" target="_blank">CloudFront がコンテンツをユーザーに配信する方法</a></div>

VPC

IPアドレスは、次の5つのアドレスクラスに分かれています。

クラスA 0.0.0.0 - 127.255.255.255

クラスB 128.0.0.0 - 191.255.255.255

10000000.00000000.00000000.00000000

クラスC 192.0.0.0 - 223.255.255.255

11000000.00000000.00000000.00000000

クラスD 224.0.0.0 - 239.255.255.255

11100000.00000000.00000000.00000000

クラスE 240.0.0.0 - 255.255.255.255

RDS

IMPORT/EXPORT

ROUT53/ELB

ELBは、ロードバランサのサービスとして一般に言うリバースプロキシの機能を持ちます。処理の流れを以下に示します。

1. ELBはクライアントからのリクエストを受信し、EC2インスタンスに転送する
2. EC2インスタンスはELBが転送したリクエストに対応する処理を実行する
3. EC2インスタンスはレスポンスとしてELBに処理の結果を返送する
4. ELBはEC2インスタンスのレスポンスをクライアントに転送する

今回のタイムアウト値は、上記手順の2と3にかかった時間の合計値を指します。デフォルトは60秒で、60秒を経過するとELBはEC2インスタンスのレスポンスを待たずに、エラーとしてクライアントにHTTP 504: Gateway Timeoutを返します。EC2でのリクエストに対する処理がJavaやPHPなどの動的処理で時間がかかったり、EC2の処理性能が足りないというケースで起こりうるトラブルです。

ROUT53/ELB

ELB의 경우, 헬스체크를 통과하지 못하는 경우 해당 타겟으로 트레픽을 전달하지 않는다.

route53의 경우, 대상 ip를 쿼리 결과로써 반환하지 않는다.

VPC

VPC とサブネット

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/amazon-vpc-limits.html

ROUT53/ELB

Elastic Load Balancing

ヘルスチェックは、正常とみなすHTTP応答コードは200のみであり、他の200番台やリダイレクト（300番台）は異常とみなされます。（ 200 OK 以外のレスポンスを受信した場合、ヘルスチェックでインスタンスは異常と見なされます。

route 53

ヘルスチェックは、HTTP応答コード200番台と300番台を正常とみなします。リダイレクトされるパスをチェック対象として指定できます。（エンドポイントとの TCP 接続を 4 秒以内に確立できることが必要です。加えて、接続後 2 秒以内に、HTTP ステータスコード 200 以上、400 未満でエンドポイントが応答する必要があります

CLOUDFRONT

Amazon EBS ボリュームのタイプ

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/amazon-vpc-limits.html

EBS

EBS는 기본적으로 하나의 인스턴스에만 어태치가 가능하다!!

S3

RRS는 S3의 저가용성 레포지토리를 의미한다.

EBS

provisioned IOPS 스토리지는 인스턴스에 어태치 하지 않아도(사용하지 않아도), 만든 것만으로 요금이 들어가는 서비스이다. 하지만, I/O자체(provisioned IOPS와 input output을 주고받은 것)만으로는 과금되지 않는다.

RDS

• インスタンスタイプの変更にはインスタンスのリブートが伴う。
• サービス停止時間はインスタンスタイプの変更とリブート時間に依存する。
• サービス停止は最低でも6分程度かかる。

CLOUDFORMATION

Chef:(レシピと呼ばれるRubyのコードで書かれた構築手順書)を実行するとその手順通りに自動構築してデプロイしてくれるサービスです。AWS CloudFormation に比べると、サポート範囲はアプリケーション志向の AWS リソースに限られています。例えば Amazon EC2 インスタンス、Amazon EBS ボリューム、Elastic IP、Amazon CloudWatch メトリックスなどです。

ETC

IAM

• 支払いアカウントの所有者は、単に、一括請求ページからアカウント所有者に要求を送信する必要があります。
• リンクされたアカウントの所有者が要求を受け入れると、リンクされたアカウントは一括請求書の一部になります。
• リンクされたアカウントからプロセスを開始できません

VPC

AMI

EBS ボリュームそのものからデータのコピーを取得し S3 上に保管したものをスナップショットと呼びます。スナップショットには AMI のようなインスタンスを構成するための管理情報は含まれていません。スナップショットの中のデータを利用する場合には、基本的にそのスナップショットを元に EBS ボリュームを作成することになります。<br>

■スナップショット</b>：「EBS ボリュームの中のデータ」を特定のタイミングで取得しS3に保存したもの

■AMI</b>：「EBS ボリュームの中のデータ(スナップショット) とインスタンスを構成する管理情報」を含む起動テンプレート

VPC

ELB

フォールトトレラント設計(Fault tolerant system)

フォールトトレラント設計とは、システム設計の手法で、システムの一部に問題が生じても全体が機能停止するということなく（たとえ機能を縮小しても）動作し続けるようなシステムを設計するもの、とWikipedia先生がおっしゃっています。AWSはまさにフォールトトレラント設計されたサービスではないでしょうか。今回は、AWSの何がフォールトトレラントなのか簡単に確認したいと思います。マジで惚れてまうよ〜

CLOUNDFRONT

cloudfront의 엣지 로케이션중, distribution에서 가격이 높은 곳을 제하면 가격을 낮출 수 있다.

EC2

以前は、効率的かつ低レイテンシーで行うために、EBS暗号化の機能はEC2のM3、C3、R3、CR1、G2、I2インスタンスのみで他のインスタンスタイプには暗号化されたEBSボリュームをアタッチすることはできませんでしたが、現在は汎用T2なども含めて暗号化されたEBSボリュームをアタッチすることができるようになりました。（一部のインスタンスタイプであり、サポートされるインスタンスタイプのみに利用できます。)

<b>Amazon EBS 暗号化 は、参照URLに示すインスタンスタイプで使用できます。</b>これらのインスタンスタイプは、Intel AES New Instructions（AES-NI）命令セットを利用することで、データ保護の高速化と簡素化を実現します。<br>

参考URL：<a href="http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSEncryption.html#EBSEncryption_supported_instances" target="_blank">暗号化をサポートされるインスタンスタイプ</a> </div>

EBS

EC2

EBS

EBSボリューム上に保存されたデータは、EBSの暗号化を有効にした際に、保管時および転送時ともに暗号化することができます。 暗号化されたEBSボリュームを作成し、サポートされるインスタンスタイプにアタッチすると、ボリューム上のデータ、ディスクI/O、ボリュームから作成されたスナップショットの全てが暗号化されます。 暗号化は、EC2インスタンスとEBSストレージ間を移動する際にデータの暗号化を提供します。

参考URL：<a href="http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSEncryption.html" target="_blank">Amazon EBS Encryption</a> </div>

VPC

Network address is first address in the network and it is used for identification network segment. All the IP addresses, using the same network address part, are in the same network segment. Because network address is first address in the network, it can not be random IP address, but it must mach with network mask in a binary view, for last bits in the network address must be zeros, as long as mask has zeros.

Broadcast address is the last address in the network, and it is used for addressing all the nodes in the network at the same time. It means that IP packet, where the destination address is broadcast address, is sent to all nodes of the IP network. It is important for remote announcements in network segment. In some cases it is used for attacking purposes by hackers or can cause problems in bigger network segments.

EBS

AMI

public AMI 설정 (https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/sharingamis-intro.html)

public snapshot설정 (https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html)

EBS dedicated

CLOUDFORMATION

클라우드 포메이션으로 private ip를 지정하는 것은 가능하지만, 기존에 있는 private ip는 삭제해도 곧바로 삭제가 안되기 때문에(결과정합성), 다른 private ip를 사용하여야한다.

ELB

Elastic Load Balancing은 연결된 IP 주소를 사용하여로드 밸런서를 EC2 인스턴스에 등록(콘솔에는 인스턴스를 지정하는 ui 밖에 없지만 내부적으로는 ip로 관계 짓는듯)합니다. EC2-Classic에서 시작된 EC2 인스턴스를 중지 한 후 시작하면 인스턴스에 연결된 IP 주소가 변경됩니다. 로드 밸런서는 새로운 IP 주소를 인식하지 않습니다. EC2-Classic에서 시작한 등록 된 EC2 인스턴스를 중지 한 후 시작하면 중지 된 인스턴스를로드 밸런서로부터 등록 해제하고 다시 시작한 인스턴스를 다시 등록해야합니다. 그렇지 않으면 다시 시작할 인스턴스에 대한 트래픽을로드 밸런서가 라우팅 할 수없는 가능성이 있습니다.

EC2-VPC에서 인스턴스를 시작하면 기본적으로 인스턴스에 연결된 IP 주소는 인스턴스를 중지하고 시작한 후에도 변경되지 않습니다. 그러나 EC2-VPC 인스턴스를 중지하고 시작하면 중지 된 인스턴스가 시작되었음을로드 밸런서가 인식 할 때까지 시간이 걸릴 수 있습니다. 그동안로드 밸런서는 다시 시작한 인스턴스에 연결되어 있지 않습니다. 다시 시작한 인스턴스를로드 밸런서에 다시 가입하는 것이 좋습니다.

ENI

인스턴스는 A와 B의 두 서브넷의 규칙에 따르도록합니다.

Elastic 네트워크 인터페이스 (ENI)은 VPC의 인스턴스에 연결할 수있는 가상 네트워크 인터페이스입니다. ENI는 VPC에서 인스턴스에 어태치하여 사용할 수 있습니다.

각 ENI는 VPC 중 하나의 서브넷 (즉 특정 가용성 존)에 속합니다.

이 새로운 모델에서 중요한 것은, ENI가 있으면 VPC에서 EC2를 시작할 때 특정 VPC서브넷에 둔 것 자체는 지금까지와 비교하면 그다지 의미가 없어진 것입니다. 각 ENI는 각각 특정 서브넷에 속해 있습니다. 각 EC2 인스턴스에 두 ENI를 추가 할 수 있기 때문에 다른 서브넷에 속하는 ENI를 추가 할 수 있습니다. 이는 A라는 서브넷(10.1.10.0/24)에 속한 EC2라도, B서브넷(10.1.11.0/24)의 ENI를 어태치 하면 B서브넷의 인스턴스로써도 기능할 수 있다는 의미가 됩니다.

실행중인 EC2 인스턴스에 ENI를 추가 할 수 있습니다 (핫 첨부라고하자). 종료시 삭제 플래그가 설정되어 있지 않으면 EC2 인스턴스를 종료해도 ENI는 살아 계속합니다. EC2 만들 때 특히 지정하지 않는 한 ENI가 자동으로 생성됩니다. 그리고 기본적으로 종료시 삭제 플래그가 설정되어 있기 때문에 EC2 종료시에는 ENI도 삭제됩니다.

RDS replica

VPC peering

 VPC 피어 연결은 개인 IP 주소를 사용하여 2 개의 VPC 간의 트래픽을 라우팅하는 것을 가능하게하는 네트워크 연결입니다. 두 VPC의 인스턴스도 동일한 네트워크 내에 존재하는 것처럼 서로 통신 할 수 있습니다. VPC 피어 연결은 지역 내 또는 지역 사이입니다. 지역 간의 VPC 피어링 연결을 만들 수 지역은 미국 동부 (버지니아 북부) 미국 서부 (오레곤), 유럽 (아일랜드) 및 미국 동부 (오하이오), 유럽 (런던), 유럽 (파리), 아시아 태평양 ( 뭄바이), 아시아 태평양 (시드니), 아시아 태평양 (싱가포르) 아시아 태평양 (도쿄), 캐나다 (중부), 남미 (상파울루) 등이 있습니다. 또 다른 AWS 계정에있는 VPC 사이에 만들 수 있습니다.

1 : autoscaling에서 ec2를 종료하는 기능은 있어도 정지하는 기능은 없다.

3 : RDS의 autoscaling은 지원하지 않는다.

5 : 인스턴스의 스케일 아웃/인 기능은 지원하지만, 스케일 업/다운 기능은 지원하지 않는다.

ELB

ELB는 기본적으로 복수의 az에 걸쳐 작성하면 각 AZ에 존재하는 인스턴스의 수에 관계없이 트레픽을 균등하게 흘려보낸다. 본문제와 같은 경우 AZ내의 인스턴스 수가 균등하지 않으면 트레픽은 균등히 배분되므로 부하분산이 균등히 되지 않고, 가장 수가 적은 AZ의 인스턴스가 가장 높은 부하를 받게 된다. 해결책으로는 로드벨러스의 클로즈존 부하분산을 설정하여 AZ에 걸쳐 전 인스턴스에 균등히 트레픽을 분산하는 방법이다. 클로즈존 부하분산을 유효시의 로드벨런스 노드와 백엔드 인스턴스 간의 데이터 전송에 대해서는 과금되지 않는다.

http://docs.aws.amazon.com/ja_jp/ElasticLoadBalancing/latest/DeveloperGuide/enable-disable-crosszone-lb.html

AUTO SCALING

なぜクールダウンが必要か？

• 例えば、新しいインスタンスが起動して処理を開始するまでに2分かかるとする。
• CPUが80%を超えたため新しいインスタンスが追加される
• しかしクールダウンがない場合、インスタンス追加後2分は処理が開始できないためCPUが80%を超えた状態が2分以上続く
• 80%を超えているためインスタンスがさらに追加される
• ここでクールダウンを3分とすると、スケール後3分はスケールしない時間となる
• 3分後にCPUが80%以下だとスケールしない。依然80%だったらスケールする

IAM

사용되는 자격 증명의 종류는 액세스 키 및 API 호출에 대한 Multi-Factor Authentication (MFA)입니다. 각각의 의미는 다음과 같습니다. 

■ 키(해본적 있어서 기억남)

키는 AWS 서비스 API 호출에 대한 디지털 서명에 사용됩니다. 키 인증 정보는 액세스 키 ID와 키로 구성됩니다. 비밀 키 부분은 AWS 계정 소유자 또는 AWS 계정에 할당 된 IAM 사용자가 안전하게 관리해야합니다. 사용자는 활성 키 세트를 동시에 2 개까지 소유 할 수 있습니다. 모범 사례로 키는 정기적으로 업데이트하는 것이 좋습니다. 

■ API 호출에 대한 MFA

Multi-Factor Authentication (MFA)로 보호 된 API에 액세스하는 경우 IAM 사용자는 API의 특정 기능을 사용하기 전에 유효한 MFA 코드를 입력해야합니다. 어떤 API에서 MFA가 요구 될까는 IAM에서 만든 정책에 따라 결정됩니다. AWS 서비스 API 호출은 AWS 관리 콘솔에서 이루어 지므로 콘솔과 API 모두에서 액세스되는지에 따라 API를 MFA를 적용 할 수 있습니다.

*로그인할때 필요한건 유저아이디/패스워드, MFA

*실제 베스트 플렉티스는 API를 사용하고자 하는 리소스에 IAM ROLE을 부여하는 것이다.

CLOUDWATCH

S3

*S3의 리소스 변경에도 MFA를 적용할 수 있다.

CloudTrail

AWS CloudTrail을 통해 aws내의 리소스에서 발생한 이벤트들을 확인할 수는 있지만, 인스턴스내에 엑세스로그나 ip트래픽 로그를 제공하지는 않는다.

RDS  

DB의 태그는 겹쳐도 덮어써진다 ;

EBS

CLOUDFORMATION

S3

IAM EBS

예약 인스턴스는 1 년 또는 3 년의 인스턴스 확보 요금을 선불하여 저렴한 인스턴스를 사용할 수있는 서비스입니다. 예약 인스턴스 구매시에는 명목상에서 구입 한 계정에 청구됩니다 만, 이용시 모든 계정에 적용 할 수 있습니다. 

예를 들어, B1 및 B2라는 계정이 있습니다. B1의 멤버 어카운트로 B2 있습니다. B1은 6 인스턴스 사용하고, B2는 3 인스턴스 사용하고 있습니다. 여기서, B2는 5 개의 예약 인스턴스를 구입했습니다. 이제 어떻게 될 것인가. 중요한 포인트는 예약 인스턴스는 일괄 청구 계정에 적용되는 것입니다. 따라서 총 9 인스턴스 중 5 인스턴스가 리저브 드 인스턴스에서 4 인스턴스가 보통의 것입니다.

ELB

EBS

 Amazon Elastic Block Store (Amazon EBS)는 EC2 인스턴스에서 사용하는 블록 레벨 스토리지 볼륨을 제공합니다. EBS 볼륨은 특정 단일 가용성 영역에서 생성되고 그 가용성 존의 인스턴스에 연결할 수 있습니다. EBS 볼륨은 단일 가용성 영역에 저장되기 때문에 가용성 영역의 장애에 견딜 수 없습니다. 

가용성 영역의 장애에 견딜 위해 스냅 샷을 작성하고 스냅 샷을 다른 지역에 복사 한 후 그 지역의 새 볼륨에 복원합니다. 지리적 확대 및 데이터 센터 마이그레이션, 재해 복구 등 여러 AWS 지역을보다 쉽게 활용할 수 있습니다.

IAM

IAM

EBS AMI

RDS

IAM

SQS

VPC

서브넷의 크기에 대한 문제입니다. 

동일 지역 내이면, AZ를 넘고 서브넷을 구성 할 수 있으며, VPC 내의 서브넷의 CIDR 블록은 / 28 넷 마스크에서 / 16 넷 마스크 사이의 블록 크기입니다. 즉, VPC는 ​​16 ~ 65,536 개의 IP 주소를 포함 할 수 있습니다. 이번 질문은 CIDR 블록이 / 28이되므로 16 개의 IP 주소 공간되지만 네트워크 주소와 브로드 캐스트 주소에 2 개의 IP 주소 외에 AWS에서 예약 된 3 개의 IP 주소를 제외한 총 5 개의 IP 주소를 뺀 11 개의 사설 IP 주소를 사용 할 수 있습니다. 

각 서브넷 CIDR 블록의 첫 번째 4 개의 IP 주소와 마지막 IP 주소는 사용할 수 없으며 인스턴스에 할당 할 수 없습니다. 예를 들어, CIDR 블록 10.0.0.0/28 인 서브넷의 경우 다음의 5 개의 IP 주소가 예약됩니다. 

10.0.0.0 네트워크 주소입니다. 

10.0.0.1 : VPC 라우터에 AWS에서 예약되어 있습니다. 

10.0.0.2 : Amazon이 제공하는 DNS에 매핑 용 AWS에서 예약되어 있습니다. 

10.0.0.3 : 향후 사용을 위해 AWS로 예약되어 있습니다. 

10.0.0.15 : 브로드 캐스트 주소입니다. VPC는 브로드 캐스트가 지원되지 않기 때문에이 주소를 예약합니다. 

참고 URL : https://aws.amazon.com/jp/vpc/faqs/#IP_Addressing

구내 동등한 감각으로 작은 시작에서 서브넷을 꺼 버리면 인스턴스 외에 ELB의 대수가 증가하면 ELB에서 사용하는 VPC의 사설 IP 주소를 소비하여 사설 IP 주소가 고갈합니다. 나중에 서브넷의 크기 조정은 귀찮아서 서브넷은 약간 큰 설계하는 것이 좋을 것 같습니다.

->요약 : 첫 번째 4 개의 IP 주소와 마지막 IP 주소는 사용할 수 없으며, 서브넷을 설정하는 ELB나 NAT도 프라이벳 아이피를 소비한다.

RDS

KINESIS

스트림 서비스를 하기위해서는 kinesis다.

RDS

RDS마스터 유저란 rds 접속할때 root/admin 말하는거다. RDS 생성할때 root 유저(마스터유저) 설정한다.

EBS

 EC2 인스턴스가 기동되어 있는 상태에도 스냅샷을 취득할 수 있지만, 스냅 샷 취득시에 볼륨에있는 모든 파일의 기록을 중지 할 수 있어야 완전한 스냅 샷을 얻을 수 있기 때문에 디스크 I / O를 정지시키고, EBS 볼륨의 스냅 샷을 시작합니다. 스냅샷 취득을 시작하면 스냅 샷의상태는 "pending"이지만, 인스턴스의 볼륨은 읽고 쓰기 가능하기 때문에 즉시 디스크 I / O를 재개시킴으로써 다운 타임을 최소화합니다. 

다음은 해설입니다. 

· 1.EBS 볼륨의 분리, 2.EBS 볼륨의 스냅 샷 시작 3.EBS 볼륨 다시 연결

→ EBS 볼륨의 분리, 재 부착함으로써 읽기 및 쓰기 중단의 장기화를 초래하므로 실수입니다. EBS볼륨을 분리하지 않고 장착된 상태에서도 스냅샷을 찍을 수 있습니다.

· 1.EC2 인스턴스의 정지, 2.EBS 볼륨의 스냅 샷

→ 루트 장치로 기능하는 Amazon EBS 볼륨의 스냅 샷을 만들려면 스냅 샷을 복용하기 전에 인스턴스를 중지해야하지만, 루트 장치로 사용하는 문제 문장에 기재가 없기 때문에 EC2 인스턴스를 중지하는 것은 중단의 장기화를 초래하므로 실수입니다.

· 1. 디스크 I / O를 중지하고 2.EC2 인스턴스의 이미지 만들기 3. 디스크 I / O의 재개

→ EC2 인스턴스의 이미지(AMI)를 만들어도, EBS 볼륨의 백업되지 않기 때문에 실수입니다

· 1. 디스크 I / O를 중지하고 2.EBS 볼륨의 스냅 샷의 시작 3. 스냅 샷 완료 확인 4. 디스크 I / O의 재개

→ 스냅 샷 완료 확인을 기다리고있어 다운 타임의 장기화를 초래합니다. 스냅 샷 완료 확인을하지 않아도 볼륨은 바로 사용할 수 있기 때문에 실수입니다.

■ 참고 

사용중인 연결 된 볼륨의 스냅 샷을 취할 수 있습니다. 그러나 스냅 샷은 스냅 샷 명령을 ​​실행 한 시점에서 Amazon EBS 볼륨에 기록 된 데이터 만 캡처됩니다. 따라서 응용 프로그램이나 운영 체제에 따라 캐시 된 데이터는 제외 될 수 있습니다. 스냅 샷 동안 볼륨에있는 모든 파일의 기록을 중지 할 수 있어야 완전한 스냅 샷을 취할 수 있습니다. 그러나 볼륨에있는 모든 파일의 기록을 중지 할 수없는 경우에는 일관된 완전한 스냅 샷을 취할 수 있도록 인스턴스 내에서 볼륨을 마운트 해제하고 스냅 샷 명령을 ​​실행하여 볼륨을 다시 마운트 합니다. 스냅 샷의 상태가 pending 동안 볼륨을 다시 마운트하여 사용할 수 있습니다. <br>

루트 장치로 기능하는 Amazon EBS 볼륨의 스냅 샷을 만들려면 스냅 샷을 복용하기 전에 인스턴스를 중지합니다. 

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html

IAM

C2 인스턴스에 IAM 역할을 할당 지식을 묻는 문제입니다. IAM 역할을 EC2 인스턴스에 적용하려면 

1 .EC2 인스턴스 생성시에 적용하는 방법과 

2. 실행중인 인스턴스에 할당하는 방법의 두 가지가 있습니다. 

또 하나의 EC2 인스턴스에 동시에 연결할 수있는 하나의 IAM 역할 만하게 1 롤의 제한은 완화 할 수 없습니다. 

부하 분산 장치의 액세스 로그를 사용하여 수행 할 수 있습니다.

Elastic Load Balancing은로드 밸런서에 전송되는 모든 요청에 ​​대해 자세한 정보를 수집하는 액세스 로그를 제공합니다. 각 로그는 요청을받은 시간, 클라이언트의 IP 주소, 지연 요청의 경로 서버 응답 등의 정보가 포함됩니다. 이러한 액세스 로그를 사용하여 트래픽 패턴 분석과 문제 해결을 할 수 있습니다. 액세스 로그 작성은 Elastic Load Balancing 옵션 기능이며, 기본적으로 비활성화되어 있습니다. 로드 밸런서의 로그에 액세스 할 수 있도록하면 Elastic Load Balancing 로그를 캡처하여 지정한 Amazon S3 버킷에 저장합니다. 액세스 로그 작성은 언제든지 해제 할 수 있습니다.

다음은 실수입니다. 

로드 밸런서를 위해 AWS CloudTrail을 활성화합니다.

→ CloudTrail은 AWS API 호출이 기록되기 때문에 예를 들어, 특정 사용자가 특정 기간에 수행 한 작업 특정 자원에 대해 특정 기간 동안 작업을 수행 한 사용자 특정 활동의 소스 IP 주소 부적절한 권한 때문에 실패하는 활동 등을 알 수있게됩니다. 로드 밸런서 자체의 조작은 기록되지만 내부에 흐르는 요청에 대한 로그가 수집되지 않기 때문에 실수입니다. <br>

-> CloudTrail은 aws 리소스에 관해  사용자의 정보와 사용한 리소스에 대한 정보만 알려주지 리소스 내의 구체적인 정보를 알려주지는 않는다.

로드 밸런서에 Amazon CloudWatch 로그 에이전트를 설치합니다 

→ CloudWatch 로그 에이전트가 지원되는 것은 Amazon Linux, Ubuntu, CentOS, Red Hat Enterprise Linux, Windows되므로 오류입니다. 또한 에이전트를 설치하면 호스트의 개별 로그 파일을 모니터링 할 수 있습니다.

로드 밸런서에 Amazon CloudWatch 메트릭을 사용합니다.

→ Amazon CloudWatch는 액세스 로그를 수집 할 수 없기 때문에 실수입니다.

おはようございます､加藤です｡WWDC 2018でiPhone SE2が来るかと期待していましたが､見事に夢破れました｡

VPCピアリングを使用する機会があったので､構築しながら勉強してみました｡

概要

できること

異なるVPCを接続

当然ですね､VPCピアリングによって異なるVPCを接続することができます｡VPC間で直接接続する為､インスタンスにパブリックIPアドレスが割り当てらている必要はありません｡

また､IPv6アドレスでも利用することが可能です｡

異なるAWSアカウントのVPCを接続

VPCピアリングはAWSアカウントに依存しません｡異なるアカウント間でVPCピアリングを利用することができます｡

異なるリージョンのVPCを接続

VPCピアリングはリージョンに依存しません｡異なるリージョン間でVPCピアリングを利用することができます｡

ただし､IPv6アドレスは非対応です｡

複数のVPCとピアリング

VPCピアリングは1:Nの接続をサポートしています｡デフォルトの制限値は50で上限緩和リクエストによって最大125まで緩和できます｡

ただし､ネットワークパフォーマンスに影響がでる場合があります｡また､合わせてルートテーブルの上限緩和が必要になる可能性があります｡大規模なピアリングを行う場合は､しっかりと計画しましょう｡

できないこと

CIDRブロックが一致・重複するVPC間のピアリング

CIDRブロックが一致または重複する VPC 間で VPC ピアリング接続を作成することはできません。

重複していないCIDR ブロック間の通信にのみが必要であったとしても､いずれかのCIDR ブロックが重複している場合は、VPC ピアリング接続を作成することはできません。

ピアリング先のVPCを経由する通信

オンプレチックな考え方だとできそうと思ってしまいますが､NGです｡具体的な例を上げていきます｡

ピアリング先のVPCがピアリングしているVPCに直接通信することはできません｡

ピアリング先のVPCが接続しているVPN/DXを経由してオンプレミスと直接通信することはできません｡

ピアリング先のVPCのインターネットゲートウェイ/NATデバイスを経由してインターネットに直接通信することはできません｡

ピアリング先のVPCエンドポイントを経由してAWSリソースに直接通信することはできません｡

やってみた

以下の条件でVPCピアリングを試してみました｡

• 同一アカウント
• 異なるリージョン
  • ap-northeast-1, ap-southeast-1
• EC2(VPC A) →SSH→ EC2(VPC 2)

VPC,EC2

本筋では無いのでTerraformで構築しました｡コードはGithubで公開しています｡

雑い & 英語が変かもしれませんが生暖かい目で御覧ください＼(^o^)／

Terraformについてはこちらのブログをどうぞ

VPCピアリング

AWSマネジメントコンソールでピアリング接続の画面を開き､｢ピアリング接続の作成｣をクリックします｡

フォームに値を入力します｡

これで接続先にVPCピアリングのリクエストが飛びます｡

リージョンをシンガポールに切り替えて承認を行います｡

ルートテーブル

VPC間は接続されましたが､ルートテーブルを定義しないと通信ができません｡

それぞれのVPCのルートテーブルにルートを追加します｡

VPC A

VPC B

セキュリティグループ

VPC AのEC2からVPC BのEC2に対してSSHを許可します｡

VPCピアリングが接続されていますが､送信元/送信先にセキュリティグループを指定することが可能です｡

ただし､別リージョンの場合はできません｡つまり､今回はCIDRブロックで指定する必要があります｡

VPC B側のセキュリティグループに受信設定を追加します｡

動作確認

EC2 AにSSH接続

EC2 A経由でEC2 BにSSH接続

SSH Configを作成

EC2それぞれのパブリックIPアドレスが表示されれば成功です

 あとがき

できないことについても作って検証したかったですが､そこそこの長さになってしまったので一旦切り上げました｡今後､Terraformをアップデートして引き続き勉強&ブログにしようと思います｡

VPCピアリングしている際にVPCをまたいで､セキュリティグループの送信元にセキュリティグループを指定できるという知識はあったのですがリージョンをまたぐとできないという事が抜けていました｡構築している際に､少しハマってしまいました...

引用元

출처: http://bluese05.tistory.com/52 [ㅍㅍㅋㄷ]

EC2 における Public IP と Elastic IPの違いに関して

EC2は外部（主にインターネット上)と通信する場合、外部アドレスが必要となります。例えばEC2をSSHサーバとして構築する場合、インターネット上の SSH クライアントはこのIPアドレスに向けてアクセスします。(ただし ELB やProxy経由でアクセスする場合はその限りではありません。)この場合、使用するIPアドレスは2通りあります。この違いに関して説明します。

比較は以下の表の通りとなります。

参考まで、パブリックサブネット上のEC2サーバは ifconfig や ipconfig で自分のアドレスを知ることはできません。なぜなら SDN (Software-Defined Network) により仮想的なネットワーク上で稼働しているためです。そのため、自分の IP アドレスを知るには meta 情報を使用します。

https://opentutorials.org/course/608/3005

EBS란?

EBS란 Elastic Block Store의 약자로 일종의 하드디스크라고 생각하면 된다. EBS의 특징은 아래와 같다.

• 필요한 용량에 맞게 구입 할 수 있다. 이를테면 EC2 인스턴스를 웹서버의 용도로만 쓰고 파일 저장은 S3를 사용한다면 넉넉 잡고 1기가바이트만 구입하면 된다.
• 필요에 따라서 즉시 생성하고, 제거 할 수 있다.
• 사용한 만큼 과금 되는 종량제다. 자세한 내용은 설명서의 비용예측을 참고한다.
• 내부적으로 데이터를 실시간 복제하고 있기 때문에 하드디스크에 비해서 데이터를 잃어버릴 확률이 현저히 낮다.
• 스냅샷 기능을 제공해서 EBS의 현재 상태 그대로 보존 할 수 있다.
• CloudWatch를 통해서 EBS의 통계를 열람 할 수 있다.
• EC2 인스턴스를 제거해도 EBS는 독립적이기 때문에 데이터가 유지 된다.

Volume이란?

EBS로 생성한 (말하자면) 디스크 하나 하나를 볼륨이라고 부른다.

EBS 생성

EBS를 생성하고 이것은 인스턴스에 붙이는 방법에 대해서 알아보자.

사이드 바에서 ELASTIC BLOCK STORE 하위의 Volumes를 선택한다.

상단의 Create Volume를 클릭한다.

EBS 설정화면에 설정 값을 입력한다.

• Size : EBS의 용량
• Availability Zone : AZ에 대한 설명을 참고한다.
• Snapshot : EBS는 현재 저장된 데이터 상태 그대로 보관할 수 있는데, 이를 스냅샷이라고 한다. 미리 만들어진 스냅샷을 선택해서 똑같은 데이터가 저장된 상태로 EBS를 새로 만들 수 있다.
• Volume Type : IOPS는 디스크에 데이터를 읽고 쓰는 속도를 의미한다. IOPS를 선택하면 EBS의 읽기/쓰기 속도를 선택할 수 있고, 표준(standard)를 선택하면 IOPS의 값이 100으로 기본설정된다. (통상 7500rpm 속도의 하드디스크의 IOPS를 75~100 정도로 잡는다)

EC2 인스턴스에 EBS 붙이기

생성한 EBS를 EC2 인스턴스에 붙이기 위해서는 EBS 볼륨에 마우스 커서를 올려놓고 오른쪽 클릭을 한다. 이때 볼륨의 상태(State)가 Avaliable인 것만 EBS 인스턴스에 붙일 수 있다. in-use는 이미 사용중이라는 의미다. 또 볼륨과 인스턴스는 같은 가용성 존에 위치하고 있어야 한다. 아래는 Attach Volume를 선택한 결과다.

• Instances :  볼륨을 붙이려는 인스턴스를 지정한다.
• Devices : 마운트 하려는 장치의 이름을 지정한다. 마운트에 대한 자세한 설명은 생활코딩 리눅스 수업을 참고 한다. 마운트하는 장치의 이름은 리눅스의 버전에 따라서 달라질 수 있다. 구체적으로 마운트 하는 방법은 뒤에서 살펴본다.
• Yes, Attach를 누르면 ECS 인스턴스에 EBS 볼륨이 장착된다.

EC2 인스턴스에서 EBS 인식하기

콘솔의 사이드 바에서 인스턴스를 선택해서 인스턴스 리스트 화면으로 이동한다. EBS를 붙인 인스턴스를 선택하면 인스턴스에 대한 디테일에 방금 추가한 볼륨의 이름이 아래와 같이 있는지 확인한다.

터미널을 이용해서 인스턴스에 접속한다. 인스턴스에 접근하는 방법은 이전 수업 '인스턴스 생성'을 참고 한다.

터미널에서 아래와 같이 입력한다. sdf는 위에서 확인한 Block Devices의 이름으로 변경해야 한다.

주의 : 아래의 명령은 볼륨의 데이터를 삭제한다. 인스턴스를 최초로 추가할 때만 실행한다.

1	sudo mkfs.ext4 /dev/sdf

아래와 같은 결과가 출력된다면 리눅스 커널에서 디바이스의 이름을 xvdf~xvdp로 변경했기 때문일 수 있다. 이런 경우 이름을 직접 찾아야 한다.

아래와 같이 명령을 입력한다.

1

df;

필자의 인스턴스는 위와 같이 출력된다. 붉은 색으로 강조한 표시는 /dev/xvda1이 이미 사용중이라는 뜻이다. 그럼 xvd로 시작하는 디바이스 중에 최근에 추가된 것이 우리가 찾고 있는 디바이스라고 추론 할 수 있을 것이다. 아래와 같이 입력한다.

1	ls -al /dev/xvd*

추가 된 디바이스의 이름이 /dev/xvdf 라는 것을 알아냈다. 이제 포멧을 다시 시도해보자.

주의 : 아래의 명령은 볼륨의 데이터를 삭제한다. 인스턴스를 최초로 추가할 때만 실행한다.

1	sudo mkfs.ext4 /dev/xvdf

마운트한 볼륨을 추가할 디렉토리를 생성한다. files라는 이름을 사용하고 싶다면 아래와 같이 한다.

1	sudo mkdir /files;

/files 디렉토리에 볼륨을 마운트하자.

1	sudo mount /dev/xvdf /files;

df 명령을 입력해서 아래와 같이 디바이스가 추가된 것을 확인한다.

EC2 인스턴스에서 EBS 볼륨 떼어내기

장치를 제거한다. (마운트를 해제한다) 

 

1	sudo umount /dev/xvdf;

EBS 볼륨 목록에서 해당 볼륨을 선택하고 Detach Volume를 선택한다. 

이 과정을 반복하면 EBS 볼륨을 다른 EC2 인스턴스에 붙일 수 있다. 

既存EC2インスタンスにEBSボリュームを追加（アタッチ）する

AWSEC2ebs

この記事は最終更新日から1年以上が経過しています。

概要

既に構築済みのEC2インスタンスに新しくEBSボリュームを追加してEC2で使用できるようにします。

EBSとは

Elastic Block Storeの略
EC2への仮想外付けストレージサービス
・サイズは1GB単位で～1TBまで
・サイズ/期間/IOで課金される

詳しくは下記を参照してください
[AWSマイスターシリーズ] Elastic Block Store(EBS)

作業イメージ図

作業手順

EBSボリュームを作成する

1.AWS ManagementConsoleの「Services」から「EC2」を選択します。

2.左側のナビゲーションから「ELASTIC BLOCK STORE」の「Volumes」を開いて「Create Volumes」をクリックして作成ダイアログを開きます。

3.必要な項目を入力して、「Create」をクリックしてEBSを作成する

項目名	説明
VolumeType	通常は「standard」を選択。I/O性能を設定したい場合は「Provisioned IOPS」を選択。
Size	ボリュームサイズ（ストレージサイズ）を入力します。
IOPS	「Provisioned IOPS」を選択した場合のI/O性能を設定します。
Availability Zone	EBSを作成するゾーンを設定します。注意：ゾーンは追加したいEC2インスタンスと同じゾーンを指定しましょう
Snapshot	EBS作成時に元になるSnapshotを指定する場合に使用します。Snapshotの内容を使いたいけど、Snapshotとは異なるボリュームサイズにしたい時等に使用します。

4.作成したEBSが一覧に追加され、「State」が「available」になったらEBS作成完了です。

既存のEC2に作成したEBSを追加する

1.EBS一覧から追加したいEBSにチェックを入れて、「Actions」メニューまたは右クリックメニューで「Attach Volume」を選択します

2.必要な項目を入力して、「Attach」をクリックしてEC2にEBSを追加します。

項目名	説明
VolumeType	選択したEBSボリューム
Instance	EBSを追加したいEC2インスタンスを指定する。追加可能なEC2リストから選択するだけです。
Device	EC2内でのデバイス名を指定します。通常はInstanceを選択した時点で最適なデバイス名が自動で設定されます。手動で設定ももちろん可能です。

3.EBS一覧で正常に追加できたか確認する。

EBSボリュームをEC2にマウントする

追加したEBSをEC2で使用できるようにマウントします。

1.EC2へSSH接続する。

操作するEC2のOSはUbuntuですが、基本的にAmazon Linuxでも同様の操作になります。
ubuntuだと/dev/sdgは/dev/xvdgになっている。


2.現在のマウント状態を確認する（/dev/sdgはまだマウントされていない）

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       20G  8.0G   11G  43% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            816M  8.0K  816M   1% /dev
tmpfs           166M  200K  166M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            827M     0  827M   0% /run/shm
none            100M     0  100M   0% /run/user
/dev/xvdf        20G  2.0G   17G  11% /data

3.EBSボリュームをフォーマットし、/data2にマウントします。

$ sudo su -

# mkfs -t ext4 /dev/xvdg
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
・
・
・
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

# mkdir /data2
# mount /dev/xvdg /data2
# exit

4.正常にマウントできているか確認する

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       20G  8.0G   11G  43% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            816M  8.0K  816M   1% /dev
tmpfs           166M  200K  166M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            827M     0  827M   0% /run/shm
none            100M     0  100M   0% /run/user
/dev/xvdf        20G  2.0G   17G  11% /data
/dev/xvdg        99G   60M   94G   1% /data2

5.書き込みが正常にできるか確認する

# mkdir -p /data2/test/file/to/ 
# echo "this is text file" > /data2/test/file/to/test.txt
# cat /data2/test/file/to/test.txt
this is text file

自動マウントを設定する

このままだとEC2インスタンスをSTOP等をした際に、マウントが外れてしまうので、自動マウントするように設定しておく。
意外と忘れがち。
以下を/etc/fstabの末尾に追加する。

1.自動マウントの設定をする

/dev/xvdg /data2 ext4 defaults 1 1

2.（可能なら）自動マウントできているか確認する
EC2をAWS ConsoleからStop -> Startをして自動マウントできているか確認する

編集リクエスト

Amazon EC2 インスタンスからの AMI の作成

[Amazon EC2 Instances] ビューで、実行中または停止したインスタンスのいずれかを使用して、Amazon Machine Image (AMI) を作成することができます。

インスタンスから AMI を作成するには

AMI が作成されるまでには数分かかる場合があります。作成されると、AWS Explorer の [AMIs] ビューに表示されます。このビューを表示するには、AWS Explorer の [Amazon EC2 | AMIs] ノードをダブルクリックします。AMI を表示するには、[Viewing] ドロップダウンリストから [Owned By Me] を選択します。AMI を表示するには、[Refresh] を選択する必要がある場合があります。最初に AMI が表示されたときは、保留状態であることがありますが、しばらくすると、利用可能な状態になります。

作成された AMI のリスト