Turning up Security on Application Integration Part 1

• Auto Scaling
• Application Load Balancer (ALB)
• Network Load Balancer (NLB)
• Gateway Load Balancer (GWLB)
• Amazon API Gateway
• Summary mapping and operational tips

​

Auto Scaling

• Service identity: Auto Scaling performs actions using a service-linked role. In IAM and exam scenarios, recognize the service-linked role as the IAM principal for Auto Scaling.
• Observability: monitor scaling activity with CloudWatch metrics/events and CloudTrail API logs to detect unexpected scaling behavior.
• Sizing and resilience: set sensible ASG min and max values to meet availability, cost, and capacity requirements. Setting min == max disables dynamic scaling and removes resiliency benefits.

​

Application Load Balancer (ALB)

• OSI layer: Layer 7 — route based on HTTP semantics.
• Security groups: restrict inbound ports to only what’s required (for example, 443 for HTTPS) and allow outbound traffic necessary to reach targets.
• Authentication: use listener rule authentication with Amazon Cognito or external OIDC providers to authenticate requests before forwarding.
• TLS termination: terminate TLS on the ALB and use AWS Certificate Manager (ACM) for certificate management and automatic renewal.
• Logs and monitoring: enable ALB access logs to S3 for request/response-level detail; use CloudWatch for metrics and CloudTrail for configuration/API auditing.

• ALB OSI layer: Layer 7.
• Pre-target authentication: ALB listener authentication with Cognito or OIDC.
• Encrypt traffic in transit: enable HTTPS listeners and use ACM-managed certificates.

​

Network Load Balancer (NLB)

• OSI layer: Layer 4 — routes based on TCP/UDP rather than HTTP semantics.
• Listeners: supports TCP, UDP, and TLS listeners. TLS listeners allow TLS termination at the NLB.
• Access control: use security groups on targets or interface ENIs, and NACLs at the subnet level where appropriate.
• PrivateLink: NLB is a common target for AWS PrivateLink endpoint services — use this for secure, private connectivity across VPCs or accounts.
• Logging: NLB integrates with CloudWatch metrics and supports access logs to S3 for some listener types; verify current AWS docs for listener-specific logging support.

• NLB supports TLS but offers less granular cipher-suite customization than a dedicated proxy. If you need strict cipher control, terminate TLS on a proxy or at application endpoints where you can configure the TLS stack directly.

​

Gateway Load Balancer (GWLB)

• Encapsulation: GWLB uses GENEVE to encapsulate and tunnel traffic to inspection appliances — allowing metadata and flexible headers to be delivered to appliances.
• Traffic flow: client → GWLB endpoint → GENEVE-encapsulated packet to appliance → appliance inspects/modifies → decapsulate at GWLB → forward to destination.
• Endpoint access control: create a Gateway Load Balancer endpoint (GWLBe) to connect consumer VPC traffic to a provider VPC. Use endpoint service configuration and resource-based policies to control which principals can create endpoints.
• Monitoring: enable CloudWatch metrics, CloudTrail, and VPC Flow Logs for per-ENI and per-flow network visibility.

• Enable VPC Flow Logs when you need per-flow inspection visibility.
• Use endpoint service policies to restrict who can connect to your GWLB-managed service.

​

Amazon API Gateway

• Purpose: front proxy for APIs supporting integrations to Lambda, ALB/NLB-backed services, HTTP endpoints, and many AWS service integrations.
• Encryption: TLS for endpoint communication and encryption at rest for API cache. API Gateway also supports mutual TLS (mTLS) for client and server certificate verification.
• Authorization:
  • IAM (sigv4) for AWS service-to-service calls,
  • Amazon Cognito user pools for user authentication,
  • Lambda Authorizers (custom authorizers) for custom auth/permission logic returning IAM policies.
• API keys & usage plans: use API keys and usage plans to track, throttle, and quota developer or third-party usage.
• Observability: CloudWatch Logs/Metrics and AWS X-Ray support for distributed tracing.

• Custom authorization logic: use a Lambda Authorizer.
• Metering third-party usage: use API keys with usage plans, throttling, and quotas.
• Detailed diagnostics and auditing: enable CloudWatch Logs for the API and consider X-Ray for distributed tracing.

{ "RequestId": "$context.requestId", "DomainName": "$context.domainName", "APIId": "$context.apiId", "RequestPath": "$context.path", "RequestTime": "$context.requestTime", "SourceIp": "$context.identity.sourceIp", "ResourcePath": "$context.resourcePath", "Stage": "$context.stage" }

​

Quick Reference Table — Service, OSI Layer, and Recommended Controls

​

Closing notes

• Many integration services act as “enablers”: focus on how they connect, what they terminate, and which resources they expose.
• When answering exam or design questions, map each service to:
  • its OSI layer,
  • its authentication and authorization capabilities,
  • its logging/monitoring options,
  • and whether it persists data (for example, ALBs generally do not persist application data; API Gateway may cache responses that can be encrypted at rest).
• Apply defense in depth: network controls (security groups/NACLs), identity controls (IAM/Cognito/Lambda authorizers), transport security (TLS/mTLS), and observability (CloudWatch, CloudTrail, VPC Flow Logs).