RDS
Amazon RDS では、お客様の DB インスタンスの自動バックアップはデフォルトで Amazon S3 に作成され、指定した期間安全に保存されます。さらに、スナップショットを作成することも可能です。スナップショットはユーザー起動型のインスタンスバックアップで、明示的に削除するまで保持されます。
ご希望の際にいつでも、データベーススナップショットから新しいインスタンスを作成できます。データベーススナップショットはフルバックアップとして動作しますが、ストレージ使用の増加分に対してのみ課金されます。
デフォルトで有効になっている Amazon RDS の自動バックアップ機能により、データベースとトランザクションログがバックアップされます。Amazon RDS では DB インスタンスのストレージボリュームのスナップショットを自動的に作成し、個々のデータベースだけではなく、その DB インスタンス全体をバックアップします。
このバックアップは、バックアップウィンドウと呼ばれるユーザーが設定可能な 30 分間隔の時間に 1 日 1 回行われます。自動バックアップは、お客様が設定した日数の間、保持されます（バックアップ保持期間と呼ばれます）。自動バックアップの保持期間は、最大 35 日間までに設定できます。
この保持期間中の任意の時点に DB インスタンスを復元して、新しい DB インスタンスを作成できます。DB インスタンスを復元するには、AWS コンソールまたはコマンドラインインターフェイスを使用します。
DB インスタンスの復元可能な直近の時間を調べるには、AWS コンソールまたはコマンドラインインターフェイスを使用し、DB インスタンスの [LatestRestorableTime] フィールドに返される値を参照します。DB インスタンスの復元可能な直近の時間は、通常、現在時刻の 5 分以内です。
データベースのスナップショットはお客様が開始して 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입니다.(볼륨이 펜딩인게 아니라 스냅샷이 팬딩이므로 볼륨의 사용에는 영향을 받지않음) 따라서 크기가 큰 최초의 스냅샷이나 변경된 블록이 많은 후속 스냅샷의 경우 몇 시간씩 시간이 걸릴 수 있습니다. 완료하는 동안 진행 중인 스냅샷은 볼륨에 대한 지속적인 읽기 및 쓰기의 영향을 받지 않습니다.
중요
볼륨의 이전 스냅샷이 pending 상태일 때에도 볼륨의 스냅샷을 생성할 수는 있지만 볼륨의 pending 스냅샷을 여러 개 생성하면 스냅샷이 완료될 때까지 볼륨 성능이 저하될 수 있습니다.
단일 gp2, io1 또는 Magnetic 볼륨에 대해 다섯 개의 pending 스냅샷, 단일 st1 또는 sc1볼륨에 대해 한 개의 pending 스냅샷으로 제한됩니다. 동일 볼륨에 대해 여러 개의 동실 스냅샷을 생성하려 할 때 ConcurrentSnapshotLimitExceeded 오류가 표시되면 한 개 이상의 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 はそれらを認識しなくなります。また、その認証情報によって作成された API リクエストによるあらゆるタイプのアクセスが許可されなくなります。
一時的セキュリティ認証情報はユーザーとともに保存されることはなく、ユーザーのリクエストに応じて動的に生成され、提供されます。一時的セキュリティ認証情報が失効すると（または失効する前でも）、ユーザーは新しい認証情報をリクエストできます。ただし、リクエストするユーザーがまだその権限を持っている場合に限ります。
【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は、ロードバランサのサービスとして一般に言うリバースプロキシの機能を持ちます。処理の流れを以下に示します。
- ELBはクライアントからのリクエストを受信し、EC2インスタンスに転送する
- EC2インスタンスはELBが転送したリクエストに対応する処理を実行する
- EC2インスタンスはレスポンスとしてELBに処理の結果を返送する
- 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は、ロードバランサのサービスとして一般に言うリバースプロキシの機能を持ちます。処理の流れを以下に示します。
- ELBはクライアントからのリクエストを受信し、EC2インスタンスに転送する
- EC2インスタンスはELBが転送したリクエストに対応する処理を実行する
- EC2インスタンスはレスポンスとしてELBに処理の結果を返送する
- ELBはEC2インスタンスのレスポンスをクライアントに転送する
今回のタイムアウト値は、上記手順の2と3にかかった時間の合計値を指します。デフォルトは60秒で、60秒を経過するとELBはEC2インスタンスのレスポンスを待たずに、エラーとしてクライアントにHTTP 504: Gateway Timeoutを返します。EC2でのリクエストに対する処理がJavaやPHPなどの動的処理で時間がかかったり、EC2の処理性能が足りないというケースで起こりうるトラブルです。
ROUT53/ELB
ELB의 경우, 헬스체크를 통과하지 못하는 경우 해당 타겟으로 트레픽을 전달하지 않는다.
route53의 경우, 대상 ip를 쿼리 결과로써 반환하지 않는다.
VPC
VPC とサブネット
| リソース | デフォルトの制限 | コメント |
|---|---|---|
リージョン当たりの VPC の数 | 5 | リージョンあたりのインターネットゲートウェイの制限は、これと直接的な相関があります。この制限を増やすと、リージョンあたりのインターネットゲートウェイの制限が同じ数だけ増加します。 リージョンでの VPC の数および VPC あたりのセキュリティグループの数の倍数が 10000 を超えることはできません。 |
VPC 当たりのサブネットの数 | 200 | - |
| VPC 当たりの IPv4 CIDR ブロック | 5 | この制限は、プライマリ CIDR ブロックと 4 つのセカンダリ CIDR ブロックで構成されます。 |
VPC 当たりの IPv6 CIDR ブロック | 1 | この制限を増やすことはできません。 |
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 ボリュームのタイプ
次の表に、現行世代の EBS ボリュームのユースケースとパフォーマンス特性を示します。
| ソリッドステートドライブ (SSD) | ハードディスクドライブ (HDD) | |||
|---|---|---|---|---|
| ボリュームタイプ | EBS プロビジョンド IOPS SSD (io1) | EBS 汎用 SSD (gp2)* | スループット最適化 HDD (st1) | Cold HDD (sc1) |
短い説明 | レイテンシーの影響が大きいトランザクションワークロード向けに設計された極めてパフォーマンスの高い SSD ボリューム | 幅広いトランザクションワークロードに対応できる価格とパフォーマンスのバランスが取れた汎用 SSD ボリューム | 高いスループットを必要とするアクセス頻度の高いワークロード向けの低コストの HDD ボリューム | アクセス頻度の低いワークロード向けに設計された極めて低コストの HDD ボリューム |
ユースケース | I/O 負荷の高い NoSQL データベースとリレーショナルデータベース | ブートボリューム、インタラクティブで低レイテンシーのアプリケーション、開発およびテスト環境 | ビッグデータ、データウェアハウス、ログ処理 | 1 日のスキャン必要回数が少ないコールドデータ |
API 名 | io1 | gp2 | st1 | sc1 |
ボリュームサイズ | 4 GB～16 TB | 1 GB～16 TB | 500 GB～16 TB | 500 GB～16 TB |
最大 IOPS**/ボリューム | 64,000 | 10,000 | 500 | 250 |
最大スループット***/ボリューム | 1,000 MB/秒 | 160 MB/秒 | 500 MB/秒 | 250 MB/秒 |
最大 IOPS/インスタンス | 80,000 | 80,000 | 80,000 | 80,000 |
最大スループット/インスタンス | 1,750 MB/秒 | 1,750 MB/秒 | 1,750 MB/秒 | 1,750 MB/秒 |
料金 | 0.125 USD/GB – 月 0.065 USD/プロビジョンド IOPS | 0.10 USD/GB – 月 | 0.045 USD/GB – 月 | 0.025 USD/GB – 月 |
主なパフォーマンス属性 | IOPS | IOPS | MB/秒 | MB/秒 |
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는 액세스 로그를 수집 할 수 없기 때문에 실수입니다.
'Cloud > AWS' 카테고리의 다른 글
| ec2루트 디바이스 볼륨, 블록 디바이스, 어떻게 AMI가 EBS/instance store와 맵핑되는지 (0) | 2018.12.04 |
|---|---|
| EBS volume와 instance store volume의 차이 (0) | 2018.12.04 |
| vpc피어링 해보기(rt설정, sg설정, 동작확인) (0) | 2018.12.01 |
| AWS EC2 Container Service(ECS) - 구조와 특징 (0) | 2018.11.06 |
| EC２에서 public IP할당과 EIP할당의 차이점 (0) | 2018.09.05 |