AWS におけるマルチアカウントを統制

「AWS Control Tower のカスタマイズ」を試してみる

2022-10-03
AWS ソリューション紹介

須藤 裕也 (監修 : 山澤 良介)

無料クーポン特典の詳細 » 
 ツイート »
 シェア »
 はてブ »

こんにちは！AWSソリューションアーキテクトの須藤 裕也です。

皆さんは「AWS ソリューションライブラリ」をご存知でしょうか ? AWS ソリューションライブラリには、AWS サービスを用いた構成の参考となる AWS ソリューションリファレンスアーキテクチャ、AWS CDK を用いて複数の AWS サービスを組み合わせて構築する際に利用できる AWS Solutions Constructs 、AWS パートナーによる AWS ソリューションコンサルティングサービス、そして、今回紹介する「AWS Control Tower のカスタマイズ」が含まれる AWS ソリューション実装 が含まれています。

AWS ソリューション実装では、世界中のユーザーが直面している課題に対して、簡単に行える解決策を提供しています。AWS ソリューション実装は AWS CloudFormation のテンプレートが提供されており、お客様の環境で CloudFormation テンプレートを実行することで、手軽に実装可能です。構築後の運用はお客様の方で実施していただく必要がありますが、CloudFormation テンプレートは無料で入手することができ、お客様は実際に利用したサービスの利用料を負担いただくのみで利用できます。

今回ご紹介するソリューションは、「AWS Control Tower のカスタマイズ」というマルチアカウント管理のためのソリューションです。このソリューションは、AWS Control Tower がベースとして提供するマルチアカウント環境の上にお客様独自のルールを設定することで、お客様独自の要件に合わせたマルチアカウント環境を構築したいときにご活用いただけます。

お客様独自のルールとして、AWS Organizations の SCP (サービスコントロールポリシー) や CloudFormation テンプレートをご用意いただく必要はございますが、本ソリューションではこれら独自ルールの適用を自動化することができるため、マルチアカウント管理の負担を軽減し、効率的にアカウント全体に渡ってお客様独自の統制を効かせることができるようになります。

それではここから本ソリューションの概要や使い方を紹介しますが、その前に「なぜ AWS においてマルチアカウント環境が推奨されるのか」、そして「AWS Control Tower とは何か」について軽くおさらいします。

本ソリューションの内容をすぐに知りたい方は こちらのセクション からお読みください。

ご注意

本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。

*ハンズオン記事およびソースコードにおける免責事項 »

この記事のデモを無料でお試しいただけます »

毎月提供されるデベロッパー向けアップデート情報とともに、クレジットコードを受け取ることができます。 

今すぐ特典を受け取る »

AWS Control Tower と、そのカスタマイズとは？

日頃より AWS をご利用されている皆さんの中には、1 つの AWS アカウント内で全てのワークロードを管理されている方も多いかもしれません。そのような皆さんは、以下のような課題に直面したことがあるのではないでしょうか。

  • 誤操作で本番環境で動いているリソースを削除した / しそうになった
  • 1 つの組織で同一のアカウントを使用しているため、サービスごとに設定されているクォータ (制限) の上限にすぐに達してしまい、頻繁に上限引き上げの申請をしている
  • 権限管理やタグの管理、リソースのトラッキングが複雑化している

以上のような課題は、マルチアカウント構成をとることで解決できます。アカウントを分割することによるメリットは以下の通りです。

  • 開発、テスト、本番などの環境をセキュリティやガバナンス、規制のために分離できる
  • 部門単位やシステムの単位で AWS のコストが明確に分離できる
  • 事前定義されたガバナンスフレームワークの中で特定のビジネス部門に対する権限の委譲が行える
  • 外部向け/社内向けサービスや、リスクやデータ分類、顧客の違いなどに応じてワークロードを分離できる

しかしながら、いざマルチアカウント構成をとろうと考えても、以下のような悩みに直面するのではないでしょうか。

  • そもそもどのようなアカウントの分け方をしたらいいかわからない
  • アカウント間の設定の整合性を取るのが難しそう
  • 複数アカウントにポリシーや設定をいちいち導入するのは大変そう

マルチアカウント構成をとった場合、ビジネスや組織がスケールするに従ってどんどんアカウントが増加してしまうため、増加するアカウントを効率よく管理する仕組みが必要になってきます。

そこで登場するのが AWS Control Tower です !

マルチアカウント環境におけるセキュリティやガバナンスの要件に関して、AWSではさまざまなベストプラクティスがあります。その多くはお客様の要件によって設定する内容は変わってきますが、どのお客様でも共通で最低限設定することが推奨される内容もあります。例えば、複数アカウントのログを集約・保全することなどがこれにあたります。

従って、マルチアカウント環境を 1 から作るのではなく、ベースラインはすでにベストプラクティスとして出来上がったものを使って迅速に展開し、その上にお客様固有の統制を必要に応じて構築する、というのが効率的なアプローチではないでしょうか。

そこで、AWS のベストプラクティスに則った、マルチアカウント環境のベースラインを提供するのが AWS Control Tower です。AWS のセキュリティサービス群にベストプラクティスに則った設定を投入し、統制を利かせたマルチアカウント環境をランディングゾーンと呼びます。

ただし、注意していただきたいのは、AWS Control Tower はあくまでマルチアカウント環境のベースラインを提供するものである、という点です。もちろん AWS Control Tower が構築する環境だけでも、ベストプラクティスに則っているため十分な場合もあります。しかしながら、お客様固有のガバナンスや要件等を、AWS Control Tower が構築した下地の上に構築していくことで、よりお客様に最適化されたマルチアカウント環境を構築することができるようになるのです。

そこで利用できるソリューションの 1 つが「AWS Control Tower のカスタマイズ」です。

AWS Control Towerのカスタマイズの概要

本ソリューションは AWS Control Tower を既に有効化していることを前提としています。

AWS Control Tower のセットアップの方法は、「スタートアップにおけるマルチアカウントの考え方と AWS Control Tower のすゝめ」をご参照ください。

さて、ここから本ソリューションの紹介となりますが、「AWS Control Tower のカスタマイズ」を利用することで、マルチアカウント環境全体に渡って、 CloudFormation スタックセットや AWS Organizations の SCP を展開することが可能となります。同じリソースの展開や SCP の適用などを各アカウントごとに実施する手間を減らし、運用コストを削減できます。

また、CloudFormation テンプレートが提供されているため、以上の仕組みを簡単にデプロイすることが可能です。そのため、お客様は適用したい CloudFormation テンプレートや SCP を記述した JSON ファイルを準備するだけで既存のアカウント、および新規で発行されるアカウントに対して統制を効かせることが可能です。

本ソリューションでは、 Control Tower からアカウントを発行したときや AWS CodeCommit か Amazon S3 に保存した CloudFormation テンプレート/ SCP が更新されたときに、自動で CloudFormation スタックセットや SCP がマルチアカウント環境に展開されます。

使用している AWS サービスは？

本ソリューションは、主に新規アカウントが発行された時にカスタマイズを適用するための仕組みである「AWS Control Tower ライフサイクルイベントワークフロー」と、 CloudFormation テンプレートや SCP の内容を検証し、実際のアカウントにデプロイする「AWS CodePipeline ワークフロー」で構成されています。使用している AWS サービスはすべてサーバーレスのサービスであるため、本ソリューションを利用することによるインフラストラクチャの追加の管理は不要です。

AWS Control Tower ライフサイクルイベントワークフロー

AWS Control Tower お客様が構築している既存の AWS Control Tower ランディングゾーンです。
Amazon EventBridge AWS Control Tower 上の新規アカウント発行を Amazon EventBridge イベントルールが検出し、イベントを Amazon SQS FIFO キューに渡します。
Amazon Simple Queue Service 新規アカウントの発行イベントをキュー上に保持します。
AWS Lambda SQS のメッセージによりトリガーされて、後述する AWS CodePipeline ワークフローを実行します。

AWS CodePipeline ワークフロー

AWS CodePipeline ソースの更新に基づく検証およびデプロイのパイプラインを構築します。
AWS CodeBuild 設定した CloudFormation テンプレートまたは SCP の内容を検証します。
AWS Step Functions 設定した内容のうち CloudFormation テンプレートは CloudFormation に、SCP は Organizations に受け渡します。
AWS CloudFormation CloudFormation テンプレートからスタックセットを生成し、マニフェストファイルで指定したアカウントまたは OU のリストに対してデプロイします。
AWS Organizations SCP を作成、対象アカウントまたは対象 OU に対して適用します。

また、お客様が適用したい CloudFormation テンプレートや SCP の格納先として、Amazon S3 または AWS CodeCommit を利用可能です。

Amazon S3 デフォルトの格納先である、フルマネージドなストレージサービスです。
AWS CodeCommit AWS が提供するフルマネージドな Git ベースのリポジトリです。ソースの格納先として選択可能です。

デプロイ方法 / 設定方法

本記事はソリューションの v2.4.0 (2022/8/1 時点での最新版) を使用しております。

AWS CloudFormation スタックの作成

それでは、AWS ソリューションのデプロイ方法を見ていきましょう！

「AWS Control Tower のカスタマイズ」は、AWS Control Tower のランディングゾーンの構築先であるアカウント / リージョンで起動してください。つまり、本ソリューションは AWS Control Tower の管理アカウントのホームリージョンにデプロイする必要があります。

本ソリューションにて使用する CloudFormation テンプレートを実行するために、「AWS Control Tower のカスタマイズ」の実装ガイドにアクセスします。

GitHub から CloudFormation テンプレートをダウンロードします。その後、既存の AWS Control Tower の管理アカウントにログインし、AWS Control Tower ホームリージョンであることを確認して AWS CloudFormation にアクセスします。

「スタックの作成」をクリックします。

クリックすると拡大します

「スタックの作成」画面では、「テンプレートの指定」セクションで「テンプレートファイルのアップロード」を選択し、「ファイルの選択」から先ほどダウンロードしたテンプレートファイルを選択します。

「次へ」をクリックします。

クリックすると拡大します

「スタックの名前」に任意の名前 (例 : CfCT) を入力します。

クリックすると拡大します

CloudFormation パラメータの説明

次に、CloudFormation のパラメータを設定します。特に注意すべきパラメータは、AWS CodePipeline Source です。デフォルトではマルチアカウント環境に展開したいファイルのソースが Amazon S3 となっておりますが、ソースに既存の CodeCommit リポジトリを利用したい場合は、こちらのパラメータを変更し、他のパラメータで Git リポジトリの名前や Git ブランチ名を指定します。

その他、各パラメータの詳細はこちらの表をご確認ください。

パイプラインの設定

パラメータ デフォルト 説明
Pipeline Approval Stage No パイプライン設定をデフォルトの自動承認ステージから手動承認ステージに変更するかどうかを選択します。
Pipeline Approval Email Address オプション入力 承認通知用の電子メールアドレスを、Pipeline Approval Stage が Yes の場合に入力します。
AWS CodePipeline Source Amazon S3 AWS CodePipeline のソースを、Amazon S3 または AWS CodeCommit のいずれかから選択します。

AWS CodeCommit のセットアップ

パラメータ デフォルト 説明
Existing CodeCommit Repository? No AWS CodePipeline Source で AWS CodeCommit を選択した場合、既存の CodeCommit Git リポジトリの使用するかを選択します。
CodeCommit Repository Name custom-control-tower-configuration AWS CodePipeline Source で AWS CodeCommit を選択した場合、Git リポジトリの名前を指定します。
CodeCommit Branch Name main AWS CodePipeline Sourceで AWS CodeCommit を選択した場合、Git ブランチ名を指定します。 

AWS CloudFormation StackSets の設定

パラメータ デフォルト 説明
Region Concurrency Type PARALLEL リージョンで StackSets オペレーションをデプロイする同時実行タイプを PARALLEL, SEQUENTIAL から選択します。
Max Concurrent Percentage 100 このオペレーションを一度に実行するアカウントの最大の割合を指定します。
Failure Tolerance Percentage 10 AWS CloudFormation がリージョンでのオペレーションを停止するまでに、各リージョンでこのスタックオペレーションの失敗を許容するアカウントの割合を指定します。

本記事では、デフォルトの設定のまま進めていきます。「スタックオプションの設定」、「詳細オプション」は変更せずに、「次へ」を選択します。「レビュー CfCT 」で、CloudFormation のパラメータが指定した値で設定されていることを確認します。

クリックすると拡大します

レビューを下へスクロールし、「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを入れ、「スタックの作成」を選択します。

クリックすると拡大します

スタックの作成が成功したことを確認します。作成完了までに 5 分程度かかります。

クリックすると拡大します

カスタムパッケージを作成する

カスタムパッケージのソースとなる S3 の確認と準備

本記事では、デフォルトの設定である Amazon S3 をソースとして進めていきます。スタックの作成が完了すると、custom-control-tower-configuration-＜account-ID＞-＜region＞ という名前の S3 バケットが生成されています。その S3 バケットの中に、_custom-control-tower-configuration.zip という名前の初期設定ファイルが配置されています。

クリックすると拡大します

この初期設定ファイルをカスタマイズし、変更を圧縮してから custom-control-tower-configuration.zip という名前を付けて同じ S3 バケットにアップロードすることで、カスタマイズ内容をマルチアカウント環境にデプロイすることができます。初期設定ファイルの名前は先頭がアンダーバー（ _ ）になっているため、正式にデプロイするためにはこのアンダーバーを消す必要があるという点に注意が必要です。

早速、この zip ファイルにアクセスしてカスタマイズを実行していきたいのですが、実はこの zip ファイルは初期状態だと AWS KMS のキーによって保護されており、アクセスすることができません。

そのため、マネジメントコンソール上でAWS KMS に移動して、必要なロールを付与しましょう (この操作は、Amazon S3 をソースとして設定した場合にのみ必要です) 。

AWS KMS のコンソールに移動したら、「カスタマー管理型のキー」をクリックします。

クリックすると拡大します

[CustomControlTowerKMSKey] というキーが生成されているため、押下します。

クリックすると拡大します

「キーポリシー」タブを選択し、「編集」を選択します。

クリックすると拡大します

コード内の [Allow Use of the key] セクションを開き、次のいずれかのアクセス許可を追加します。

  • 管理者ロールを追加する場合：arn:aws:iam::＜account-ID＞:role/＜administrator-role＞
  • ユーザを追加する場合： arn:aws:iam::＜account-ID＞:user/＜username＞

「変更を保存」をクリックします。

これで、先ほどの S3 バケット上の初期設定ファイルにアクセスできるようになります。

設定ファイルの書き方

初期設定ファイルをダウンロードし、解凍すると example-configuration フォルダと manifest.yaml ファイルを確認することができます。この中でも、example-configuration フォルダ内にある manifest.yaml ファイルが書き方の参考になります。このファイルと以下の表を参考にしながら、カスタマイズを設定してみましょう。

各設定項目の詳細は以下の通りです。

region AWS Control Tower 管理アカウントのホームリージョンを指定します。(必須)
version 値はデフォルトのままで問題ありません。(必須)
resources 以下に設定を記述していきます。(必須)
  name 任意の名前を設定します。(必須)
  description 設定の説明を書くことができます。
  resource_file 設定したい CloudFormation テンプレートまたは JSON ファイル (SCP の場合) の場所を指定します。(必須)
  parameter_file CloudFormation スタック展開時に何らかのパラメータを用いたい場合に、JSON ファイルの場所を指定します。
  parameters parameter_key と parameter_value を指定してパラメータを設定可能です。
    parameter_key パラメータの key を設定します。
    parameter_value パラメータの value を設定します。
  deploy_method stack_set (CloudFormation テンプレートの場合) または scp (SCP の場合) を指定します。(必須)
  deployment_targets 以下にカスタマイズのデプロイ先を指定します。(必須)
    accounts デプロイ先のアカウントを指定します。
    organizational_units デプロイ先の OU を指定します。
  export_outputs SSM パラメータキーを指定して、テンプレート出力を SSM パラメータストアに格納できます。
    name SSM パラメータストアキーの name 文字列を指定します。
    value パラメータの value 文字列を指定します。
  regions CloudFormation スタックを展開するリージョンを指定します。

以上を参考に、要件にあったカスタマイズをマルチアカウント環境に適用しましょう !

実際に作成してみる

今回は、以下のような manifest.yaml ファイルと、適用するSCP を定義した block-s3-public.json ファイル、および展開したいリソースを定義した CloudFormation テンプレートである access_keys_rotated.template ファイルを使って検証します。

ここでは AWS Control Tower 管理アカウントのホームリージョンが東京リージョン (ap-northeast-1) であると仮定しておりますが、この部分はお客様の状況に合わせて適宜変更してください。

manifest.yaml

---
region: ap-northeast-1
version: 2021-03-15

resources:
  - name: block-s3-public-access
    description: To S3 buckets to have public access
    resource_file: policies/block-s3-public.json
    deploy_method: scp
    deployment_targets:
      organizational_units:
        - Security

  - name: rotate-access-keys-guardrail
    resource_file: template/access_keys_rotated.template
    parameters:
    - parameter_key: maxAccessKeyAge
      parameter_value: '24'
    deploy_method: stack_set
    deployment_targets:
      organizational_units:
        - Security
        - Sandbox
    regions:
    - ap-northeast-1

この manifest.yaml ファイルでは、2 つのカスタマイズを適用しています。

1 つ目は block-s3-public.json ファイルを参照しており、Security OU 配下のアカウントに対して、Amazon S3 のブロックパブリックアクセス設定の変更をできないようにする SCP を適用しています。

2 つ目は access_keys_rotated.template ファイルを参照しており、Security OU および Sandbox OU 配下のアカウントに対して、アクセスキーのローテーションを指定日数以上行っていない場合に検知する Amazon Config ルールを適用するテンプレートを展開しています。

実際に適用する block-s3-public.json ファイルと access_keys_rotated.template ファイルは以下の通りです。

block-s3-public.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GuardPutAccountPublicAccessBlock",
            "Effect": "Deny",
            "Action": "s3:PutAccountPublicAccessBlock",
            "Resource": "arn:aws:s3:::*"
        }
    ]
}

access_keys_rotated.template

---
AWSTemplateFormatVersion: '2010-09-09'
Description: Checks whether the active access keys are rotated within the number of days specified in maxAccessKeyAge.
Parameters:
  maxAccessKeyAge:
    Type: 'String'
    Description: 'Maximum number of days within which the access keys must be rotated. The default value is 90 days.'

Resources:
  CustomConfigRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: ACCESS_KEYS_ROTATED
      Description: Custom Config Rule - Checks whether the active access keys are rotated within the number of days specified in maxAccessKeyAge 
      InputParameters:
        maxAccessKeyAge : !Ref maxAccessKeyAge
      Source:
        Owner: AWS
        SourceIdentifier: ACCESS_KEYS_ROTATED
      Scope:
        ComplianceResourceTypes: []
右のようなディレクトリ構造であることを確認して、これらを圧縮し custom-control-tower-configuration.zip という名前で先ほどの S3 バケットへアップロードします。

クリックすると拡大します

カスタマイズ結果を実際に確認する

アップロードが完了したら、実際にカスタマイズが適用されたか確認してみましょう！まずは、実際に適用が成功したかどうか、失敗した場合はどういったエラーが出ているのかを AWS CodePipeline のコンソールで確認できます。

約 10 分ほどで完了が確認できました。

クリックすると拡大します

まずは、展開した SCP が反映されているか、AWS Organizations のコンソールに移動して確認します。

クリックすると拡大します

詳細をクリックすると、指定した OU (Security) に展開されていることが確認できました。

クリックすると拡大します

続いて、指定したアカウントにログインして、CloudFormation テンプレートで設定した AWS Config のルールが適用されているかを確認します。

クリックすると拡大します

実際に指定した通りに適用されていることが確認できました。最後に、Control Tower から新規アカウントを払い出した時、および設定ファイルの更新時に設定内容が反映されることを確認します。

まず AWS Control Tower のコンソールにアクセスし、 Account Factory から新規アカウントを作成しましょう。

クリックすると拡大します

作成したアカウントにログインすると、既に CloudFormation テンプレートで設定した AWS Config のルールが適用されていることが確認できました。

クリックすると拡大します

また、先ほど作成した manifest.yaml ファイルを以下のように更新し、先ほどと同様の手順で圧縮したファイルを S3 にアップロードしてみます。

---
region: ap-northeast-1
version: 2021-03-15

resources:
  - name: block-s3-public-access
    description: To S3 buckets to have public access
    resource_file: policies/block-s3-public.json
    deploy_method: scp
    #Apply to the following OU(s)
    deployment_targets:
      organizational_units: #array of strings
        - Security

  - name: rotate-access-keys-guardrail
    resource_file: template/access_keys_rotated.template
    parameters:
    - parameter_key: maxAccessKeyAge
      parameter_value: '30' *#値を変更 (24 → 30)*
    deploy_method: stack_set
    deployment_targets:
      organizational_units:
        - Security
    regions:
    - ap-northeast-1

約 10 分ほど待つと自動で更新内容が適用されていることを確認できました。

クリックすると拡大します

リソースの削除方法

SCP の削除

AWS Organizations のコンソールに移動し、設定した SCP を削除します。

 

StackSets の削除

AWS Control Tower のマネジメントアカウントにログインし、展開した StackSets を削除します。

 

ソリューションスタックの削除

カスタマイズソリューション自体を削除します。CloudFormation から CustomizationsForCTSolution のスタックを削除してください。ただし、展開済みの S3 や CodeCommmit はスタックを削除しただけでは消えないので、不要であれば手動で削除してください。S3 はバージョニングが有効化されているため、旧バージョンのオブジェクトまで全て削除してからバケットを削除するように注意しましょう。

 

対象のS3バケット

  • custom-control-tower-configuration-{アカウントID}-{リージョン名}
  • customizationsforctsolut-customcontroltowerpipeli-xxxxxxxxxxxx
  • customizationsforctsolut-customcontroltowers3acce-xxxxxxxxxx

 

対象のリポジトリ名 (CodeCommit の場合)

  • custom-control-tower-configuration

まとめ

今回の記事では「AWS Control Tower のカスタマイズ」ソリューションの概要や使い方を紹介しました。CloudFormation テンプレートを使ってセットアップし、適用したい CloudFormation テンプレートや SCP を設定するだけで、既存のアカウントおよび新規で発行されるアカウントに対して即座にデプロイできることをご理解いただけたのではないかと思います。

今回の記事では以下のようなポイントについてご紹介しました。

  • AWS Control Tower はあくまでマルチアカウント環境のベースを提供するものです。「AWS Control Tower のカスタマイズ」を利用することで、ベースの上にお客様独自の要件に従ったカスタマイズをすることが可能です。
  • 本ソリューションはお客様のマルチアカウント全体に渡って、カスタマイズされた統制を自動的に効かせることで、効率的にお客様独自のマルチアカウント環境を構成したい場合に最適なソリューションです。具体的には、複数のアカウントに、自動的に同一の CloudFormation スタックを展開する・ SCP を適用することで、マルチアカウント管理の運用負担を軽減させたいお客様や、効率よく独自の統制を効かせたいと考えているお客様に役立ちます。
  • GitHub 上に公開されている CloudFormation テンプレートを使ってセットアップすれば、Amazon S3 または AWS CodeCommit 上に設定ファイルをアップロードするだけで、簡単にマルチアカウントの統制が可能です。
  • 本ソリューションを展開すると、新規アカウント発行時・設定ファイル更新時に自動でカスタマイズが更新されます。


本ソリューションを活用される際には、AWS Control Tower ランディングゾーンのカスタマイズの実装ガイドもご一読頂ければと思います。

今後も AWS に関するブログ記事を書いていきたいと思いますので、是非また読んでもらえたら嬉しいです。また、他の AWS ソリューションの紹介記事もありますのでぜひご活用ください !

それでは、良いクラウドジャーニーを !

builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

メンバー特典を受け取る » 

筆者プロフィール

須藤 裕也
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト

2022 年 4 月に新卒として入社したソリューションアーキテクトです。好きな AWS サービスは Amazon Kinesis。趣味はありとあらゆるボードゲームをすることですが、その中でも最近、将棋にハマりました。

監修者プロフィール

山澤 良介
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト

テクニカルソリューションアーキテクトとして、業種業態を問わず様々なお客様を支援させて頂いています。
前職では主にネットワーク案件を担当していたため、好きなサービスは、AWS Direct Connect と AWS Transit Gateway です。
休日はスノーボードが大好きなので、シーズン中は毎週スキー場に行っているほか、オフシーズン中もオフトレ施設に行っています。

 ツイート »
 シェア »
 はてブ »

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する