質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.48%
AWS(Amazon Web Services)

Amazon Web Services (AWS)は、仮想空間を機軸とした、クラスター状のコンピュータ・ネットワーク・データベース・ストーレッジ・サポートツールをAWSというインフラから提供する商用サービスです。

Q&A

解決済

3回答

1564閲覧

AWS社内ルール制定時に記載すべきポイント

gonzaless333

総合スコア1

AWS(Amazon Web Services)

Amazon Web Services (AWS)は、仮想空間を機軸とした、クラスター状のコンピュータ・ネットワーク・データベース・ストーレッジ・サポートツールをAWSというインフラから提供する商用サービスです。

0グッド

0クリップ

投稿2020/10/27 13:40

編集2020/10/27 17:03

AWS社内ルール制定時に記載すべきポイントについて、
皆さんは社内で運用するAWSのアカウントやリソースにどのようなルールを設けていられるのでしょうか。
当方業務でAWSを利用したことがなく実際に現場などではどの粒度で記載されているのか見当がつかない状態です。実際に業務でAWSを利用している方・AWS利用にあたっての規約、ルールを作成された経験がある方に項目やポイントだけでもご教示いただきたく記載させていただきました。

個人での調査した結果、以下のポイントはルールとして記載するべきかと思っておりますが正しいのでしょうか?
・プロダクトごとのAWSアカウント分割とAWS Organizationの利用
・AWSリソースなどの命名規則?

正解がないのは理解しているため、
こういった観点で記載するといいと思う、とか
うちではこんな項目についても記載しているよ、などのご指摘でもいいので何卒宜しくお願い致します。

------------------------
「丸投げした質問」と「プログラミングと関係ない質問」とのご指摘がありましたのでクローズさせていただきます。一応規約などの投稿がこれまで行われているか、自分で行った点の記載、など規約違反にならないように投稿したつもりでしたが、不快に感じた方おられましたら申し訳ございません。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答3

0

ベストアンサー

どのような方、どのような用途で利用されるのか、@gonzaless333さんはどのような役割なのかなどを記載して頂くとより具体定例が出しやすいかと思います。

ひとまず、私の経験から紹介します。
部門用AWSと自社クラウドサービス用AWSとそれぞれ異なる契約のAWSを使用しています。
さらに自社クラウドサービスのAWSは開発、ステージング、本番とさらに異なる契約のAWSを所有しています。
私の組織では基本的にプロジェクト、プロダクト単位や用途でAWSアカウントを分けています。

それぞれのAWSを分けることで以下のメリットはあると考えています。

  • コストの切り分け(クラウドサービスのランニングコストと開発コストを明確に分けることができる)
  • セキュリティ(本番AWSに接続できる人が最小限で済む)
  • 事故を減らせる(間違えて本番のリソースを消したりすることがなくなる)
  • リソースの共用でコスト削減ができる(アーキテクチャに依存する)

デメリットは

  • 管理コスト

 ただし、基本的に自動化しているので、よくわからないリソースが使われるはない
部門用AWSのように雑多な用途の時はチームごとの使用量を算出してあげる必要がある

自社クラウドサービスが1つのみなので、リソースの管理として基本的にタグ付けを行っていて、自動処理でそれらのタグを参照するような形にしています。タグは基本的にリソースの種別用、役割用、バージョンなどを設けています。

一方部門用AWSは部門内の各チームが検証用に使っています。

ルールとしては以下になります。

  • 基本的に各チームが作成したリソースにタグ付けを義務化しています。
    タグはTeam名、利用者名になります。
    現時点タグ付けは手動になっていますが、今後EventBridge+Lambdaで作成者のIAM情報から自動的にタグ付けしようと検討中です。
  • EC2インスタンスについては基本的にスポットインスタンスを利用するようにしています。
  • アカウントは多要素認証必須
  • リソースの削除は自チームのタグが付与しているリソースのみ削除できるようにするIAMでコントロールしている。

コスト意識を持ってもらうために今後CostExploerで各チームごとの利用費を公開しようかと検討中です。そのためにもタグ付けは欠かせないですね。
あともしAWS管理者ならば、CloudTrialやAWS Configを有効にすることをお勧めします。
問題があった時に誰がどのリソースを変更したのかが追えるようになります。
またご存知かと思いますが、AWS Well-Architectedも一読されると良いかと思います。

投稿2020/10/27 15:20

comefigo

総合スコア1045

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

gonzaless333

2020/10/27 16:44

詳細なご返答誠に有難うございます。情報が不足しており大変お手間をおかけしたかと思います。 AWSの利用用途と致しましては自社サービス運用のためであり、複数サービス運用するとなった場合に命名規則がないことやアカウントの管理、VPC上限などを気にする必要が生じたため、ルールを策定するべきとなった運びです。 私の立ち位置と致しましては、これまでにAWSの社内資料作成などを担当したことがあり、作成を任されたといった感じでAWS管理者といった立場ではございません。 前述の通り業務で利用したことがないことは周知ですので、実際の社内規定のようなハイクオリティーの物ではなく、最低限これくらいはやっとかないとね、というレベルの共通となる部分のみを取り決める役割です。 comefigo様に記載頂いたルールは大変参考になりました。 貴重なお時間をいただき本当に感謝しております。
comefigo

2020/10/28 01:02

自社サービスの運用でしたら、私の組織と同じ感じですね。 複数サービスを考慮されるのであれば、サービス名も含めたほうがいいですね。 私は何が知りたいのか?なにを管理にしたいのか?で考えます。 例えば、サービスごとのコストを知りたいのであれば、サービス名をタグに含める必要があります。 また、開発、本番、ステージング環境が混合する場合(最低限VPC、リージョン分ける)や顧客ごとにEC2が異なるといった場合は、それらがわかるようにタグ付けといった具合です。 AWS管理者の立場ではないのであれば、最終的に運用と開発と一緒に一度どうしていきたいのか?など話をされたほうがいいと思います。 汎用的な部分に関しては前述のタグ付け等を参考にされるのであれば、たたき台にして頂いても良いかと思います。運用や開発の方もAWSに詳しくないのであれば、先にたたき台を作ってから話をされるとスムーズかと思います。 前述で漏れてしまったのですが、アカウントの共有も禁止にしています。 もし、共有で使用した場合は、共有した方がすべての責任を負うようにルール化しています。 最終的にはトライ&エラーで自組織にマッチした運用していくのがいいと思います。 最初は誰もが他社事例が気になるのは仕方ないと思います。 参考になれば幸いです。
guest

0

当方業務でAWSを利用したことがなく実際に現場などではどの粒度で記載されているのか見当がつかない状態です。

そもそも論としては、社内の業務要件をまとめてからその要件をクリアするルールをまとめないと意味が無いので、要件を整理するところからスタートするのが良いかと思いますよ。

トライ&エラーが許されるのであれば、要件定義と整理を念頭に置いてトライ&エラーをすると方向性も定まってくると思います。


時間的余裕が無いのであれば、AWS が推奨するパートナーから条件に合いそうなところを探して相談に乗ってもらうのが手っ取り早いです。
パートナーを通して契約すると利用料金が安くなったりサポートが手厚くなったりもします。

投稿2020/10/27 15:17

tanat

総合スコア18713

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

gonzaless333

2020/10/27 16:30 編集

ご指摘の通り本来であれば業務要件に準じてルールを設定するべきだとは思っており、そこに関して返す言葉もございません。 今回の質問については1プロジェクトの話ではなく、全般に通じるルールの設定という観点で質問させていただきました。記述に不足があり大変申し訳ございません。 また、パートナー等に相談することに関しましては現段階では本格的な社内での運用が直近ないため、あくまでこれから利用するにあたってのルール作りレベルで考えていたため検討しておりませんでした。 参考サイトまで載せていただき誠にありがとうございます。今後の参考にさせていただきます。
tanat

2020/10/27 16:17

> 今回の質問については1プロジェクトの話ではなく、全般に通じるルールの設定という観点で質問させていただきました。記述に不足があり大変申し訳ございません。 その部分に認識の齟齬は無いかと思いますよ。 全体であれば余計に要件を整理しない事にはルールを定めることは出来ないというか、`AWS 運用 ポイント`等で検索して見つかる一般論以外には定義できないでしょうし、それらにしても組織内の要件と相反するものもあることが多いです。 例えば、 - AWSに何を求めているのか(開発環境の構築なのか、サービス運用基盤なのかetc) - AWSを使用するにあたって少なくとも今わかっているレベルで発生したら困る事象はどういうものなのか - ルールに合わせて運用方針を決めることが出来るのか、出来ないのか 等の要件は存在するはずで、それらを明確にしない事には一般的に好ましいとされているルールが要件を満たすものかの判断は出来ないはずです。
gonzaless333

2020/10/27 16:56

ご返答ありがとうございます。夜分遅くまで申し訳ございません。 tanat様のおっしゃる通り、要件の整理をすれば自ずと策定すべき規定も決まるということを理解いたしました。 コーディング規約のように基礎部分に関しては変わらないものだと考えておりましたが、発生するであろう困ることをいったん整理し、それをもとに策定していきたいと思います。 貴重なお時間いただき感謝しております
comefigo

2020/10/28 00:47 編集

コメントする場所を間違えました。。。
guest

0

AWS社内ルール制定時に記載すべきポイントについて、

皆さんは社内で運用するAWSのアカウントやリソースにどのようなルールを設けていられるのでしょうか。

求めている情報とは趣が違うと思いますが、セキュリティ方面に特化した資料があるので紹介しておきます。

政府機関等の情報セキュリティ対策のための統一基準群 - aws.amazon.com

私も詳細まで読んだわけではないのですが、参考まで。

投稿2020/10/27 22:54

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.48%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問