AWS(Amazon Linux) Linux

この記事のポイント

・Amazon Data FirehoseはAZ障害を意識せず使える設計（マルチAZ組み込み）
・バッファリング間隔（60秒～15分）の設定がコストと遅延のトレードオフになる
・S3プレフィックスをHive形式に設計するとAthenaのスキャンコストを削減できる
・CloudWatch Logsサブスクリプションフィルターとの組み合わせが最もシンプルな構成

この記事のポイント

・RDS ProxyはLambdaの同時起動による接続数爆発をコネクションプールで解消する
・プライベートサブネットにマルチAZ配置し、RDSフェイルオーバー時の切断を10秒以内に短縮できる
・Secrets ManagerでDB認証情報を管理し、IAMロールでProxyに参照権限を付与する
・LambdaはProxyエンドポイントへの接続文字列変更だけで利用でき、コード改修は不要

この記事のポイント

・ALBの加重ルーティングはターゲットグループに0～999の重みを付けて実現する
・aws elbv2 modify-ruleで重みをリアルタイムに変更できるため再デプロイ不要
・マルチAZ環境ではCross-Zone Load Balancingの動作確認と各AZへの均等登録が重要
・問題発生時は重みを0/100に戻すだけで即座にロールバックが完了する

この記事のポイント

・VPCの/56 IPv6 CIDRはAmazon提供の無料ブロック（GUAアドレス）を使う
・パブリックサブネットはIGW、プライベートサブネットはEgress-Only IGWでIPv6経路を分ける
・セキュリティグループのIPv4ルール（0.0.0.0/0）はIPv6に自動適用されない——別途::/0の追加が必須
・EC2へのIPv6自動割り当てはサブネット側でassign-ipv6-address-on-creationを有効化する

この記事のポイント

・Patch ManagerはSSM AgentとIAMロールがあれば追加インストール不要で動く
・パッチグループはEC2タグで環境（本番/検証）を分離する設計が基本
・メンテナンスウィンドウでスキャンとインストールを別タスクに分けると安全
・コンプライアンス確認でパッチ未適用インスタンスを一覧で把握できる

この記事のポイント

・eb init → eb create の2ステップで環境が作成できる
・ローリングデプロイは .ebextensions/deploy.config の DeploymentPolicy で制御する
・マルチAZ構成は Availability Zones と MinSize を組み合わせて設計する
・VPC統合は eb create --vpc.id / --vpc.ec2subnets / --vpc.elbsubnets で指定する

この記事のポイント

・VPCのCIDRブロックは作成後に変更不可。最初の設計が全てを決める
・複数VPCを計画するなら10.x.0.0/16形式の連番プランニングが基本
・マルチAZの3層サブネット設計は/24 x 9サブネットが現場の標準パターン
・セカンダリCIDRで既存VPCを無停止拡張でき、最大5ブロックまで追加できる

この記事のポイント

・ステートマシンはTask・Parallel・Wait・Choiceなど8種のStateで構成される
・直列連鎖は "Next" で次Stateを指定し、"End:true" で終端を定義する
・Parallel Stateで複数Lambdaを並列実行しWall Clockを短縮できる
・Retry/Catchでエラーハンドリングを宣言的に定義、コード修正不要

この記事のポイント

・Network FirewallはFirewall Subnetを作り、ルートテーブルを変更してインライン配置する
・マルチAZ構成ではAZごとに1つのFirewall Endpointが必要（Traffic Asymmetry防止のため）
・ルールグループはステートレス（5-tuple）とステートフル（Suricata互換）の2層に分かれる
・ドメインリストルールでアウトバウンドのHTTPS通信をFQDN単位で許可リスト管理できる

この記事のポイント

・1スタックにすべて詰め込むとデプロイ遅延とBlast Radiusが拡大する
・VPC層・セキュリティ層・アプリ層の3層分割がスタック設計の基本型
・スタック間のリソース参照はStack Propsで型安全に渡す
・環境差分（AZ/CIDR）はcdk.jsonのContextに定義して--contextで上書き

この記事のポイント

・CloudFront前段WAF（スコープ: CLOUDFRONT）はus-east-1で作成する
・ALB前段WAF（スコープ: REGIONAL）はALBと同一リージョンで作成する
・マネージドルール追加後はCountモードで正規リクエストへの影響を確認する
・誤検知はRuleActionOverrideでルール単位に細かく調整できる

この記事のポイント

・aws ram create-resource-share でサブネットを参加アカウントに公開できる
・Organizations連携を有効にすると招待承諾が不要になり運用が簡単になる
・ルートテーブル・NACLはオーナー管理、セキュリティグループは参加側が設定する役割分担が基本
・AZ冗長のためマルチAZ分のサブネットをまとめて共有するのが実務上の鉄則

この記事のポイント

・Inspector v2はSSM Agent経由でEC2のCVEをエージェントレスでスキャンできる
・aws inspector2コマンドで有効化からスキャン結果取得まで操作できる
・CVSSスコアと「exploitability」の組み合わせで修正優先度を判断する
・SSMパッチマネージャーと組み合わせることで検出から修正まで自動化できる

この記事のポイント

・AWS KMSには「AWSマネージドキー」「CMK」「データキー」の3層構造がある
・CMKはキーポリシーとIAMポリシーの両方が揃って初めてアクセスできる
・EC2 EBSのデフォルト暗号化はアカウント・リージョン単位で一括有効化できる
・キーローテーションはCMKで年1回の自動ローテーションを必ず有効にする

この記事のポイント

・aws ec2 create-vpc-endpoint-service-configurationでエンドポイントサービスを作成する
・NLBをバックエンドにすることでマルチAZ冗長のプライベートサービスを実現できる
・コンシューマー側はInterface型エンドポイントを作成するだけでVPC間接続が可能
・VPCピアリングと異なりCIDRアドレスが重複していても接続できる

この記事のポイント

・VPC内でカスタムドメインを使うにはプライベートホストゾーンが必要
・enableDnsSupportとenableDnsHostnamesを両方ONにしないと解決されない
・マルチVPCや別アカウントのVPCにも追加の関連付けで対応できる
・オンプレミスとの双方向DNS解決はResolver Endpointで実現する

この記事のポイント

・HTTP API（V2）はREST APIより70%安く、aws apigatewayv2コマンドで一気に構築できる
・Lambdaプロキシ統合ではstatusCode+bodyを返す形式を守ることが最重要
・$defaultルートキーで全パスをLambdaにキャッチオールできる
・CognitoオーソライザーでJWT認証をLambda不要で設定できる
・スロットリングとアクセスログは本番公開前に必ず設定する

この記事のポイント

・aws secretsmanager コマンドでシークレットを作成・取得できる
・EC2にIAMロールを付与して認証情報を安全に参照する設計ができる
・RDSパスワードの自動ローテーションをLambdaなしで設定できる
・Secrets ManagerとSSM Parameter Storeの使い分け基準が判断できる

この記事のポイント

・MySQLレプリケーションはbinlogを介してソースからレプリカへ更新を自動同期する仕組み
・binlogポジション方式はFile名+位置で同期、GTID方式は一意IDで自動追跡する
・MySQL 8.4ではCHANGE MASTER TO等の旧構文が廃止。新コマンドへの対応が必須
・SHOW REPLICA STATUSでIO/SQLスレッド両方がYesなら正常動作している

この記事のポイント

・DynamoDBは設定不要でマルチAZ冗長化済み。スキーマレスでスケールが自動
・パーティションキーはカーディナリティが高いものを選ぶのが設計の基本
・グローバルテーブルで複数リージョンへの自動レプリケートが実現できる
・最初はオンデマンド課金で動かし、安定後にプロビジョンドへ移行するのが定石

この記事のポイント

・Auroraはクラスターボリュームを3AZ×6コピーで共有し単一障害に強い
・aws rds create-db-clusterでマルチAZクラスターを作成できる
・failover-db-clusterで手動フェイルオーバーをテストする
・Global Databaseでリージョン障害に備えRPO約1秒を設計できる

この記事のポイント

・ALBはL7（HTTP/HTTPS）、NLBはL4（TCP/UDP）で動作する
・パスベースルーティング・WAF連携が必要ならALB一択
・固定IP・低レイテンシ・DB/MQ接続ならNLBが適切
・マルチAZ設定はaws elbv2コマンドで複数サブネットを指定する

この記事のポイント

・ クラスター配置は低レイテンシ優先（HPC・ML向け）、スプレッドは最大限の物理分離
・ スプレッドはAZあたり最大7インスタンスのハードリミットに注意
・ パーティション配置はHadoop・Kafka向けで7パーティション/AZまで設定可能
・ Placement Groupは起動時のみ指定可能（既存の実行中インスタンスへの後付けは不可）

この記事のポイント

・AWSのEC2はハードウェアを「仮想マシン」として提供するクラウドサービス
・オンプレミスと最も大きく違うのは「責任共有モデル」とコスト構造
・amazon linuxはEC2向けに最適化されたLinuxディストリビューション
・AWSを使いこなすにはLinuxのファイル・プロセス・ネットワーク管理の基礎が必須

この記事のポイント

・EFSはNFSv4を使い、複数EC2から同時に読み書きできる共有ストレージ
・マウントターゲットを複数AZに配置することでAZ障害時も継続してアクセスできる
・aws efs create-file-systemで作成し、各AZのサブネットにマウントターゲットを設ける
・パフォーマンスモードはGeneral Purpose、スループットはElasticを最初に選ぶのが現実解

この記事のポイント

・EKSのマルチAZ設計はノードグループのAZを3つに分散させることが基本
・eksctlのClusterConfig YAMLでVPC・ノードグループの設定を一括定義できる
・プライベートサブネットにはEKS用タグ（kubernetes.io/role/internal-elb: 1）の設定が必須
・PodへのAWS権限はIRSA（IAM Roles for Service Accounts）で最小権限を実現する

この記事のポイント

・CloudFormationのテンプレートはResources（必須）・Parameters・Outputsの3セクションが基本
・VPC + マルチAZサブネット + ALBの冗長構成は1つのYAMLテンプレートで定義できる
・aws cloudformation deployコマンドで変更セットを確認してから安全に更新できる
・ドリフト検知（detect-stack-drift）でコンソールからの手動変更を検出してテンプレートとのズレを把握できる
・スタック削除時の誤消去はDeletionPolicyとTerminationProtectionで防ぐ

この記事のポイント

・AWS Client VPNで個々のデバイスからVPCへセキュアに接続できる
・相互TLS認証ではEasy-RSAで証明書を発行しACMに登録する
・スプリットトンネルを有効にするとVPC宛の通信のみVPN経由になる
・複数AZのサブネットに関連付けることで冗長性を確保できる

この記事のポイント

・CodePipeline・CodeBuild・CodeDeployの3役割を正しく理解して設計する
・buildspec.ymlとappspec.ymlがCI/CDパイプラインの動作を定義するコアファイル
・ECS Blue/Greenデプロイでゼロダウンタイムリリースと即座のロールバックを実現できる
・IAM権限ミスがパイプライン停止の最大原因、最小権限設計で事前に防ぐ

この記事のポイント

・AWS Direct Connectは専用物理回線でAWSに直結し帯域と遅延が安定する
・VIF 3種類（Private/Public/Transit）の使い分けとDX Gatewayの役割を押さえる
・本番環境はDX＋VPNのアクティブ・スタンバイ冗長構成が定石
・CLIのdescribe-*コマンドでBGP状態と接続状態をリアルタイムに確認できる

この記事のポイント

・Anycast IPで最近傍のAWS PoPからバックボーン経由でルーティングする
・アクセラレーター→リスナー→エンドポイントグループ→エンドポイントの4階層で構成する
・固定IPのままフェイルオーバーは約30秒で完了（DNSキャッシュに依存しない）
・Route 53フェイルオーバーより高速な切り替えが必要な場面に向く

この記事のポイント

・Site-to-Site VPNは1つのVPN接続に2本のIPsecトンネルを持ち、AWSが冗長性を提供する
・BGPを使えばトンネル障害時に自動で経路切り替えが起きる（静的ルーティングは手動対応が必要）
・CGW・VGW・VPN接続の3ステップをCLIで構成しルート伝播で経路をVPCに伝える
・VpwTelemetryのStatusとAcceptedRouteCountでトンネルとBGPの状態を最初に確認する

この記事のポイント

・aws ec2 create-flow-logsでVPC・サブネット・ENIの3レベルで有効化できる
・actionフィールドがREJECTの記録を絞り込むと不審アクセスを素早く特定できる
・S3送信はコストが低く長期保存向き、CloudWatch Logsはリアルタイム分析に強い
・traffic-type REJECTから始めて必要に応じてALLに拡張するのがコスト効率のよい設計

この記事のポイント

・NAT GatewayはパブリックサブネットにEIPと共に作成する
・プライベートサブネットのルートに0.0.0.0/0→NAT GWを追加する
・可用性確保のためAZごとに1台のNAT Gatewayを配置する
・S3はGateway型VPCエンドポイントで迂回するとコスト削減できる
・VPC Flow Logsを有効にするとNAT GW障害の切り分けが格段に速くなる

この記事のポイント

・ルートテーブルの0.0.0.0/0がIGWを向いているかで「パブリック」かが決まる
・プライベートのアウトバウンドはNATゲートウェイ（パブリックサブネット配置）で確保
・セキュリティグループはL3/4止まり——サブネット設計と組み合わせて多層防御を作る
・aws ec2 create-subnetとルートテーブル設定でCLIから段階的に構成できる

この記事のポイント

・NACLはサブネット単位のステートレスFW、SGはインスタンス単位のステートフルFW
・ステートレスのNACLはエフェメラルポートのアウトバウンド許可が必須
・「NACL=不審IP遮断」「SG=インスタンス間の通信制御」で役割を分担する
・SGはSG IDを参照したチェーン設計にすることで、IP変動やオートスケーリングに強くなる
・マルチAZ構成では同じ役割のサブネットに同じNACLを関連付けてルール不一致を防ぐ
・L7のドメイン・ペイロード検査が必要なときはNetwork Firewallを追加する
・Network Firewallのステートフルルールは5タプル・ドメインリスト・Suricata互換の3形式から選べる
・StatefulEngineOptionsはSTRICT_ORDERを指定してルール評価順を明示的に制御する
・複数VPC環境は検査VPC（Inspection VPC）パターンでFirewallをTransit Gateway経由で集中配置できる

この記事のポイント

・ACMはAWSが提供する無料SSL証明書マネージドサービスで、ALB・CloudFrontに適用できる
・Route 53のDNS検証でCNAMEレコードを追加すれば証明書の発行は最短数分で完了する
・ALBのHTTPS（443）リスナーにACM証明書をアタッチするだけでHTTPS化が完成する
・ACM証明書の有効期限は13ヶ月で、Route 53使用時は自動更新が有効になる

この記事のポイント

・Gateway型は無料でS3へのルートを自動追加する
・Interface型はオンプレ・他VPCからも到達できるが有料
・Gateway型への切替えでNATコストを大幅削減できる
・接続確認はaws s3 lsで即座にテストできる

この記事のポイント

・RTOは「何時間以内に復旧するか」、RPOは「どこまでのデータを戻せるか」を決める指標
・DR戦略はバックアップ&リストア・パイロットライト・ウォームスタンバイ・マルチサイトの4段階
・RTO/RPO目標が短いほどコストは指数関数的に上昇する
・まずRTO/RPO目標をビジネス側と合意してから戦略を選ぶ順序が正しい

この記事のポイント

・Well-Architected Frameworkは6つの柱でAWSアーキテクチャを総合評価する公式指針
・Well-Architected Toolで質問に答えるだけでHRIs（高リスク課題）を自動抽出できる
・改善の優先順位はリスクの大きさと対応コストのバランスで判断する
・フレームワークは一発チェックではなく四半期ごとのPDCAサイクルとして活用する

この記事のポイント

・GuardDutyは脅威検知エンジン、Security Hubはセキュリティ状態の一元集約管理
・GuardDutyはコンソール数クリックで有効化でき、S3・EKS・マルウェア保護も追加可能
・検出結果はEventBridge→SNS→Lambdaのパイプラインで自動通知・対応できる
・マルチアカウントはOrganizations委任管理者でGuardDutyとSecurity Hub両方を一元管理する

この記事のポイント

・SQSは1対1のキューイング、SNSは1対多のファンアウト配信
・SNS+SQSの組み合わせでメッセージの蓄積とファンアウトを両立できる
・VPCエンドポイントでSQS/SNS通信をAWSネットワーク内に閉じセキュリティを強化する
・FIFOトピックとFIFOキューは必ずセットで使う（混在不可）

この記事のポイント

・Lambda＋EventBridgeでEC2夜間自動停止をサーバーレスで実装できる
・Python boto3のタグフィルタで本番EC2への誤操作を防ぐ設計にする
・EventBridge cronはUTC基準（JSTから9時間引いた値）で設定する
・IAMはec2:StopInstances・CreateSnapshot・DescribeInstancesを最小限付与

この記事のポイント

・EBS=ブロックストレージ（EC2に直接アタッチ）、EFS=共有NFS、S3=オブジェクトストレージが3者の基本的な違い
・EC2のOSやDBにはEBS、複数インスタンスでファイル共有するならEFS、APIアクセスでよいならS3を選ぶのが基本判断軸
・コスト比は概算でS3＜EBS＜EFSの順。高機能になるほど割高になる
・AZをまたぐ冗長化要件はEFSとS3が自動対応。EBSは単一AZ内にとどまる

この記事のポイント

・CloudTrailはAPIコール全記録、ConfigはAWSリソースの設定状態変化を記録する
・2つを組み合わせて「変更の操作者」と「リソースの変化前後」を突き合わせた証跡が完成する
・証跡はマルチリージョン＋S3永続保存が前提。改ざん防止にはLogFileValidationを有効化する
・Config Rulesでコンプライアンス違反を自動検出し、修復アクションまで自動化できる

この記事のポイント

・AWS Backupでバックアッププランを1箇所で管理できる
・EC2・RDS・EFSをタグで一括割り当て可能
・バックアップボールトでリカバリポイントを統合管理
・復元テストを定期実施してRPO/RTOを検証することが重要

この記事のポイント

・Cost Explorerのレコメンデーション機能でSavings Plans購入額の目安がわかる
・Compute Savings Plansは1年・前払いなしで最大66%割引、新規にはこれを選ぶ
・スポットインスタンスは最大90%割引、中断2分前通知をメタデータAPIで検知できる
・Reserved InstancesよりSavings Plansのほうが柔軟で新規購入に向いている

この記事のポイント

・AWS OrganizationsはOU（組織単位）でアカウントを階層管理し、SCP（サービスコントロールポリシー）で全体統制する
・SCPはIAMポリシーの上位にある制御層で、AdministratorAccessでも突破できないガードレールを作れる
・OU設計は「本番/開発/セキュリティ/サンドボックス」の4層分離が実務の標準パターン
・Consolidated Billingで全アカウントのコストを一元集計し、RIの割引も組織全体で共有される

この記事のポイント

・AWS WAFはSGと異なりHTTPリクエストの中身（L7）を検査してブロック判定できる
・WebACLにマネージドルールを追加するだけでSQLi・XSS・Bot攻撃を即座にブロック可能
・レートベースルールで同一IPからの過剰アクセスを5分単位で自動遮断できる
・まずカウントモードで誤検知を確認し、段階的にBLOCKへ移行するのが安全な設計手順

この記事のポイント

・バージョニング有効化は put-bucket-versioning --status Enabled の1コマンド
・削除しても削除マーカーが残るため list-object-versions で復元できる
・ライフサイクルポリシーで古いバージョンをGlacierに移行してコストを削減
・CRRはバージョニングが前提条件。既存オブジェクトには自動適用されない点に注意

この記事のポイント

・aws ssm start-session でSSHなし・鍵なしでプライベートサブネットのEC2に接続できる
・IAMロール（AmazonSSMManagedInstanceCore）のアタッチが唯一の前提条件
・Run Commandでタグ指定した複数EC2へ同時コマンドを実行できる
・Parameter Storeは無料で設定値管理向け、Secrets Managerはパスワード自動ローテーションが必要な場合に使い分ける

この記事のポイント

・マルチAZ構成は --automatic-failover-enabled --multi-az-enabled の2オプションで作成する
・プライマリ障害時はリードレプリカが自動昇格（約1～2分）・アプリ側の設定変更は不要
・リーダーエンドポイントで読み取りをレプリカに分散し、レプリカ追加でスループットを線形拡張できる
・CloudWatch の ReplicationLag と CacheHitRate を常時監視して本番品質を担保する
・AUTHトークンはSecrets Managerに格納し、ハードコードを避けるのが現場の鉄則

この記事のポイント

・CloudWatch Agentがないとメモリ・ディスクは取得できない
・IAMポリシー2つをEC2ロールにアタッチするのが設定の前提
・put-metric-alarmでメモリ85%・ディスク80%のアラームを設定
・CloudWatch Logsへのログ集約とERRORフィルターで異常を検知

この記事のポイント

・FargateはサーバーレスでEC2管理が不要。本番用途では最初の選択肢になる
・タスク定義でCPU・メモリ・コンテナ定義・ログ設定を一元管理する
・ECSサービス＋ALBでマルチAZに分散配置してヘルスチェックを自動化する
・maximumPercent=200／minimumHealthyPercent=100でゼロダウンタイムデプロイを実現する
・Auto ScalingはCPU使用率70%をトリガーにするターゲットトラッキングが基本
・実行ロール（起動権限）とタスクロール（アプリ権限）を分離して最小権限を実現する
・デプロイ失敗時はcircuit breakerで自動ロールバックしサービス停止を防ぐ
・TerraformでIaC管理する場合はjsonencodeかテンプレートファイルでコンテナ定義を管理し、lifecycle.ignore_changesでCI/CDと共存する

この記事のポイント

・CloudFrontはエッジロケーションでキャッシュしてレイテンシを削減するCDNサービスです
・S3オリジンにはOAC（Origin Access Control）を使い、S3直接アクセスを必ず遮断する
・オリジングループで5xxエラー時にセカンダリS3へ自動フェイルオーバーさせる
・キャッシュポリシーとCache-Controlヘッダーを組み合わせてTTLを適切に制御する

この記事のポイント

・Route 53はヘルスチェックで向き先を自動切替できる
・フェイルオーバーはPrimary・Secondaryの2レコードで組む
・切り替え速度はTTLとヘルスチェック間隔で決まる
・マルチリージョン構成でリージョン障害にも備えられる

この記事のポイント

・VPCピアリングは2VPC間の1対1接続で推移的ルーティングが効かない
・Transit GatewayはハブになりVPC数が増えても接続数がO(n)で収まる
・3VPC以上またはマルチアカウント運用はTransit Gateway一択
・CIDR設計とルートテーブルの伝播ルールが設計の核心

この記事のポイント

・マルチAZはスタンバイDBへの自動フェイルオーバーで高可用性を実現する
・リードレプリカは読み取り専用の複製で参照負荷を分散する設計パターン
・2つは用途が異なる。可用性=マルチAZ、スケール=リードレプリカが基本
・フェイルオーバー時間は1～2分が目安。ダウンタイムゼロにはならない

この記事のポイント

・IAMユーザー・グループ・ロール・ポリシーの4要素を正確に理解する
・rootアカウントを封印し、IAMユーザーとMFAで運用する初期設定手順
・最小権限の原則を守るグループ設計と、EC2/S3/RDSへのロール付与の実践
・アクセスキーの代わりにIAMロールを使う設計がなぜセキュアかを理解する

この記事のポイント

・ELBがトラフィックを分散し、Auto Scalingが台数を自動調整する
・スケーリングポリシーはまずターゲット追跡を試し、段階制御が必要ならステップに切り替える
・ヘルスチェック失敗時にAuto Scalingが自動でEC2を入れ替える仕組み
・マルチAZ構成にしてはじめて単一AZ障害に耐えられる

この記事のポイント

・VPCのCIDRは作成後に変更できない——最初に余裕を持った/16で設計することが鉄則
・サブネットはパブリック（ALB）・アプリプライベート（EC2）・DBプライベート（RDS）の3層に分ける
・セキュリティグループはALB-SG→EC2-SG→RDS-SGの順にSG参照で連携させる
・S3・DynamoDB向けGateway型VPCエンドポイント（無料）でNATゲートウェイのコストを削減できる
・VPCフローログでACCEPT/REJECTを記録し、SG/NACLの設定検証と通信監査に活用する

この記事のポイント

・マルチAZはVPCサブネット設計から始まる
・ALB＋Auto Scalingで自動復旧するWeb層を作る
・RDSのマルチAZはプライマリ障害時に自動昇格する
・設計の落とし穴はセッション管理とDNS TTLにある

$ sudo yum update

$ sudo useradd pakira
$ sudo passwd pakira
Changing password for user pakira.
New password:　　　　←任意のパスワードを設定します。
Retype new password:　←再度、任意のパスワードを設定します。
passwd: all authentication tokens updated successfully.

$ date
Thu Apr 1 05:37:56 UTC 2021

$ $ sudo localectl set-locale LANG=ja_JP.utf8
$ $ source /etc/locale.conf
$ date
2021年 4月 1日 木曜日 05:45:42 UTC