AWS IAM and VPC Security as Code: KMS, Endpoints, WAF, and Security Hub

Use infrastructure as code to make security controls reviewable, repeatable, and testable—but do not treat a large stack as proof of least privilege or compliance. IAM and resource policies prevent or allow actions, KMS policies control key use, VPC endpoints provide network paths, WAF filters supported HTTP traffic, and Security Hub reports findings. Each control solves a different problem.

The strongest design states what each control prevents, what it only detects, how it is tested, and who responds when it fails.

Before you start

By the end, you will be able to:

• Classify controls as preventive, detective, or recovery-oriented.
• Scope workload roles and KMS access around named resources and call paths.
• Choose the correct private endpoint type and add an authorization boundary.
• Roll out WAF and Security Hub without creating a false sense of enforcement.

Why this matters

Security drift is not limited to console changes. A committed template can also be insecure:

• an IAM statement grants Action: "*" or Resource: "*";
• a KMS key policy makes a workload role a key administrator;
• a VPC endpoint allows every principal to access every resource;
• a WAF rule blocks legitimate traffic because it skipped count-mode testing;
• Security Hub is enabled in one Region while workloads run in several;
• a security finding has no owner or response deadline.

Infrastructure as code improves change control and repeatability. It does not decide whether the policy is safe. That still requires review, validation, tests, logs, and operational ownership.

Architecture at a glance

Human access -> federation and temporary credentials

Workload role
  |-- identity policy -> named AWS actions and resources
  |-- resource policy -> bucket, queue, secret, or API boundary
  `-- KMS key policy/grant -> cryptographic use, not key administration

Private workload subnet
  |-- S3 gateway endpoint -> route-table path with no endpoint charge
  |-- Secrets Manager interface endpoint -> private API path + SG + endpoint policy
  `-- controlled egress -> only when external access is required

Internet request
  |-- CloudFront WAF web ACL (global scope, created in us-east-1)
  `-- Regional WAF web ACL for supported regional resources

AWS Config + Security Hub CSPM -> findings -> owner -> remediation workflow

Network reachability and authorization are separate. A private endpoint can remove the internet path while still allowing broader API actions than intended. IAM, resource, key, and endpoint policies remain necessary.

Start with identities and permissions

AWS recommends federation and temporary credentials for human users and IAM roles for workloads. Long-lived access keys should not be the default application credential.

For a workload role:

1. List the API actions used by the application.
2. Scope resources to the intended ARNs where the service supports it.
3. Add conditions such as source account, source ARN, principal tags, or VPC endpoint only when they match the real call path.
4. Validate the policy with IAM Access Analyzer.
5. Test an allowed action and a denied action.
6. Review actual access activity and remove unused permissions.

An illustrative policy fragment:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOnlyFromUploadsPrefix",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::production-uploads/incoming/*"
    },
    {
      "Sid": "ReadApplicationSecret",
      "Effect": "Allow",
      "Action": ["secretsmanager:GetSecretValue"],
      "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:production/app-*"
    }
  ]
}

This is illustrative, not a universal policy. The actual secret suffix, Region, access pattern, KMS permissions, object versions, and bucket policy must be reviewed together.

Separate KMS administration from key use

A workload that decrypts an application secret normally does not need to:

• create or delete keys;
• change key policies;
• schedule key deletion;
• disable keys;
• create unrestricted grants.

Give key administrators and key users different permissions. Where supported, restrict cryptographic permissions using the KMS key ARN, kms:ViaService, caller account, source ARN, or the encryption context used by the integrated service.

Be careful with grants. AWS services can require them to use a customer-managed key, but grant permissions should be limited and tied to AWS resources. Grants do not automatically expire; stale custom grants need lifecycle management.

Before changing a production key policy:

• confirm the account retains a recovery administration path;
• test service integration in a non-production environment;
• verify encrypt and decrypt paths;
• monitor denied KMS calls;
• protect key deletion with the required waiting period and organizational controls.

Encryption can increase impact when one key protects unrelated critical systems. Choose key boundaries from data classification, blast radius, access administration, and service integration—not from a rule that every resource must have a unique key.

Design VPC endpoints as controlled paths

S3 gateway endpoints provide private S3 connectivity through route tables and have no additional endpoint charge. They have networking limitations—for example, they do not provide the same cross-network access model as interface endpoints.

Secrets Manager uses interface endpoints powered by AWS PrivateLink. The endpoint creates network interfaces, uses security groups, and can use private DNS. Interface endpoint-hour and data-processing charges apply.

For each endpoint, review four controls:

1. Route or DNS: does the workload actually use this endpoint?
2. Security group: which sources can connect to the interface endpoint?
3. Endpoint policy: which principals and API actions are allowed through it?
4. Service policy: does IAM or the resource policy restrict the target resource?

Do not remove NAT or internet egress until every required dependency has a tested alternative. Container registries, package repositories, external APIs, certificate checks, and telemetry destinations can create hidden dependencies.

Deploy WAF at the correct scope

AWS WAF web ACLs for CloudFront use global scope and must be created in US East (N. Virginia), us-east-1. Web ACLs for supported regional resources such as an ALB or API Gateway REST API are regional and must be in the resource's Region.

This usually requires a separate CDK stack or environment for the CloudFront web ACL.

Roll out new rules in count mode:

1. Enable metrics and sampled requests.
2. Observe representative production traffic.
3. Identify legitimate requests that match.
4. Tune exclusions and scope-down statements.
5. Move to blocking in a controlled change.
6. Keep a rapid disable or rollback path.

WAF is not authorization. It can reduce common web attacks and unwanted request patterns, but the application must still authenticate users, authorize actions, validate input, protect data, and rate-limit according to business identity where required.

Treat Security Hub as detection and aggregation

Security Hub CSPM evaluates enabled controls and aggregates findings from supported services and products. It does not retroactively generate all historical findings when first enabled, and it only processes findings in Regions where it is enabled.

Most Security Hub controls depend on AWS Config recording the relevant resources. Enabling Security Hub without checking Config coverage can leave expected controls without usable evaluation data.

For multi-account or multi-Region environments:

• designate the intended delegated administrator;
• define a home Region and linked Regions where aggregation is required;
• enable required standards and controls through central configuration where appropriate;
• route findings to an owner;
• suppress only with a reason, expiry, and compensating control;
• measure finding age and remediation, not only the security score.

A finding is evidence that something needs attention. It is not evidence that remediation occurred.

What breaks and how you detect it

Security and cost

Security baseline

• Human access uses federation, temporary credentials, and MFA.
• Workloads use roles with reviewed trust policies.
• Permissions are validated and include tested denials.
• Key administration and cryptographic use are separate.
• Public and cross-account resource access is continuously reviewed.
• Endpoint policies and service permissions both restrict access.
• WAF changes begin in count mode and have rollback.
• Security findings have an owner, severity policy, and response target.
• CloudTrail and relevant service logs are protected and retained.

Cost assumptions

Security controls are billable in different ways:

• customer-managed KMS keys and API requests;
• interface VPC endpoint-hours and data processing;
• WAF web ACLs, rules, requests, managed rule groups, and larger body inspection;
• Security Hub checks and finding ingestion;
• AWS Config recording and configuration items;
• CloudTrail data or additional event delivery;
• logs, metrics, alarms, retention, and transfer.

S3 gateway endpoints have no additional endpoint charge, which is why treating them like priced interface endpoints produces a wrong network cost model.

Price the enabled controls by account, Region, protected resource, request volume, recorded resource, and log retention. Security cost should be visible, but removing a control requires a risk decision—not only a lower estimate.

Practice: classify and test five controls

Safety: This exercise creates no AWS resources, needs no credentials, and has no cleanup step.

Goal

Review one stack without using the phrase “secure by default” as evidence.

Steps

1. Select one IAM policy, KMS key, VPC endpoint, WAF web ACL, and Security Hub control.
2. Classify each as preventive, detective, recovery-oriented, or a combination.
3. State the resource and threat boundary each control covers.
4. Write one positive and one negative test.
5. Name the metric, log, or finding produced when it fails.
6. Assign an owner and safe rollback or remediation path.

Verify the result

The review passes only when each control has a narrow claim, a test, an observable failure signal, and an owner. “It exists in CDK” is not a test result.

Clean up

No resources are created.

Verify cleanup

Confirm that no IAM, key, endpoint, WAF, Config, or Security Hub setting was changed.

Check your learning

1. Does a private VPC endpoint grant permission to use the target service?
2. In which Region must a CloudFront-scope WAFv2 web ACL be created?
3. Why should a workload role not normally be a KMS key administrator?
4. What dependency does Security Hub have for many configuration controls?

Review the answers

1. No. It provides a network path; IAM, resource, key, and endpoint policies still control authorization.
2. US East (N. Virginia), us-east-1.
3. Key administration could let the workload change policy, disable protection, or expand access beyond cryptographic use.
4. AWS Config must record the relevant resources for many Security Hub controls.

Before you ship

• [ ] Human and workload access uses temporary credentials.
• [ ] IAM policies pass Access Analyzer validation and include negative tests.
• [ ] KMS administration and use are separated and recoverable.
• [ ] Gateway and interface endpoints are chosen and priced correctly.
• [ ] Endpoint, IAM, resource, and key policies describe the same intended path.
• [ ] CloudFront and regional WAF resources use the correct scope and Region.
• [ ] WAF rules are tuned in count mode before blocking.
• [ ] Security Hub, Config coverage, aggregation, finding ownership, and response are verified.

Sources and verification

• Security best practices in IAM
• Validate policies with IAM Access Analyzer
• Least-privilege permissions for AWS KMS
• S3 gateway VPC endpoints
• Secrets Manager interface VPC endpoints
• Configuring protection in AWS WAF
• Resources protected by AWS WAF and CloudFront Region scope
• Introduction to AWS Security Hub CSPM
• Code status: Illustrative. Policies and architecture are not claimed as a deployed security baseline.
• Technical review: Pending human technical review.

Continue learning

• Next lesson: AWS Web App on Fargate, Aurora, and CloudFront
• Related reference: Orchestrating DataSync, DMS, and Glue

Correction history

• 2026-07-25: Replaced the inaccessible premium shell with a complete public lesson; separated prevention, network reachability, detection, and recovery, and added test and ownership boundaries.