https://blog.igeight.net/tags/aws/Recent content in Aws on igeight blogHugojaSun, 25 Oct 2026 00:00:00 +0900https://blog.igeight.net/posts/2026-10-25-cloudfront-custom-domain/Sun, 25 Oct 2026 00:00:00 +0900https://blog.igeight.net/posts/2026-10-25-cloudfront-custom-domain/<p>CloudFront のディストリビューションに、独自ドメイン(この記事では例として <code>blog.example.com</code>)を設定します。 ドメインの DNS が<strong>別の AWS アカウント</strong>にあり、こちらのアカウントでは証明書と CloudFront の設定だけを行って、DNS には「このレコードを登録してください」と依頼する場合を想定します。</p> <ol> <li>登場するものと、つながりの仕組み</li> <li>全体の流れ</li> <li>方法 A: CloudFormation</li> <li>方法 B: AWS CLI</li> <li>DNS に登録するレコード</li> <li>登録の順番</li> <li>A レコードや AAAA レコードではだめなのか</li> </ol> <h2 id="登場するものとつながりの仕組み">登場するものと、つながりの仕組み</h2> <p>独自ドメインの設定は、次の 3 つを<strong>同じドメイン名</strong>で結ぶ作業です。</p> <table> <thead> <tr> <th>登場するもの</th> <th>場所</th> <th>役割</th> </tr> </thead> <tbody> <tr> <td>DNS のレコード</td> <td>ドメインの DNS(別アカウント)</td> <td><code>blog.example.com</code> を CloudFront に向ける。証明書の所有確認にも使う</td> </tr> <tr> <td>ACM 証明書</td> <td><strong>us-east-1</strong></td> <td><code>blog.example.com</code> の HTTPS 通信の証明</td> </tr> <tr> <td>CloudFront の別名(Alias)</td> <td>CloudFront ディストリビューション</td> <td>「このドメイン名のアクセスを受け付ける」という宣言</td> </tr> </tbody> </table> <p>ブラウザが <code>https://blog.example.com/</code> を開いたとき、次のようにつながります。</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl"> ブラウザ </span></span><span class="line"><span class="cl"> │ ① blog.example.com の IP は? </span></span><span class="line"><span class="cl"> ▼ </span></span><span class="line"><span class="cl"> DNS ── CNAME: blog.example.com → xxxx.cloudfront.net ──┐ </span></span><span class="line"><span class="cl"> │ ② CloudFront の IP が返る </span></span><span class="line"><span class="cl"> ┌────────────────────────────────────────────────────┘ </span></span><span class="line"><span class="cl"> ▼ </span></span><span class="line"><span class="cl"> CloudFront(ディストリビューション xxxx) </span></span><span class="line"><span class="cl"> │ ③ TLS の接続で「blog.example.com」と名乗る(SNI) </span></span><span class="line"><span class="cl"> │ ④ 別名(Alias)に blog.example.com が入っているか? ← 入っていないと 403 </span></span><span class="line"><span class="cl"> │ ⑤ ACM 証明書(blog.example.com 用)を提示する </span></span><span class="line"><span class="cl"> ▼ </span></span><span class="line"><span class="cl"> ブラウザ: 証明書のドメイン名と、開いたドメイン名が一致 → HTTPS で表示 </span></span></code></pre></div><p>つまり、次の 3 つが同じ名前でそろって初めて繋がります。</p>https://blog.igeight.net/posts/2026-10-25-aws-iam-identity-center-sso/Sun, 25 Oct 2026 00:00:00 +0900https://blog.igeight.net/posts/2026-10-25-aws-iam-identity-center-sso/<p>AWS を複数のアカウントで運用していると、アカウントごとに IAM ユーザーとアクセスキーを作って <code>~/.aws/credentials</code> に貼る、という運用になりがちです。 <strong>IAM Identity Center</strong>(旧名 <strong>AWS SSO</strong>)を使うと、アクセスキーを持たずに、ブラウザでログインするだけで複数アカウントの一時的な認証情報を取得できます。</p> <p>この記事では、<code>~/.aws/config</code> に SSO の設定がある環境を例に、次の順で整理します。</p> <ol> <li>IAM Identity Center の登場人物と全体像</li> <li>権限セットとアカウント割り当ての関係</li> <li><code>aws sso login</code> の裏側(ログインの流れ)</li> <li><code>~/.aws/config</code> の読み方</li> <li>日々の使い方</li> <li>トークンの有効期限と、つまずきやすい点</li> </ol> <blockquote> <p>旧名の名残で、CLI のコマンドや設定項目は今でも <code>sso</code> という名前です(<code>aws sso login</code>、<code>sso_start_url</code> など)。 コマンドの出力例は説明用です。アカウント ID・ユーザー名・ハッシュ値は実際の値とは異なります。</p> </blockquote> <h2 id="iam-identity-center-とは">IAM Identity Center とは</h2> <p><strong>複数の AWS アカウントへのサインインを、1 か所で管理する仕組み</strong>です。 「誰が」「どのアカウントで」「何ができるか」を Identity Center に登録しておくと、ユーザーはそこにサインインするだけで、許可されたアカウントとロールを選べます。</p> <p>IAM ユーザー方式との違いは次のとおりです。</p> <table> <thead> <tr> <th>項目</th> <th>IAM ユーザー + アクセスキー</th> <th>IAM Identity Center</th> </tr> </thead> <tbody> <tr> <td>認証情報</td> <td>長期のアクセスキー(失効させない限り有効)</td> <td><strong>一時的な認証情報</strong>(1〜12 時間で失効)</td> </tr> <tr> <td>ユーザーの管理場所</td> <td>アカウントごとに IAM ユーザーを作る</td> <td>Identity Center で 1 回だけ作る</td> </tr> <tr> <td>MFA</td> <td>アカウントごとに設定</td> <td>サインイン時に 1 回</td> </tr> <tr> <td>退職・異動時</td> <td>全アカウントで削除する</td> <td>Identity Center で無効化すれば全アカウントに効く</td> </tr> <tr> <td>キーの漏えいリスク</td> <td>ファイルに平文で残る</td> <td>残るのは期限付きのトークンだけ</td> </tr> </tbody> </table> <h2 id="登場人物">登場人物</h2> <p>まず用語を押さえます。</p>https://blog.igeight.net/posts/2026-10-25-github-actions-oidc/Sun, 25 Oct 2026 00:00:00 +0900https://blog.igeight.net/posts/2026-10-25-github-actions-oidc/<p>GitHub Actions から AWS を操作したいとき、IAM ユーザーのアクセスキーを GitHub Secrets に入れていませんか。 <strong>OIDC</strong> を使うと、長期のキーを一切持たずに、実行のたびに短命の認証情報を受け取れます。</p> <p>この記事では、次の順で整理します。</p> <ol> <li>OIDC とは何か</li> <li>GitHub Actions と AWS はどうつながるのか</li> <li>自分の環境で試せる、最小限のテスト(所要時間は 15 分ほど)</li> <li>OIDC が使われるほかの場面</li> </ol> <h2 id="oidc-とは">OIDC とは</h2> <p><strong>OIDC(OpenID Connect)</strong> は、「ある主体が誰なのか」を、信頼できる第三者が <strong>署名付きの身分証</strong> で証明するための仕組みです。 身近な例は「Google でログイン」です。サイト側はあなたのパスワードを知らなくても、Google が「この人は確かに本人です」と署名付きで保証してくれるので、ログインを許可できます。</p> <p>ここで出てくる言葉は 4 つだけ覚えれば十分です。</p> <table> <thead> <tr> <th>言葉</th> <th>意味</th> <th>「Google でログイン」の場合</th> </tr> </thead> <tbody> <tr> <td>IdP(身分を証明する側)</td> <td>身分証を発行する</td> <td>Google</td> </tr> <tr> <td>利用する側</td> <td>IdP を信頼して、身分証を受け取る</td> <td>ログインしたいサイト</td> </tr> <tr> <td>トークン(JWT)</td> <td>署名付きの身分証。「誰が」「どこから」などの情報が入っている</td> <td>ログイン用のトークン</td> </tr> <tr> <td>クレーム</td> <td>トークンに入っている個々の情報</td> <td>メールアドレス、名前など</td> </tr> </tbody> </table> <p>GitHub Actions の OIDC は、これを <strong>人ではなくワークフロー(ジョブ)</strong> に当てはめたものです。 GitHub が IdP になり、「このジョブは、このリポジトリの、このブランチで動いています」という身分証をジョブごとに発行します。</p> <h2 id="github-actions-と-aws-の関係">GitHub Actions と AWS の関係</h2> <p>役割を整理すると、次のようになります。</p>