AWSは、複数の環境を運用する際に、マルチアカウントをベストプラクティスとしています。 そして、マルチアカウントにおいては、AWS OrganizationsでAWSアカウントを取りまとめた上、SCPを利用して権限移譲を行うことをベストプラクティスとしています。しかし強く推奨しているにも関わらずAWS Organizationsを利用できない場合、権限移譲を行おうとするとPermissions Boundaryを利用することになります。 SCPを利用する場合、使い方は2通りあります：許可リスト方式と拒否リスト方式です。こちらについて、公式ドキュメントに詳細が記載されています： https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html 文字の説明だけだと分かりにくいので、図で整理するとこちらになります： Permissions Boundaryも、複数のポリシーを1つのアイデンティティに紐づけできないものの、SCPと同様に記述がない場合暗黙的拒否となっているため、理論上、拒否リスト方式と許可リスト方式の2つの使い方があるはずです。では、実際はどうでしょうか？ 例えば、S3の「MYBUCKET」というバケットの内容に対して、読み取り（GET）のみ許可しようとします。SCPの拒否リスト方式、許可リスト方式、Permissions Boundaryの拒否リスト方式、許可リスト方式の合計4パターンでポリシーを作成してみます。 SCP：拒否リスト方式 SCPの拒否リスト方式を利用する場合、明示的許可ポリシーとして、「FullAWSAccess」というポリシーがデフォルトで作成されているため、追加で明示的拒否ポリシーを対象OU、もしくは対象アカウントにアタッチすればいいです。例えば以下のようなポリシーを作成し、アタッチします： SCP：許可リスト方式 SCPの許可リスト方式を利用するには、まずデフォルトの「FullAWSAccess」をいったんデタッチします。そして、許可したいアクセスを記載したポリシーを、対象OUもしくは対象アカウントにアタッチします。例えば： ※このポリシーは、「SCP：拒否リスト方式」での例と同一ではありません。拒否リストの例の場合、MYBUCKET以外のバケットへのアクセスや、EC2/RDSなど他のAWSサービスへのアクセスは可能になっています。しかし、この例では、すべてのS3バケットへの読み取りのみ可能です。S3以外のすべてのサービスへのアクセスはできません。 ※SCPの場合、EffectがAllowの場合、Resourceの値は「*」にのみ設定可能です。 Permissions Boundary：拒否リスト方式 Permissions Boundaryは、SCPと異なりプリンシパル毎に1つしか設定できないため、まずすべて許可した上、不要な部分を拒否する書き方になります。 Permissions Boundary：許可リスト方式 最後は、Permissions Boundaryの許可リスト方式です。 ざっくり見た感じだと、SCPでもPermissions Boundaryでも結果は一緒のようです。しかし、SCPとPermissions Boundaryは、一つ致命的な違いがあります。この違いを確認するために、対象S3バケットのバケットポリシーを追加します。そうすると再度アクセスを評価すると以下の表の結果になります。 S3バケットポリシーなし S3バケットポリシーあり SCP：拒否リスト方式 Get：〇 / Put：× Get：〇 / Put：× SCP：許可リスト方式 Get：〇 / Put：× Get：〇 / Put：× Permissions Boundary：拒否リスト方式 Get：〇 / Put：× Get：〇 / Put：× Permissions Boundary：許可リスト方式

今月のAWS re:Inforce 2023で、EC2 Instance Connect Endpoint（EICE）が正式にリリースされました。これにより、Public IPアドレスを持たないEC2インスタンスへの接続がより簡単になりました。 Public IPアドレスを持たないEC2インスタンスに接続する方法は、以下があります。 VPNや踏み台は手順が煩雑で余計にコストがかかるのですが、今までのSession Manager機能は今回のEICEと何が違うのでしょうか？どのように使い分けすれば良いでしょうか？ 仕組みの比較 まずは、それぞれの接続方式の仕組みを見てみましょう。 SSM Session Managerの場合、EC2インスタンスにインストールされているSSM Agentが、SSMのEndpointと接続を確立した後、リモート接続要求をユーザから受け付ける仕組みとなります。以下の①～③までは、シェルに接続する際の流れを示しており、ポートフォワーディングの場合は更に、④のようにSSM Agentがローカルに接続を確立する形となります（例えばSSHの場合、$SSH_CLIENTを確認すると127.0.0.1になります）。 SSM Endpointから、EC2インスタンスに接続しに行くことは絶対にないのが特徴です（つまり①の方向は必ずEC2インスタンスからSSM Endpointへとなります）。 一方、EICE経由の接続は非常に自然な流れとなります。EC2 Instance Connect Endpoint（EICE）は、踏み台のような役割を果たしています。SSHの場合、$SSH_CLIENTを確認すると、EICEのENIのPrivate IPアドレスであることが分かります（EICEは、インターフェース型のVPC Endpointと同様に、Private SubnetのIPアドレスを占有します）。 詳細な情報については、AWSの公式ドキュメントを参照していただくことをお勧めします。ここでは、これら2つの接続方法の比較についてご紹介します。 SSM Session Manager EICE トラフィックの方向 インスタンス→Endpoint Endpoint→インスタンス コスト 3種類のPrivateLink型のVPC Endpoint（ssm, ssmmessages, ec2messages）が必要なので、最低限でも毎月30 USD 無償。PrivateLinkを利用していない EC2に必要なエージェント SSM Agent ec2-instance-connect EC2に必要な権限 SSM関連の権限（AmazonSSMManagedInstanceCoreで最低限の権限を定義） 不要 EC2に開放が必要なインバウンドポート なし 22番（SSHの場合）、3389番（RDPの場合）など 可用性 複数サブネットでインターフェースを作成可能

VPCにおいて、プライベートサブネットからインターネットにアクセスするには、NATが必要になります。AWSから「NATゲートウェイ」というサービスが提供されており、数クリックで簡単にNATをデプロイすることができます。 しかし、どうしてもNATゲートウェイを利用できないケースがあります。また、NATゲートウェイの料金が高く無料利用枠がないことも、初心者からすると敷居が高い理由の一つでしょう。 そんなときに、EC2のインスタンスを利用して、NAT機能を実装した「NATインスタンス」を利用するといいです。NATインスタンスは、単なるEC2インスタンスなのでもちろん無料利用枠がありますし、ニーズに応じてインスタンスタイプを選択することで費用の節約が可能になります。また固定IP（Elastic IP）の必要性もないのでEIPの利用が禁止されている環境でもNATが使えるようになります。 最新のAmazon Linux、AL2023を使ってNATインスタンスを構築する方法はクラスメソッドさんのブログにもありますので、ここで割愛しますが、CloudFormationでIaC化しました。このCloudFormationテンプレートを利用すると、一発でNATインスタンスを構築することができます。 文末に掲載しているこのCloudFormationテンプレートの仕様、注意点は以下です。 ちなみに、AL2023は頻繁にアップデート版のAMIを出しています。以下のAWS CLIコマンドでAL2023のx86フルバージョンのイメージ一覧を確認できます。 CloudFormationテンプレートはこちらです。

最近、自宅に大量（15台程度）のCisco ISR 2911ルータが溜まっています。ヤフオクで出品しても3000円程度しか値段が付かないので、処分に困っています。昔、CiscoのASAを利用して自宅のネットワークからAmazon VPCにSite-to-Site VPNを構築したことはあるが、ISRルータでもできるのでは？と思い、やってみました。 まず準備作業として、ISRルータのIOSバージョンとライセンスを確認しておきます。バージョンは、よほど古くなければ問題ありません。 IPSec VPNを設定するには、「securityk9」というライセンスフィーチャーが必要です。securityk9がインストールされていない・有効化されていないISRルータではVPN関連のコマンドが利用できません。試しにsecurityk9が存在しない・有効化されていない場合のcryptoコマンドのヘルプを見てみると： 一方、securityk9が有効な場合だと、以下の結果になります： ちなみにsecurityk9ライセンスは、permanentもしくはRTU（RightToUse）のどちらの形態になります。RTUの場合は、以下のコマンドで有効化しておく必要があります： 設定を保存してから再起動するとライセンスが有効になります： これで準備作業は完了です。 システム構成 今回は検証のため最もシンプルな構成でシステムを作っていきます。AWS側はPrivate SubnetのみのVPCを作成します。自宅の環境では、ISR 2911ルータのg0/0ポートをLANケーブルでブロードバンドルータにつなげるだけです。VPNアクセスの際に、パケットは自分のPCからいったん2911に流れ、トンネリングされブロードバンドルータ、インターネット経由でAWSのVGWに到着し、VPC内のEC2インスタンスに転送されます。 1. ISRルータのルーティング設定 ISRルータでは、まずインターフェースのIPアドレスと、インターネットにアクセスするためのスタティックルートを設定します。VPN接続においてBGPのルーティング設定も必要ですが、これは後ほどAWSから提供されるコマンドに含まれているのでこの段階では設定しません。 2. VPCでCGWとVGWを作成 CGW（Cutomer Gateway）とは、Amazon VPCにおいてユーザ側デバイス（今回の場合は私の自宅にあるCisco ISR 2911）を表しているエンティティです。一方、VGW（Virtual Private Gateway）は、IGW（Internet Gateway）と同様にVPCにアタッチするエンティティです。VGWとCGWを作成してから、VGWとCGWとの間に、「Site-to-Site VPN」という接続を設定するという流れになります。 では、まずCGWを作成していきます。CGWの作成に必要な情報は1つだけです。自宅のブロードバンドルーターのインターネット側のIPアドレス、つまりグローバルIPです。ちなみに自宅のグローバルIPを確認するには、AWSから提供されているURL「http://checkip.amazonaws.com/」が便利です。 ここで注意してほしいのは、1個のIPアドレスにつき1つのCGWしか作成できません。同じIPアドレスで新しいCGWを作成しようとすると、同じIPアドレスの古いCGWが上書きされます。 続けてVGWを作成します。VGWとVPCとの関係は、1対1です。つまり1つのVGWは複数のVPCにアタッチできません。1つのVPCに複数のVGWをアタッチすることもできません。VGW作成には特にIPアドレスなどを情報を必要としません。Amazon側のASNはデフォルトで64512になりますが、既存環境のAS番号と重複していない限り変更する必要はありません。 3. Site-to-Site VPN接続を作成 CGWとVGWを作成したら、Site-to-Site VPN接続を作成します。先ほど作成していたCGWとVGWを指定する以外のオプションは、デフォルトのままで構いません（セキュリティ向上のために通せるIPアドレス範囲を絞ることができますが、今回はいったん制限なしでいきます）。 また、ルーティングオプションについては、ISR 2911がBGPをサポートしているため、「動的」を選択しています。BGPをサポートしない機種の場合、「静的」を選択したうえ手動でルーティングを設定する必要があります。 4. NAT Traversalを考慮したConfig修正 VPNを作成した直後、下記のようにトンネルのステータスが「Down」になっており接続できていない状態です。これを解消するには、ISR 2911側でVPNの設定を投入する必要があります。 作成したVPN接続の画面で、「設定をダウンロードする」ボタンをクリックするとサンプルの設定ファイル（Config）をダウンロードできます。CiscoのISRシリーズを選択してダウンロードします。 ここでダウンロードしたConfigは、そのまま2911に投入してはいけません。なぜかというと、2911のインターフェースに設定されているIPアドレスが、AWSから認識しているIPアドレスが異なっています。つまり、2911とAWSとの間にNATが存在します。そのため、このConfigにある自宅のグローバルIPを、すべて2911の外部向けIP（この例では192.168.1.241）に置換する必要があります。CiscoのISRルータは、自動的にNAT Traversalに対応しているので、特に追加の設定は不要です。 実際に置換を行った個所は、それぞれのトンネル設定に3カ所で合計6カ所になります。 また、IOSのバージョンによるものかもしれませんが、下記コマンドが受け付けられなかったので、少し変更しました。 上記の変更をしたら、そのまま2911に投入します。投入後、数十秒待つと両方のトンネルが「Up」ステータスに変わります。 5. VPC側のルーティング設定 最後にVPC側で、自宅へのルートを追加します。 6.

クラウド上のWindowsサーバにリモート接続するには、RDP（リモートデスクトップ）を利用することが多いでしょう。AWSのEC2においても、Windowsのインスタンスを作成した場合デフォルトでTCPの3389が空いているセキュリティグループが作成され、RDPによる接続ができるようになっています。 Server CoreのWindowsサーバに対してもRDPで接続することはできますが、せっかくのServer Coreなので、CLIで接続したいものです。特に、XのインストールしていないLinuxからWindowsに接続するには、CLI以外の方法はありません。 CLIで接続するには、主に4つの方法があります。 1. WinRS / WinRM WinRSは、WinRM（Windows Remote Management）のコマンドラインツールでWindowsにデフォルトでインストールされていますが、Windows環境でしか利用できません。LinuxやmacOS、WSLでは利用できません。 WinRMは、HTTPとHTTPSをサポートしており、それぞれTCPポートの5985と5986を使用します。しかし、HTTPS利用の場合サーバ側に証明書を導入する必要があり手間がかかってしまいます。HTTPでの通信であっても通信の中身をきちんと暗号化してくれます（ドメイン環境ではKerberos/AES-256、それ以外はNTLM/RC4で）ので、通常HTTPを選択しても問題ありません。Windows Server 2022でも、デフォルトでHTTPのみ有効になっています。しかし、セキュリティにシビアな環境での利用はHTTPSを選択したほうが無難でしょう。 一方、HTTP利用の場合クライアント側で明示的にサーバのIPアドレスを信頼ホスト（TrustedHost）に追加する必要があります。ここではHTTPで接続する場合の手順を説明します。 AWS側の設定 AWSでは、インスタンスに対して「WinRM-HTTP（5985番ポート）」もしくは「WinRM-HTTPS（5986番ポート）」を開放します。 サーバ側の設定 Windows ServerはデフォルトでWinRMのサービスが立ち上がっており有効になっています。また、ファイアウォールのPrivateとDomainプロファイルにおいて、下記のようにWinRMのポートが開放済みの状態です。そのため、ドメイン環境であればサーバに一度もログインしなくてもリモート接続は可能です。 しかしPublicプロファイルではこのポートが開放されていないため、インターネット越しなどドメイン以外の環境の場合、下記コマンドでポートを開放しておく必要があります。いったんRDPでログインしてから、コマンドを実行します。 クライアント側の設定 HTTPの場合クライアント側の信頼ホスト（TrustedHost）を設定する必要がありますが、残念ながら設定用のコマンドはWinRMのサービスが起動しないとエラーを吐きます。クライアント側の設定をするのにサービスを起動しなければならないのは非常におかしいので、マイクロソフトが別の方法を用意してくれています：直接レジストリをいじる方法です。 ただし、レジストリをいじることは、特にエンタープライズ環境では避けるべきなので、ここでコマンドで設定する方法を説明します。「winrm quickconfig」コマンドでサービスを起動してから、「winrm set」コマンドで信頼ホスト（TrustedHost）を追加する内容です。コマンドにある「x.x.x.x」は、WindowsインスタンスのパブリックIPアドレスです。 接続してみる 以下のコマンドでリモート接続します。 このように、コマンドを実行できるようになります。またPowershellも起動できcmdletを実行できます。 2. Powershell Remoting over WinRM Powershell Remotingには、2つの方式があります。1つはWinRMベースでもう1つはSSHベースです。 WinRMベースのPowershell Remotingは、Windows OSからの接続しかサポートしません（WinRMがWindows OS上にしか存在しないため）。一方、SSHベースのPowershell Remotingはクロスプラットフォームであり、WindowsからLinux、LinuxからWindowsなどをサポートしています。しかし、SSHベースはWindows Powershellをサポートしておらず、Powershell（つまりPowershell Core）を動作要件としているため、サーバ側にのPowershellのインストールが必要です（名前がややこしいですが、Windows PoweshellとPowershellは別物です）。 WinRMベースのPowershell Remotingは、前述のWinRMの仕組みをそのまま流用しているため、サーバ側・クライアント側とも同様に事前設定が必要です。また、EC2側のポート開放（5985もしくは5986）も忘れずにしておきましょう。接続する際に、winrsコマンドの代わりに、Powershellで「Enter-PSSession」を利用します。 ちなみにHTTPSで接続する場合は以下のコマンドを利用します。 3. SSH 最新のWindowsサーバのリモートCLI管理は、SSHが最も簡単な方法です。Windows Server 2019以降、またWindows 10以降のWindows OSは、標準でOpenSSHをサポートしています。デフォルトでSSHサーバがインストールされているわけではありませんが、コマンド1つでインストールと構成ができるので複雑な設定は要りません。

4月は新生活がスタートするシーズンです。なので、今まで他のところで取得し管理していたドメインを、AWSのRoute 53に移管することになりました。 以前から、ドメイン移管についてとても面倒というイメージを持っていましたが、実際にやってみたところ手順はいたって簡単で、スムーズにできました。 移管元レジストラでの作業 移管元のレジストラで行う作業は、レジストラによって異なると思います。今回は、GMOのバリュードメインからの移管でした。バリュードメインの場合、以下の3つの作業が必要でした。 Route 53での作業 Route 53では、ドメインの一覧画面で「移管（イン）」を選択すると、単一のドメインか複数のドメインかが選択できます。今回は1つだけなので単一のドメインを選択します。 ドメイン名を入力し、チェックボタンをクリックすると、移管可否を確認してくれます。ここで赤の「移管不可」が表示された場合、ドメインロックがかかっている可能性が高いですので、移管元を再度確認してみましょう。 認証コードを入力します。 料金を確認し、連絡先情報を記入すれば完了です。 移管をリクエストしたものは、リクエストの一覧に表示されます。相変わらず日本語訳がおかしいのは残念です。ここの「でドメインを移管」は、実は「Transfer domain in」の訳で、正確には「ドメインを転入」です。 メールでの承認 バリュードメインの場合、しばらくすると移管元のレジストラからメールが届きます。ここで承認をクリックすると、移管は完了です。 移管後のPublic Hosted Zoneの設定 今回は、移管元のバリュードメインでは、他社へ移管後でもバリュードメインのDNSサーバが利用できるということだったので、先に移管を行ってからDNSサーバの切り替えをしたのですが、本来なら先にDNSサーバを切り替えたほうが安心でしょう。 バリュードメインから移管されてきた直後は、ネームサーバ（DNSサーバ）はバリュードメインのものになっていました。 DNSサーバを切り替えるには、まずRoute 53で対象ドメインのPublic Hosted Zoneを作成します。作成すると、ネームサーバの一覧が表示されるのでこちらをドメインに設定します。 また、Route 53に移管してきたドメインが操作ミスやいたずらによって許可なく転出されることを防ぐために、移管ロックを必ずかけておきましょう。