0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【terraform】AWSコンソールで手動で作成するべきリソースについて

Last updated at Posted at 2025-02-28

AWSコンソールで手動作成し、Terraformのデータソースで取得すべきリソース

大前提として「全てをTerraformで管理するのが理想」です。IaC (Infrastructure as Code) の恩恵を最大限に受けるためには、定義ファイルでインフラ全体を記述し、バージョン管理するのがベストです。
※Terraformで誤って削除してはいけない重要なリソース(例:基幹システムのデータベース)を意図的にTerraform管理外とし、データソースで参照のみに留めることで、人的ミスによる事故を防ぐことができます。

以下は、AWSコンソールでリソースを手動作成し、Terraformではデータソースとして取得する際のベストプラクティスです。

これらのリソースは、ステートフルであったり既存のリソースであったり、セキュリティやコンプライアンス上の理由、または設定の複雑さから手動管理が推奨されるものです。


1. VPC/サブネット/ルートテーブル/IGW

  • 理由

    ネットワークの基盤となるリソースはステートフルであり、誤った変更がネットワーク全体に影響を与える可能性が高いため、既存リソースとして手動管理するのが望ましい。

  • データソース例

    aws_vpc(必要に応じてサブネットやルートテーブル、IGWも個別にデータソースで取得可能)

  • 実務上のポイント

    複数チームで共有する共通基盤の場合、既存のVPCや関連リソースを手動で管理し、Terraformでは参照専用とする。


2. セキュリティグループ

  • 理由

    インスタンスのセキュリティを管理する重要なリソースであり、直接Terraformで管理するとルールの競合や意図しない削除が発生するリスクがある。

  • データソース例

    aws_security_group

  • 実務上のポイント

    セキュリティチームなどが手動で設定・変更する場合、Terraformはあくまで既存の設定を参照するに留める。


3. IAMロールとポリシー

  • 理由

    アクセス管理はセキュリティおよびコンプライアンスの要であり、誤設定によるリスクを回避するために、組織で手動管理するケースが多い。

  • データソース例

    aws_iam_role

  • 実務上のポイント

    組織全体でIAMの管理を集中化する場合、Terraformでの変更を避け、既存リソースとしてデータソースで取得する。


4. KMSキー

  • 理由

    機密データの暗号化に利用されるリソースで、セキュリティや監査要件を満たすために、手動でポリシーやキー管理を行うことが望ましい。

  • データソース例

    aws_kms_key

  • 実務上のポイント

    セキュリティガバナンス上、KMSキーは既存リソースとしてTerraformで参照し、変更管理を厳格に行う。


5. RDSインスタンス

  • 理由

    ステートフルなデータベースサービスであり、データの永続性・整合性を担保するため、運用中のRDSをTerraformで直接管理するとリスクが伴う。

  • データソース例

    aws_db_instance

  • 実務上のポイント

    本番環境のデータベースは手動管理し、Terraformではその状態や設定を参照するに留める。


6. S3バケット

  • 理由

    オブジェクトストレージはステートフルで、既存バケットをTerraformで直接管理すると、データの削除や設定の競合が発生する恐れがある。

  • データソース例

    aws_s3_bucket

  • 実務上のポイント

    既存のデータ保管用バケットや複数システムで共有するバケットは、Terraformのデータソースとして安全に参照する。


7. CloudFrontディストリビューション

  • 理由

    CDNサービスは設定が複雑で依存関係が多いため、手動管理することで柔軟性と安全性を確保できる。

  • データソース例

    aws_cloudfront_distribution

  • 実務上のポイント

    配信設定をカスタマイズする場合、既存のCloudFrontディストリビューションをTerraformで参照し、管理リスクを軽減する。


8. Route 53ゾーン

  • 理由

    DNSゾーンはステートフルなリソースで、Terraformで直接管理するとドメイン運用に影響を及ぼす可能性がある。

  • データソース例

    aws_route53_zone

  • 実務上のポイント

    ドメイン管理を外部のチームやプロセスが担当している場合、既存のゾーンをTerraformで参照するのが安全。


9. ACM証明書

  • 理由

    SSL/TLS証明書はAWSコンソールで発行・管理するケースが一般的であり、更新や運用の制御を手動で行うことが望ましい。

  • データソース例

    aws_acm_certificate

  • 実務上のポイント

    CloudFront、ALB、API Gatewayなどで利用する際、既存のACM証明書をTerraformのデータソースで参照することで、証明書の管理リスクを低減できる。


まとめ

Terraformのデータソースを活用することで、既存のインフラストラクチャを安全かつ一貫性のある形で管理しつつ、構成の追跡、再現性、自動化といったTerraformのメリットを享受できます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?