AWS（Amazon Web Service）はGAFAの一角、Amazon社が展開する世界最大のクラウドサービスです。クラウドサービスはセキュリティ対策も万全で、AWSを利用する上で利用者側は何も意識する必要がないと思われがちですが、それは大きな誤りです。

**AWSを利用する場合は、利用者側も障害などに対して一定の責任を負わなければならず、これがAWSの「責任共有モデル」と言われるものです。**その責任を理解した上で、必要な対策を講じ、ルールを順守して利用することが求められます。

この記事では、AWSの責任共有モデルとは何か、利用者側の責任範囲はどこまでか、利用に当たって注意すべきことは何かなどについて解説します。

【参考】：[アマゾン ウェブ サービス｜AWS クラウド｜ ホーム](https://aws.amazon.com/jp/)

AWSとは？メリットや何がすごいのか、初心者にもわかりやすく解説

AWSには独自の「責任共有モデル」（shared responsibility model）があり、わかりやすくいうと、「セキュリティとコンプライアンスはAWSと利用者の間で共有されるべき責任」という考え方に基づいています。

**AWSの責任共有モデルは、AWS提供のインフラやサービスの内、AWS責任範囲と、利用者責任範囲を明確に分けています。**具体的にはAWSの責任範囲はAWSが提供するハードウェア・ソフトウェア、ネットワークおよびAWSクラウドサービスを提供している施設です。

仮にAWSの責任範囲で事故があり、利用者側が損害を被った場合はAWSが損害賠償責任を負います。一方、AWSが提供するサービス以外の範囲が利用者責任ですが、その責任範囲は、利用者が選択したAWSクラウドサービスによって異なっています。

この責任共有モデルについては、「AWSホワイトペーパーとガイド」※でも詳しく解説されています。

【参考】：[責任共有モデル – アマゾン ウェブ サービス｜AWS](https://aws.amazon.com/jp/compliance/shared-responsibility-model/)

【参考】：※[AWSホワイトペーパーとガイド | AWS](https://aws.amazon.com/jp/whitepapers/?whitepapers-main.sort-by=item.additionalFields.sortDate&whitepapers-main.sort-order=desc&awsf.whitepapers-content-type=*all&awsf.whitepapers-tech-category=*all&awsf.whitepapers-industries=*all&awsf.whitepapers-business-category=*all&awsf.whitepapers-global-methodology=*all)

AWSの公式ホワイトペーパーとは？日本語掲載情報はどこ？

AWSには「Lambda」というサーバレスのFaaS（Function as a Service）のサービスがあります。インスタンスを構築せず、いきなりコードを実行できるサービスですが、このLambdaにも責任共有モデルがあります。

**Lambdaでの利用者側の主な責任範囲は、Lambda内にデプロイしたアプリケーションとデータ、そしてインターネットからのアクセスです。**詳しくは「AWS Lambda のセキュリティの概要」に記されています。

【参考】：※[AWS Lambda のセキュリティの概要-Security Overview of AWS Lambda_JP.pdf｜AWS](https://d1.awsstatic.com/serverless-jp/Security%20Overview%20of%20AWS%20Lambda_JP.pdf)

AWS Lambdaとは？できることを分かりやすく解説！

### AWSの利用者によるセキュリティ事故

AWSをはじめとして、クラウドサービスは堅牢なセキュリティ対策を講じています。クラウド事業者側に起因する大規模な事故が起きれば、クラウドビジネスそのものが否定されかねないからです。

その結果、クラウドサービスにおけるセキユリティ事故の大半は、クラウド事業者側ではなく利用者側の人的なミスによって起きていると言われています。

主なものとしては、リモート操作で利用するSSH（Secure Shell）のポートの閉じ忘れによる不正ログイン、ストレージサービスのバケット開放による情報漏洩、IAM ユーザーやAWSアカウントルートユーザーのアクセスキー漏洩などが挙げられています。

個人情報の漏洩が起きると、その影響範囲は自社のみならず顧客全体に及び、その結果として企業の信用失墜・株価下落・売上低下・顧客への損害補償などで企業の経営自体が危うくなるケースもあります。

また、場合によってはAWS自体に被害を及ぼしたり、他のAWS利用者に迷惑を及ぼしたりする場合も想定され、被害者側から損害賠償請求を受ける可能性があります。

クラウド利用にはこうした**リスクがあることを踏まえて、利用者側もルールを守り、万全のセキュリティ対策を講じることが求められます。**

責任共有モデルはAWS認定資格にも試験問題として出題されています。AWS認定の受験者の方は、その覚え方に苦慮されている方もいるかと思いますが、賃貸マンションのオーナーと入居者の関係で考えると覚えやすいでしょう。

建物全体の管理責任はオーナーにありますが、部屋の鍵を掛けるなど、各部屋のセキュリティは入居者の責任です。このように考えてみると、責任共有モデルにおける各々の責任範囲は非常に合理的だと分かります。

責任共有モデルでは、AWS側の責任範囲はどこまでなのでしょうか？責任共有モデルにおける**AWS側の責任範囲は、AWSサービスのベースとなっているインフラストラクチャー部分です。**これからAWSの責任範囲を1つずつ見ていきましょう。主な責任範囲を以下に列挙していきます。

AWSの施設（データセンター）は、リージョン > アベイラリビリティゾーン > データセンターの階層で世界中に展開されています。日本では2つのリージョン（東京と大阪）があり、リージョン間で相互バックアップが可能です。

さらに、**データセンターは4つのレイヤー（施設・インフラストラクチャ・データ・環境）ごとに強固なセキュリティ対策が施されています。**

また、データセンター自体が災害などによって機能停止に陥ると、他のAWSのデータセンターで機能を継続できるような仕組みが講じられています。これをディザスタリカバリ （disaster recovery） DR）と言います。こうしたデータセンター施設の管理責任は、すべてAWS側にあります。

AWSのリージョンとは？リージョン選択のおすすめポイントを解説

### 2：インフラストラクチャの管理

AWSのデータセンター内には、様々なインフラ設備があります。電源・空調・ネットワーク・サーバ・ストレージなどはすべて24時間の監視下にあり、冗長化などによって完全無停止を前提とした構成で稼働しています。**このインフラストラクチャ全体の管理はAWSの責任範囲となっています。**

### 3：ホストOS（ハイパーバイザー）の管理

**AWSは、ホストOSに不正アクセスが行われないようなセキュリティを保障しています。**これもAWSの責任範囲です。ホストOSに対するアクセスは多要素認証に基づく厳重な管理が行われ、外部からアクセスするのが非常に難しい仕様になっています。

またホストOSに対する操作が終了した後は、付与特権とアクセス権がその都度削除され、全てのアクセスのログが保管されています。

AWSの責任共有モデルでは、**AWSが提供するサービス以外はすべて利用者側の責任範囲です。**利用するサービスによって責任範囲が異なるので、ここではAWSの代表的なIaaSサービスであるAmazon EC2を利用する場合の責任範囲について1つずつ見ていきましょう。

Amazon EC2 インスタンスなどAWSのIaaSを利用する場、**「ゲストOSの更新やセキュリティパッチの適用、アプリケーションの管理、ファイアウォールの構成」などは利用者の責任範囲です。**すなわち、ゲストOSよりも上のレイヤーに関してはすべて利用者責任ということです。

Amazon EC2 のサービスはIaaSのため、**ネットワークの設定を含むセキュリティ構成や管理は利用者側の責任で行う必要があります。**すなわち、ネットワークを介して情報漏洩などが起きれば、利用者側の責任となります。

ネットワークの設定に問題はないか、利用しないポートは開けっ放しになっていないかなど、十分なチェックが求められます。

Amazon EC2においては、利用者が持ち込んだ**アプリケーションは100%利用者側の責任で管理し、運用しなければなりません。**アプリケーションの動作不具合などで、利用者側や、そのアプリケーションを利用する顧客が損害を負っても、AWS側には一切の責任がありません。

そのため、開発・導入したアプリケーションは十分なテスト、検証を行ってからリリースすることが求められます。

**AWSサービスの中で取り扱うデータに関して、データの暗号化責任は利用者側にあります。**取り扱うデータのオーナーはAWSサービスの利用者であり、その管理方法は利用者が決めることですので、AWSは一切関与できません。

データの暗号化の責任と同様、AWSサービスの利用者**アカウント、アカウントに紐づくアプリやシステム、データへのアクセス権の管理や運用はすべて利用者の責任範囲です。**アクセス権限管理漏れ、設定ミスがセキュリティ事故の多くを占めますので、利用者側は十二分に留意すべきでしょう。

ITエンジニアが知っておくべきAWSアカウントのセキュリティ管理

## AWSを利用する上で行うべきセキュリティ対策

ここまで、AWS側と利用者側の責任範囲について確認をしましたが、それでは利用者側は具体的にどのようなセキュリティ対策を講じる必要があるのかを、見ていきましょう。ここでは、*AWSを使用する際の代表的なセキュリティ対策をご紹介します。*

【参考】：[AWS アカウントのセキュリティを改善するための 10 個の項目｜AWS](https://aws.amazon.com/jp/blogs/news/top-10-security-items-to-improve-in-your-aws-account/)

### セキュリティグループをしっかり設定する

利用に際して、まず初めにセキュリティグループの設定を行いましょう。**セキュリティグループは仮想ファイアウォールとも呼ばれ、EC2インスタンスのセキュリティを確保する上で重要な役目があります。**

セキュリティグループの設定では、EC2インスタンスに対してアクセス許可の範囲、トラフィックの制御を行うことができます。特に開発環境では関係者の出入りが多く、アクセス権限管理が難しくなり、セキュリティ被害を受けやすくなりがちです。

そのため、インバウンドルール（アクセス制限ルール）を厳しく設定して、必要がない人には公開しないようにすることが求められます。

【参考】：[セキュリティグループを使用してリソースへのトラフィックを制御する｜AWS](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_SecurityGroups.html)

### 認証情報を定期的に確認し、無効化する

セキュリティ対策としてログの管理は重要な要素の1つですので、**定期的に認証情報を確認して、不審な認証がないかどうかを確認しましょう。**

未使用のIDが不正アクセスに利用されるケースがありますので、発行済IDで一定期間利用がないIDは、本人の確認を得て削除します。不要なIDを無くすことが不正アクセス防止に重要です。

他には、ソフトウェアのバージョン管理も重要です。セキュリティの脆弱性が見つかると、それが攻撃の標的になりがちです。常にセキュリティパッチの有無を定期的に確認し、ソフトウェアのバージョン管理に細心の注意を払いましょう。

【参考】：[CloudWatch でのログの検索および分析 - AWS の規範的ガイダンス ｜ AWS](https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/cloudwatch-search-analysis.html)

### マルウェア・ウィルス対策を施す

AWSのサービスは全般的に強固なセキュリティ対策が施されていますが、クラウドはインターネットに対して公開された環境にあるため、ソフトウエアの脆弱性などを利用したマルウェアやコンピュータウィルスが侵入してくるリスクはゼロではありません。

また、自社のパソコンなどからウィルス感染する可能性もあります。**マルアェア対策、ウィルス対策は利用者の責任ですので、アンチウィルスソフトを適用するなど、万全の対策を図ることが求められます。**

### AWSのMFA（多要素認証）を利用する

AWSアカウントはデフォルトではメールアドレスとパスワードの組み合わせですが、これが盗まれると大変なことになります。そこで、**AWSサービスの機能として備わっているMFA（多要素認証）を設定しておくとよいでしょう。**これを有効にしておくと、第三者による不正ログインを防ぐことができます。

【参考】：[AWS での多要素認証 (MFA) の使用 ｜ AWS](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa.html)

AWSは上記以外にアカウントセキュリティを高める方法として10項目の励行を提唱しています。他には、**AWSの脆弱性診断サービス※がありますので、自社のセキュリティ脆弱性の診断を検討しましょう。**

この第3者による診断によって、脆弱性の問題が客観的に分かりますので、効果的なセキュリティ対策を講じることができます。

【参考】：※[アプリのセキュリティとコンプライアンスの改善をサポート ｜ AWS](https://aws.amazon.com/jp/inspector/)

## クラウド利用の効果を最大化するために

ここまで、「AWSの責任共有モデル」について、概要、それぞれの責任範囲、セキュリティ対策などについて解説しました。

AWSという安全な環境を利用しても、セキュリティリスクが多く残ることに驚かれた方がいるかもしれませんが、セキュリティリスクの大半は人的リスクです。またAWSはオンプレミスと比較して、利用者側が行わなくてはならないセキュリティ対策は圧倒的に軽減されます。

だからこそ、政府や金融機関など、セキュリティ基準が厳しい組織がAWSを利用しているのです。責任共有モデルによって、**AWSでは責任の分界点が明らかになっている点をポジティブに受け止め、AWSを正しく安全に利用して、クラウド利用の効果を最大化させていきましょう。**

AWSの提供するマネージドサービスとは？メリットや利用方法を解説

AWSを利用する場合は、「責任共有モデル」に従って利用者側も一定の責任を負います。その責任を理解した上で、必要な対策を講じ、ルールを順守して利用することが重要です。この記事ではAWSの責任共有モデルとは何か、利用者側の責任範囲はどこまでかについて解説します。

AWSには「責任共有モデル」という考え方があり、セキュリティ対策の責任はそれぞれが負うことになっている

AWS利用で、利用者側の対策不備によってセキュリティ事故が発生した場合は利用者がその全ての責任を負う

AWSには利用者側が行うべき10のセキュリティ対策があり、これらの遵守が求められる

AWS責任共有モデルとは？クラウドサービスの正しい利用法を解説！

AWSのEBSとは「Elastic Block Store」の略で、AWSが提供するストレージサービスの1つです。Elasticは弾力性があるという意味であり、利用目的に応じてサービスを柔軟に利用できるストレージサービスのことだと理解できます。

**AWS EBSはEC2インスタンスで利用するために設計されており、EC2上の仮想マシンにEBSボリュームを割り当てることで、仮想マシンのストレージの管理が柔軟に行えるようになります。**

この記事では、AWS EBSをテーマに特徴や他のサービスとの違い、利用料金や使い方などについて解説します。

【参考】：[Amazon EBS（EC2 ブロックストレージボリューム）| AWS](https://aws.amazon.com/jp/ebs/)

ブロックストレージは「ブロック」という単位でデータを保存し、管理するストレージのことです。*普段私たちが利用しているPCやサーバに搭載されるハードディスクやUSBメモリがブロックストレージに該当します。*

ブロックストレージは階層構造を必要とせず、メタデータが付加されず、読み込みデータへのパスが複数指定できることなどから、高速なアクセスを実現します。ストレージには他に、ファイルストレージやオブジェクトストレージがあります。

AWSにはよく知られた仮想サーバサービスEC2（Elastic Compute Cloud）がありますが、EBSとEC2はどのような関係にあるのでしょうか。*EBSはEC2インスタンス（仮想サーバ）用に準備されたストレージであり、EC2のデータはすべてEBSに保存されます。*

AWSのサーバー提供サービスであるAmazon EC2とは？活用方法や料金体系等を解説！

AWS S3（Simple Storage Service）はEBSと並んで、AWSの代表的なストレージサービスです。

EBSがEC2インスタンスにアタッチして利用するのに対し、*オブジェクトストレージであるS3はデータのバックアップ、災害対策用、アーカイブ、ビッグデータ分析用のデータレイクなど、主としてデータを保管場所として利用します。*

AWSについて改めて確認しておきましょう。AWSは『Amazon Web Service』の略称で、*GAFAとして知られる米国巨大IT企業4社の1つ、Amazon社が提供する100以上のクラウドコンピューティングサービスの総称です。*

AWSの利用者はインターネット経由で仮想サーバやストレージ、データベースなどのサービスを利用することができます。日本では政府が行政サービスDX化のプラットフォームとしてAWSを採用したこともあり、AWSは日本国内でも注目を集めています。　

【参考】：[アマゾン ウェブ サービス（AWS クラウド）](https://aws.amazon.com/jp/)
【参考】：[日本の行政機関のデジタルイノベーションを支援 | Amazon Web Services ブログ](https://aws.amazon.com/jp/blogs/news/accelerating-goverment-innovation-in-japan/)


AWS EBSは、主にEC2インスタンスのデータ保管という役割を担っていますが、ここではAWS EBSの主な特徴について紹介していきます。

**AWS EBSには、SSDとHDDの2種類のディスクタイプがあります。**読み書きの速度が速いSSDタイプは更新頻度の高いデータの保存に適しています。一方、HDDタイプは大量のデータ転送を伴う処理に適しています。

**AWS EBSは障害の発生が起こりにくい高可用性を特徴としています。**具体的には、AWSは99.99９%の可用性を確保しており、1年間の内でダウンタイムはわずか数分程度の計算になります。この可用性の高さがEBSの特徴の1つです。

高可用性・耐久性を誇るEBSですが、**万が一の備えとしてSnapshotと呼ばれるデータの差分バックアップ機能が用意されています。**

Snapshotは直近のスナップショットから変更分のブロックだけを対象にし、完全なデータを保存しながらも、必要なストレージの量が最小限に抑えられるメリットがあります。この差分データは低料金のAWS S3に保存されるため、バックアップに掛かる費用を低く抑えられます。

**AWS EBSは利用目的によって、4種類のボリュームタイプから選択することができます。**EBSで選択できる4つのボリュームタイプについて、それぞれの特徴や用途を紹介します。

*■ EBS 汎用 SSD （gp2）*
Amazon EC2インスタンスでデフォルトのEBSボリュームがgp2です。gp2はコストパフォーマンスが高く、開発環境やテスト環境を構築する際によく利用されています。gp2は3IOPS/GBの性能保証があり、利用状況に合わせて最大3000IOPSまでのバーストが可能です。

ただしバーストの持続時間に制限があり、高いディスクI/Oが必要な用途では注意が必要です。

*■ Eプロビジョンド IOPS SSD（io1）*
最高レベルのパフォーマンスを誇るEBSストレージが、io1です。アプリケーションやデータベースなど、ディスクI/Oが多く、ミッションクリティカルな処理に適しています。ストレージ容量のプロビジョニング費用に加え、IOPS毎の費用が加算されるため、他のボリュームに比較して費用は割高になります。

*■ Eスループット最適化 HDD （st1）*
st1は高速HDDをベースとし、安定したスループットが要求されるシステムに適しています。データセットやI/Oのサイズが大きく、アクセス頻度の高いストリーミングやビッグデータ向けデータストアなどに最適です。

*■ Cold HDD （sc1）*
sc1は低コストなボリュームタイプです。SSDを利用したボリュームと比べてHDDは大容量かつ連続したデータの保存に適しており、低速でアクセス頻度が少ないバックアップなど、大容量データの格納などの用途に適しています。

ただし、sc1は、EC2インスタンスのブートボリュームとしては利用ができませんので注意が必要です。

AWS EBSを実際に利用する前に、料金と使い方について確認しておきましょう。

AWS EBSの特徴やメリットは理解できても、利用料金が心配だという人もいるでしょう。無料枠が気に入って契約したところ、想定以上に費用が掛かってしまうケースもあります。そのような事態に陥らないよう、**最初に料金見積もりを行い、納得した上で利用するようにしましょう。**

AWSには料金見積もりツールが用意されていますので、これを利用して料金見積もりを行ってください。

【参照】：[AWS 料金見積りツール](https://calculator.aws/#/)

*■ 無料利用枠 *
AWS EBSは以下の条件で12カ月間無料で利用が可能です。

▪30 GB の Amazon EBS: 汎用 （SSD） ストレージまたは磁気ストレージの任意の組み合わせ
▪200 万 I/O （EBS Magnetic の場合）
▪1 GB のスナップショットストレージ

*■ 有料部分の利用料金* 
AWS EBSの有料部分の利用料金例を紹介します。（東京リージョンの料金です。為替変動により単位料金は変動します。）おおよその費用感が分かるでしょう。

（例）汎用SSD（gp3）ボリューム：1カ月30日間に12時間、2,000GBのボリュームをプロビジョニング（準備）し、さらにボリュームに対し 10,000 IOPS と 500MB/秒をプロビジョニングしたと仮定。

▪Gp3 ボリュームチャージ：2.677ドル（GB/月につき 0.08 ドル ）
▪Gp3 IOPS 料金：0.583ドル（プロビジョンド IOPS あたり月 0.005ドル ）
▪Gp3 のベースラインパフォーマンスの料金：0.375ドル（1 か月におけるプロビジョンド MB/秒あたり 0.06 USD ）

以上を合計すると、約3.625ドル/月になります。

【参照】：[Amazon EBS の料金 ｜ Amazon Web Services](https://aws.amazon.com/jp/ebs/pricing/)

Amazon EBS はEC2インスタンスにアタッチする際には、同じアベイラビリティーゾーン（データセンター）に存在することが前提です。**ここではEBS ボリュームのEC2インスタンスへのアタッチからマウントして、利用できるようにするまでの手順について紹介します。**

*■ 1．EBS ボリュームを作成する*
AWS EBSを利用するには、まず最初にマネジメントコンソールから以下の手順で空のEBSボリュームを作成します。

▪AWS マネジメントコンソールよりAmazon EC2 コンソールを開きます。
▪ナビゲーションバーよりEBSボリュームを作成するリージョンを選択します。
▪ナビゲーションペインより、「Elastic Block Store」にある［ボリューム］を選択し、［ボリュームの作成］を選択します。
▪［ボリュームタイプ］を選択します。
▪［サイズ （GiB）］ボリュームサイズを入力します。（1GiB～16TiB）
▪［Availability Zone］でEBSボリュームを作成するアベイラビリティーゾーン（データセンター）を選択します。
▪EBSボリュームを暗号化する場合は [このボリュームを暗号化する] を選択します。
　※使用するアカウントで暗号化が有効になっている場合は自動的に暗号化されます。
▪最後に［ボリュームの作成］を選択します。

【参照】：[Amazon EBS ボリュームの作成 ｜ Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-creating-volume.html)

*■ 2．EC2 インスタンスにアタッチする*
EBSボリュームが作成できたら、同じくAmazon EC2 コンソールからEC2インスタンスにEBSボリュームをアタッチします。アタッチとは、仮想マシンにボリュームを割り当てることです。

▪ナビゲーションペインより［Elastic Block Store］の［ボリューム］を選択します。
▪アタッチしたい EBS ボリュームにチェックを入れ、［アクション］の中 から［ボリュームのアタッチ］を選択します。
▪［インスタンス］にインスタンスの名称または ID を入力する、もしくはリストよりインスタンスを選択します。
▪［デバイス］でデバイス名の変更を行うことができます。

▪以上の操作を終えたら［アタッチ］を選択します。

【参照】：[インスタンスへの Amazon EBS ボリュームのアタッチ ｜ Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-attaching-volume.html)

*■ 3．EBS ボリュームをマウントする*
EBSボリュームをEC2インスタンスにアタッチできたら、次にマウントを行います。マウントとは、アタッチしたボリュームをOSなどのソフトウェアに認識させて、操作や利用が可能な状態にすることです。詳細の操作手順は以下のAWSのガイダンスに従って行ってください。

【参照】：[Linux で Amazon EBS ボリュームを使用できるようにする｜ Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-using-volumes.html)

AWS Amazon EC2のインスタンスとは？インスタンスの起動・確認方法を合わせて解説！

## AWS EBSサービスを実際に試してみよう

この記事では、AWSのサービスでよく利用されるEC2では必須となるAWS EBSについて、その概要や特徴、利用料金や利用方法などについて紹介しました。AWSのサービスは個人でもアカウントを取得するだけで無料で試すことができます。

しかも実際に利用できるようになるまで、僅かな時間で済みます。**まずは無料枠を有効に利用し、利用用途に応じてAWS EBSを上手に活用してみてはいかがでしょうか。**

一般提供開始のAmazon EC2 Hpc6aインスタンスを解説

AWSのクラウドサービスは数多くありますが、代表的な仮想サーバサービスのEC2にはストレージサービスのEBSが欠かせません。この記事ではAWS  EBSについて、その概要、特徴や料金、利用方法などを紹介しますので、AWSを検討中の方はぜひ参考にしてください。

AWS EBSは主にEC2インスタンス向けのデータストレージのサービス名称である

AWS EBSは高可用性、2種類のディスクタイプ、4つのボリュームタイプ、Snapshot機能を特徴とする

AWS EBSは利用目的を明確にし、無料枠を含めて最適な組み合わせを選択するとよい

AWS EBSはEC2向けのストレージ！特徴や使い方を解説

AWSのAurora（Amazon Aurora）とは、AWSが提供するデータベースサービスの1つです。リレーショナルデータベースのサービスであり、商用データベースの持つ可用性と性能、そしてオープンソースの持つシンプルで安価なメリットを併せ持ちます。

**Amazon AuroraはMySQLとPostgreSQLとの完全な互換性があり、クラウドへの移行を促進します。**

【参考】：[Amazon Aurora](https://aws.amazon.com/jp/rds/aurora/)
【参考】：[Amazon Aurora とは](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html)

MySQLとは？特徴から使い方・学習方法まで詳しく解説！

PostgreSQLとは？MySQL・Oracleとの違いを解説

Auroraの特徴は、いくつか挙げられます。

*1つ目は、高いパフォーマンスを発揮できることです。*AWSによると、同等レベルのハードウェアにおいて標準的なMySQLとの比較で最大5倍、標準的なPostgreSQLとの比較で最大3倍のスループットが得られると公表されています。

*2つ目は、高いスケーラビリティです。*サーバーレス設定やオートスケーリングにより、容量拡張やスケールダウンに対応可能です。

*3つ目は耐障害性です。*AWSの3つのアベイラビリティゾーンにわたり、レプリケートされます。ストレージの書き込みや読み込みに影響を与えずに、データコピーの損失を処理したり、自己修復したりします。負荷分散のため、更新用マスターと参照用リードレプリカを使い分けし、性能向上も行われます。

【参考】：[Amazon Aurora の特徴 優れたパフォーマンスとスケーラビリティ](https://aws.amazon.com/jp/rds/aurora/features/#High_Performance_and_Scalability)

RDBとは、リレーショナルデータベース（Relational DataBase）の頭文字をとったもので表形式のデータを扱うデータベースを表します。複数の表形式のデータから必要なデータを抽出したり、更新したりします。

*RDBはデータに一貫性があり、最も利用されているデータベースの種類です。*商用データベース、オープンソースともに多数のRDBが提供されます。

データベースとは？今更聞けないその内容をITエンジニアとして改めて学ぶ

RDBを管理するRDBMSは、すべての要素を1つのエンジンにまとめた構成をとっています。*Auroraはクラウド環境に最適化しており、スケーラビリティや可用性、耐久性の観点から全体をデザインしています。*コンピュート部分とストレージ部分を個別のエンジンとして分離する設計を行っています。

このことで、AuroraはMySQLとPostgreSQLとの完全互換インターフェースを提供することができるようになり、性能・可能性・耐障害性を向上しました。

RDSとは「Amazon Relational Database Service」の略で、AWSのデータベースサービスです。マネージド型のRDBをウェブサービスで提供しています。AuroraとRDSの違いですが、いくつか挙げられます。

*サービスの位置付けとしては、AuroraはRDSの一部として提供されます。*RDSでサポートされるDBエンジンは、多くの種類を利用可能です。Auroraの他、MySQL・PostgreSQL・MariaDB・Oracle・SQL Serverがサポートされます。

RDSはマネージド型でありユーザーの利用環境をサービス管理してくれます。機能・性能・耐障害性の面で見ると、AuroraはRDSで提供されるDBエンジンとして利用され、その特長が活かされた利用が可能です。

Auroraは、クラウド利用を想定してデザインされており、高いパフォーマンスとスケーラビリティが提供されます。耐障害性の点では、Auroraは6重化されたDBインスタンスにより障害に強く、ディスク故障もRDSよりも強化されています。

料金は、高性能で耐障害性が高いことで、Auroraの方が高い傾向があります。選べるインスタンスタイプに違いがあります。Auroraの場合も、移行コストや管理費用なども総合的に踏まえると、全体のコスト低減に貢献することができます。

【参考】：[Amazon RDS](https://aws.amazon.com/jp/rds/)
【参考】：[Amazon Relational Database Service (Amazon RDS) とは](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Welcome.html)
【参考】：[Amazon RDS の料金](https://aws.amazon.com/jp/rds/pricing/)

新機能Amazon DevOps Guru for RDSを解説！

Auroraのメリットとしては、Auroraの特徴がそのまま活用できることが挙げられます。*高いパフォーマンスとスケーラビリティ、耐障害性などです。*

さらにMySQLとPostgreSQLとの完全な互換性は大きなメリットとなります。安全性にも気を配っており、企業向けセキュリティ機能・サービスを活用することができます。

Auroraのデメリットですが、*RDSに比較するとメリットを享受できる分、すべてを活用すると支払い料金が高くなっててしまうことが挙げられます。*また、MySQLとPostgreSQLとの完全な互換性を持つために、バージョンの依存性が高く、対応バージョンを意識する必要もあります。

Amazon Auroraを使うには、事前の準備が必要です。**初めて使う場合にはAWSのアカウント作成から始めます。**最初にAWSのアカウントにサインアップし管理ユーザ―を作成しておきます。必要に応じて、ユーザーにアクセス権を付与します。

【参考】：[Amazon Aurora の開始方法](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.html)

Auroraでは、DBクラスターを用いて利用します。*環境セットアップとして、DBクラスターには1つ以上のDBインスタンスが必要です。*

データベースへのアクセスは、公開されたクラスターエンドポイントに接続します。ここでは、必要となるメモリ、データベースエンジンとバージョン、ネットワーク設定、セキュリティなどの要件に基づいて、DBクラスターを作成します。

【参考】：[Amazon Aurora の環境をセットアップする](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/CHAP_SettingUp_Aurora.html)

### Amazon Aurora DBクラスターの構成要素

*AuroraのDBクラスターは、1つ以上のDBインスタンスと、DBインスタンスのデータを管理する1つのクラスターボリュームからなります。*

DBインスタンスは、読み書きを行うプライマリ DBインスタンスと、Auroraレプリカで構成されます。レプリカは読み取りのみに対応します。障害時にはフェイルオーバーし、処理を継続します。DBクラスターを作成する準備として、Amazon Virtual Private Cloud（VPC）を事前にセットアップしておきます。

【参考】：[Amazon Aurora DB クラスター](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html)
【参考】：[Amazon VPC](https://aws.amazon.com/jp/vpc/)

### Auroraでデータベースを作成する

*Auroraの操作は、Amazon RDS AWS マネジメントコンソールやCLIを用います。*Amazon RDS コンソールで、利用可能なリージョンを選択し、「データベース」「データベースの作成」で、「エンジンのタイプ」で「Amazon Aurora」を選択します。

続いて、「エディション」で使用するインターフェースを設定します。「Amazon Aurora with MySQL compatibility」でMySQL互換、「Amazon Aurora with PostgreSQL compatibility」はPostgreSQL互換に設定されます。

その後「DB インスタンスサイズ」などを設定後、「データベースの作成」でデータベースが作成されます。

【参考】：[Amazon RDS コンソール](https://console.aws.amazon.com/rds/)
【参考】：[Aurora リージョンとアベイラビリティーゾーン](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Concepts.RegionsAndAvailabilityZones.html#Aurora.Overview.Availability)
【参考】：[DB クラスターを作成して Aurora MySQL DB クラスターのデータベースに接続する](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.CreatingConnecting.Aurora.html)
【参考】：[DB クラスターを作成して Aurora PostgreSQL DB クラスターのデータベースに接続する](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.CreatingConnecting.AuroraPostgreSQL.html)

Auroraのバージョンについては、以下のドキュメントをご確認ください。

【参考】：[Amazon Aurora バージョン](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.VersionPolicy.html)

AWSマネジメントコンソールとは？機能やCLIとの違いを解説

### Auroraのデータベースを操作する

*Auroraのデータベースを操作するには、それぞれのRDBMSの操作コマンドならびにSQLコマンドを用います。*Amazon RDS for MySQLやAmazon RDS for PostgreSQLから、スナップショットやレプリケーションを用いてデータを移行することができます。

移行のためのツールも用意されており、移行後はデータ型に基づいて格納データをそのまま利用することができます。

データベースエンジンは、定期的に更新版がリリースされます。使用するにはバージョンを選択したり、アップグレード時に指定したりします。

Amazon Aurora MySQLの参考情報（Auroraのユーザーガイド）は、以下の通りです。

【参考】：[Amazon Aurora MySQL の操作](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.html)
【参考】：[DB クラスターを作成して Aurora MySQL DB クラスターのデータベースに接続する](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.CreatingConnecting.Aurora.html)
【参考】：[Amazon Aurora MySQL DB クラスターへのデータの移行](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.html)
【参考】：[Amazon Aurora MySQL のデータベースエンジンの更新](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.html)

Amazon Aurora PostgreSQLの参考情報（Auroraのユーザーガイド）は、以下の通りです。

【参考】：[Amazon Aurora PostgreSQL の操作](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html)
【参考】：[DB クラスターを作成して Aurora PostgreSQL DB クラスターのデータベースに接続する](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.CreatingConnecting.AuroraPostgreSQL.html)
【参考】：[PostgreSQL と互換性がある Amazon Aurora にデータを移行する](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Migrating.html)
【参考】：[Amazon Aurora PostgreSQL の更新](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Updates.html)

## AWSのAmazon Auroraは試してみる価値があります

クラウドサービスが浸透し、多くの業務がクラウド環境で稼働しています。クラウドで最適なデータベース環境を目指し設計されたAuroraは、高い性能・可用性・耐障害性が達成され、データベースの活用の幅が広がると考えられます。互換性が高いため作業工数を削減し、トータルのコスト低減も可能になります。

*Auroraはサーバーレスでの利用など、さらに工夫することも可能ですので、1度試してみることをおすすめします。*

AWSのAuroraは、リレーショナルデータベースのクラウドサービスです。MySQLとPostgreSQLとの完全な互換性があり、高い性能と可用性、耐障害性が特徴です。ここでは、Auroraの概要や他のRDBMSおよびRDSとの違い、使い方について解説します。

Amazon Auroraは、AWSが提供するデータベースサービスの1つです

AuroraはDBエンジンであり、RDSの一部として提供されます

クラウド環境で最適なDBとして設計され、高い性能と可用性、耐障害性を併せ持ちます

AWSが提供するAmazon Auroraとは？概要や他との違いを解説

**AWS Batchとは、バッチ処理を行うためのクラウドサービスです。**通常はバッチ用のソフトウェアやサーバークラスターが必要ですが、AWS Batchでは追加で管理することなしに、処理の計画からスケジュール・実行を行うことができます。

Amazon ECS・Amazon EKS・AWS Fargateなどのコンピューティングサービスで、必要なリソースを動的にプロビジョニングし利用します。

【参考】：[AWS Batch](https://aws.amazon.com/jp/batch/)
【参考】：[AWS Batch とは?](https://docs.aws.amazon.com/ja_jp/batch/latest/userguide/what-is-batch.html)

バッチとは、手順に基づく処理をジョブとして定義し、連続した実行や決められた時間に実行するための処理形式を表します。バッチを使った処理を、バッチ処理と呼びます。

定義したジョブは、定期実行するためのスケジューリングや、複数の処理の多重起動防止や実行順を設定するシーケンスなどを行う仕組みを使って起動されます。この仕組みをジョブ管理と呼びます。

*バッチ処理は、一括した大量の処理を投入した場合に処理を分散化したり、指定した時間に起動したりすることで自動実行することができます。*これにより、リソースの使用率を高めながら、安定処理を行うことが可能であり、コスト削減のメリットがあります。

加えてジョブの優先順位を設定することで、緊急処理にも対応できます。

*AWS Batchは、AWSのコンピューティングサービス上で簡単にバッチ用のジョブコードを作成できる特徴があります。*標準で使用するAWSのコンソールやCLIからジョブを投入することが可能です。

ワークフロー管理用のPegasus WMSやLuigi、Nextflow・Metaflow・Apache Airflow・AWS Step Functionsなどの言語で使用することもできます。

【参考】：[AWS Batch の特徴](https://aws.amazon.com/jp/batch/features/)

### AWS Batchのメリットとデメリット

AWSの記事（12ページ目）