クイックスタート:最初のEC2インスタンスを起動する(5分)
AWS EC2は最初圧倒されるかもしれませんが、最初の仮想サーバー(「インスタンス」)の起動は驚くほど簡単です。EC2インスタンスを、スケーラブルなコンピューティング能力を提供するクラウド内の自分自身の仮想マシンと考えてください。6ヶ月以上にわたってEC2で重要なワークロードを管理してきた経験から、正しく設定すればその一貫した安定性を保証できます。必要最低限の設定で、最初のインスタンスを迅速にオンラインにしましょう。
ステップ1:AMI(Amazon Machine Image)を選択する
AMI(Amazon Machine Image)は、インスタンスのテンプレートと考えてください。オペレーティングシステムとプリインストールされたソフトウェアがバンドルされています。迅速に開始するには、通常、Amazon Linux 2 AMIまたはUbuntu Server AMIを選択します。これらはほとんどの汎用タスクにおいて信頼できる選択肢です。
# 例: 利用可能なAmazon Linux AMIを一覧表示(最新のものをフィルターする)
aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm*" --query 'reverse(sort_by(Images, &CreationDate))[:1].ImageId' --output text
ステップ2:インスタンスタイプを選択する
インスタンスタイプは、仮想サーバーのハードウェア仕様を定義し、CPU、メモリ、ストレージ、ネットワークパフォーマンスをカバーします。簡単なテストや開発には、t2.microまたはt3.micro(Free Tier対象)で通常十分です。本番環境では、インスタンスのサイジングはアプリケーションの需要に大きく依存します。これは多くの場合、m5やc5ファミリーのような、より強力なCPUやメモリリソースを提供するタイプを選択することを意味します。
ステップ3:セキュリティグループ(ファイアウォールルール)を設定する
セキュリティグループは、インスタンスの仮想ファイアウォールとして機能し、すべてのインバウンドおよびアウトバウンドトラフィックを細かく制御します。ウェブサーバーの場合、HTTP(ポート80)とHTTPS(ポート443)をどこからでも(0.0.0.0/0)許可するのが一般的です。SSHアクセス(ポート22)を設定する際は、常に特定のIPアドレスにアクセスを制限するというベストプラクティスに従ってください。これにより、攻撃対象領域が大幅に減少します。
# 例: セキュリティグループを作成し、ルールを追加する
aws ec2 create-security-group --group-name MyWebServerSG --description "ウェブサーバー用のセキュリティグループ"
aws ec2 authorize-security-group-ingress --group-name MyWebServerSG --protocol tcp --port 22 --cidr 0.0.0.0/0 # 本番環境には非推奨、自身のIPに制限してください
aws ec2 authorize-security-group-ingress --group-name MyWebServerSG --protocol tcp --port 80 --cidr 0.0.0.0/0
ステップ4:起動と接続
AMIとインスタンスタイプを選択し、セキュリティグループとキーペア(SSHアクセスに不可欠)の両方を設定したら、準備完了です。インスタンスを起動する時が来ました。これはAWSマネジメントコンソールまたはAWS CLI経由で便利に行うことができます。接続は通常、秘密鍵ファイルを使用してSSHで行われます。
# 例: インスタンスを起動する(簡略化)
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--count 1 \
--instance-type t2.micro \
--key-name MyKeyPair \
--security-group-ids sg-0123456789abcdef0 \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=MyFirstEC2}]'
# 例: SSH経由で接続する
ssh -i MyKeyPair.pem ec2-user@<your-instance-public-ip>
詳細:EC2のコアコンセプトを理解する
最初のインスタンスが実行されたので、さらにいくつかの層を掘り下げてみましょう。EC2は単にサーバーを起動するだけでなく、はるかに多くの機能を提供します。これらのコアコンセプトをしっかり理解することは、堅牢でスケーラブル、かつコスト効率の高いクラウドソリューションを構築するために不可欠です。
Amazon Machine Image (AMI)
AMIはEC2の基礎となる要素です。オペレーティングシステム、アプリケーションサーバー、およびあらゆるアプリケーションをバンドルします。パブリックAMI(Amazon、AWS Marketplace、またはコミュニティによって提供される)から選択することも、独自のカスタムAMIを作成することもできます。カスタムAMIは、デプロイメントを標準化し、すべてのインスタンス間で一貫性を確保するために非常に貴重です。私たちの本番環境では、カスタムAMIに大きく依存しています。これにより、新しいサーバーはすべて、私たちの厳密に承認されたソフトウェアスタックで開始されることが保証されます。
インスタンスタイプとファミリー
AWSは、インスタンスタイプを用途に合わせて最適化されたファミリーに分類しています。
- 汎用(M、Tインスタンス):これらは、コンピューティング、メモリ、ネットワーキングリソースのバランスが取れた組み合わせを提供します。ウェブサーバーや開発環境に最適です。
- コンピューティング最適化(Cインスタンス):高性能プロセッサを搭載しており、科学シミュレーションやゲームサーバーのようなCPU負荷の高いアプリケーションに最適です。
- メモリ最適化(R、Xインスタンス):大量のRAMを搭載して設計されており、高性能データベースやビッグデータ分析のようなメモリ集約型ワークロードに最適です。
- ストレージ最適化(I、Dインスタンス):大規模なローカルデータセットへの高いシーケンシャル読み書きアクセスを提供し、データウェアハウジングや分散ファイルシステムに優れています。
- アクセラレーテッドコンピューティング(P、G、Fインスタンス):これらのインスタンスは、機械学習のトレーニング、グラフィック処理、科学シミュレーションなどの特殊なタスクのために、ハードウェアアクセラレーター(GPUなど)を活用します。
適切なインスタンスタイプを選択することは、パフォーマンスと全体的なコスト効率の両方に直接影響します。
Elastic Block Store (EBS) ボリューム
EBSボリュームは、インスタンスのライフサイクルとは独立して永続化するネットワークアタッチ型のブロックストレージです。これは、インスタンスが終了してもデータが安全に保持されることを意味します。AWSは、さまざまなパフォーマンスとコスト要件に合わせて調整されたいくつかのEBSボリュームタイプを提供しています。
- gp3/gp2(汎用SSD):これらは、多種多様なワークロードに対してバランスの取れた価格/パフォーマンス比を提供します。私は通常、ほとんどのアプリケーションでこれをデフォルトの選択肢とし、コストとパフォーマンスの素晴らしいバランスを取っています。
- io1/io2(プロビジョンドIOPS SSD):これらは、一貫した高いパフォーマンスが最も重要となる、大規模なリレーショナルデータベースやNoSQLデータベースのようなミッションクリティカルなI/O集約型ワークロードに最適です。
- st1(スループット最適化HDD):ストリーミングデータ、ログ処理、ビッグデータアプリケーションのような、頻繁にアクセスされ、スループットが重要なワークロードに最適です。
- sc1(コールドHDD):アーカイブストレージや大規模バックアップのような、アクセス頻度の低いデータに適しており、GBあたりのコストが最も低いです。
決定的に重要なのは、EBSボリュームのスナップショットは堅牢なバックアップメカニズムを提供するということです。これは効果的なデータリカバリー戦略にとって絶対に不可欠です。
セキュアアクセス用のキーペア
キーペアはセキュアなアクセスの基本です。これらは公開鍵(AWSによって保存される)と秘密鍵(ユーザーによって安全に保存される)から構成されます。この暗号化ペアは、SSH経由でLinuxインスタンスに安全に接続するためのゲートウェイです。秘密鍵を紛失すると、インスタンスへのアクセスを永久に失うことになるため、最大限の注意を払って厳重に保管してください!
高度な使用法:スケーリングと自動化
基本に慣れてしまえば、EC2の堅牢な自動化とスケーラビリティ機能を通じて、その真の可能性を引き出すことができます。私は、本番環境で必要とされる一貫した安定性を達成するために、これらの機能が不可欠であると実感しています。
Auto Scaling Groups (ASG)
Auto Scaling Groups (ASG) は、アプリケーションにサービスを提供するEC2インスタンスの数を自動的に調整します。この調整は、需要、事前定義されたスケジュール、または堅牢なヘルスチェックに基づいて行われます。この機能は革新的であり、手動介入なしに変動するトラフィックをシームレスに管理し、高可用性と最適なコスト効率の両方を保証します。
# 例: 起動設定を作成する(ASG用、インスタンスプロパティを定義する)
aws autoscaling create-launch-configuration \
--launch-configuration-name MyWebLC \
--image-id ami-0abcdef1234567890 \
--count 1 \
--instance-type t2.micro \
--key-name MyKeyPair \
--security-groups sg-0123456789abcdef0
# 例: Auto Scaling Groupを作成する
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name MyWebASG \
--launch-configuration-name MyWebLC \
--min-size 1 \
--max-size 3 \
--desired-capacity 2 \
--vpc-zone-identifier "subnet-01234567,subnet-89abcdef" \
--health-check-type ELB \
--target-group-arns arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/MyTargetGroup/1234567890abcdef
Elastic Load Balancing (ELB)
Elastic Load Balancing (ELB) は、複数のEC2インスタンスにわたって受信アプリケーショントラフィックを自動的に分散します。このインテリジェントな分散は、アプリケーションの耐障害性を大幅に向上させるだけでなく、全体的なパフォーマンスも強化します。AWSは主に3つのタイプを提供しています。Application Load Balancers (ALB) はHTTP/HTTPSトラフィックに最適であり、Network Load Balancers (NLB) はTCP/UDPに極めて高いパフォーマンスを提供し、Classic Load Balancers (CLB) はレガシー要件に対応します。
インスタンスブートストラップのためのユーザーデータ
EC2インスタンスを起動する際、「ユーザーデータ」としてシェルスクリプト(またはcloud-initディレクティブ)を渡すオプションがあります。このスクリプトは、インスタンスが最初に起動するときに自動的に実行されます。これにより、ソフトウェアのインストール、設定、その他のセットアップタスクを自動化できます。この機能は、特にInfrastructure as Code (IaC) のアプローチを採用する場合に非常に貴重です。
# 例: Apacheをインストールして起動するユーザーデータスクリプト
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>EC2からのこんにちは!</h1>" > /var/www/html/index.html
EC2インスタンスのためのIAMロール
AWSの認証情報をインスタンスに直接ハードコーディングする代わりに、常にIAMロールを割り当ててください。これにより、インスタンスに一時的でローテーションされる認証情報が付与されます。これにより、インスタンス上で実行されているアプリケーションが、静的なアクセスキーを保存することなく、他のAWSサービス(S3、DynamoDB、またはRDSなど)と安全にやり取りできるようになります。IAMロールを実装することは、私がすべての環境で一貫して適用している重要なセキュリティのベストプラクティスです。
EC2管理の実践的なヒント
技術的な設定を超えて、EC2フリートの効果的な管理は、堅牢でコスト効率の高いクラウドプレゼンスを維持するために不可欠です。本番環境での私の経験は、これらの戦略を一貫して適用することで、安定した運用につながることを示しています。
CloudWatchによる監視
AWS CloudWatchは、EC2インスタンスの包括的な監視を提供します。重要なメトリクスを収集および追跡し、ログファイルを集約し、アラームを設定できます。CPU使用率が5分以上70%を超える、ネットワークI/O、ディスク使用量などの主要な指標に対してアラームを設定し、軽微な問題が大きな問題にエスカレートする前に積極的にアラートを受け取りましょう。
コスト最適化戦略
- 適切なサイジング:CloudWatchのようなツールでインスタンスの使用状況を継続的に監視し、ワークロードの要件に正確に一致するようにインスタンスタイプを調整します。完全に利用しないリソースに料金を支払うのはやめましょう。
- リザーブドインスタンス (RI):予測可能で長期的なワークロードには、オンデマンド料金と比較して最大75%の割引を提供するRIが有効です。
- Savings Plans:RIよりも柔軟な選択肢であるSavings Plansは、1年または3年の期間にわたる一貫したコンピューティング使用量へのコミットメントと引き換えに、最大72%の割引を提供します。
- スポットインスタンス:フォールトトレラントまたは柔軟なアプリケーションの場合、スポットインスタンスはオンデマンド料金よりも最大90%安価になる可能性がありますが、AWSは最短2分前通知で回収する場合があります。
- 未使用のインスタンスの停止:シンプルですが非常に効果的です。継続的に必要とされない開発またはステージングインスタンスは、不要な料金を避けるために使用していないときは停止すべきです。
セキュリティのベストプラクティス
- 最小特権:常にIAMロールとセキュリティグループに、必要最小限の権限のみを付与します。
- 定期的なパッチ適用:脆弱性を軽減するために、インスタンスのオペレーティングシステムとアプリケーションを最新のセキュリティパッチで常に更新してください。
- VPCフローログ:EC2インスタンスへのネットワークトラフィックを積極的に監視します。これにより、異常や潜在的なセキュリティ脅威の検出に役立ちます。
- エンドポイントセキュリティ:AWS Systems Managerを活用してインスタンスの脆弱性を管理およびスキャンすることを検討し、セキュアな状態を確保します。
- データ暗号化:EBSボリュームとそのスナップショットの両方を暗号化します。この重要なステップは、保存中のデータを保護し、多くの規制要件に準拠します。
AWS Systems Managerによる自動化
AWS Systems Managerは、運用上の深い洞察を得て、AWSリソース全体でアクションを実行するための統一されたインターフェースを提供します。私はパッチ管理、数百のインスタンスにわたるコマンドの実行、インベントリの収集などのタスクに非常に役立つと感じています。本番サーバーでのその広範な使用は、私が観察した安定した運用に直接貢献しています。
EC2インスタンスを効果的に管理するには、パフォーマンス、コスト、およびセキュリティのバランスを取ることが求められます。コアサービスをしっかり理解し、Auto ScalingやIAMロールなどの高度な機能を段階的に組み込むことで、非常に堅牢で効率的なインフラストラクチャを構築できます。本番環境での経験から、これらの原則を一貫して適用することで、真に安定した予測可能な結果が得られることが示されています。

