Skip to main content
This lesson continues from API Gateway coverage and focuses on AWS application integration services and their security considerations. These services act as intermediaries between applications, third-party SaaS, and other AWS services. Most are highly managed: they provide encryption, scaling, and resiliency while you enforce access control via IAM and resource policies and monitor activity with CloudWatch and CloudTrail. Contents:
  • AppFlow (SaaS <> AWS data flows)
  • Messaging & events: SNS, SQS, Amazon MQ, EventBridge
  • Email: SES
  • Workflows & orchestration: Step Functions, SWF, MWAA
  • Security patterns, monitoring, and summary

​
AppFlow — receive and send data from third parties

Amazon AppFlow is a managed data integration service that transfers and transforms data between SaaS applications and AWS services. It is not an ETL or long‑term storage service; instead it focuses on secure, bi-directional data movement and transformation.
A simple architecture diagram titled "AppFlow" showing Salesforce events sent into Amazon AppFlow, forwarded as an event payload to Amazon EventBridge, which then invokes an AWS Lambda function. Icons and arrows illustrate the flow inside the AWS Cloud.
Key security considerations for AppFlow:
  • Credential storage: AppFlow integrates with AWS Secrets Manager for connection credentials and secrets — you typically do not need a separate secret store.
  • Encryption: server-side encryption for data at rest using AWS KMS and TLS for data in transit.
  • Observability: flows emit API and execution activity to CloudTrail and CloudWatch for auditing and monitoring.
  • Access control: use least-privilege IAM policies and resource-level permissions to control who can create, modify, or start flows.
AppFlow stores connection credentials in AWS Secrets Manager and supports encryption both in transit and at rest. Grant only the minimal IAM permissions required to create and manage flows.
Example AppFlow pipeline (SaaS → S3 → analytics) AppFlow commonly moves SaaS data into S3 for downstream processing using EventBridge, Step Functions, Glue crawlers, Athena, and other services.
A system architecture diagram titled "AppFlow" showing Jira Cloud sending data through Amazon AppFlow into an Amazon S3 raw data folder. AWS services (EventBridge, Step Functions, Glue crawler/DataBrew, Glue Data Catalog) process and stage the data, and Amazon Athena is used to query it for a user.
Monitoring and integration tips:
  • Enable CloudTrail for API-level auditing and CloudWatch for metrics and flow execution logs.
  • Use IAM roles tied to least privilege to restrict who can define flows and which targets flows can access.
  • When processing sensitive data, add a Lambda or data processing step to perform masking/redaction before writing to shared storage.

​
Messaging and events

​
Simple Notification Service (SNS)

SNS is a managed pub/sub notification service that fans out messages to multiple subscribers (HTTP(S), SQS, Lambda, email, SMS, etc.). It supports TLS in transit and KMS-based encryption at rest.
A slide titled "Simple Notification Service" showing an AWS architecture diagram where physicians send messages to an EC2 instance that publishes to an encrypted SNS topic. The topic fans out over HTTPS to encrypted SQS queues and EC2 instances (Billing, Scheduling, Prescription) with AWS Key Management Service used for encryption.
Important SNS security features:
  • SSE with AWS KMS for encryption at rest.
  • TLS for transport-level protection.
  • Access control via IAM and resource policies to control who can publish and subscribe.
  • Message filtering and delivery policies for routing — SNS does not natively inspect or redact message content.
  • Monitoring with CloudWatch metrics and CloudTrail. Use dead-letter queues (DLQs) when supported by subscription targets to capture undeliverable messages.
Message data handling:
  • For content inspection, masking, or blocking (e.g., PII), integrate SNS with processors like Lambda or EventBridge, or deploy specialized third-party inspection tools.
  • Use message attributes and SNS filtering to route sensitive vs. non-sensitive payloads to different downstream processors.

​
Simple Queue Service (SQS)

SQS is a fully managed queuing service available in Standard and FIFO queue types. It supports KMS server-side encryption and VPC interface endpoints (AWS PrivateLink) for private connectivity.
A diagram of an AWS Simple Queue Service setup showing Amazon SNS sending messages to Amazon SQS (with a dead-letter queue). Amazon KMS is shown for encryption and consumers like AWS Lambda, EC2, and Fargate process the messages.
Key SQS security and operational points:
  • SSE with KMS for messages at rest.
  • Use VPC Interface Endpoints (AWS PrivateLink) to keep SQS traffic within AWS network boundaries and avoid public IP egress.
  • Monitor with CloudWatch metrics (e.g., ApproximateAgeOfOldestMessage, NumberOfMessagesSent).
  • Enable CloudTrail for API call logging — SQS does not log message payloads by default.
A colorful infographic showing a cloud networking question about restricting Amazon SQS access to a VPC, with a teal header and four numbered answer choices. The options listed include VPC peering, an SQS VPN gateway, a VPC Interface Endpoint (AWS PrivateLink), and a NAT Gateway.
CloudWatch metrics and CloudTrail are primary tools to observe SQS usage and API behavior.
A presentation slide titled "Simple Queue Service" showing an AWS CloudWatch metrics view with multiple "MyQueue" entries and metric names (e.g., ApproximateAgeOfOldestMessage). A context menu is open with "Add to search" highlighted, and the slide notes that SQS has standard metrics via CloudWatch.
If detailed logging is required for SQS API calls and configuration changes, enable CloudTrail.
The image is a KodeKloud quiz slide asking how to achieve detailed logging for Amazon SQS, listing four numbered options (enable SQS native logging, use CloudWatch Logs, use AWS CloudTrail, or set up S3 bucket logging). It has a turquoise header and colorful numbered option boxes.

​
Amazon MQ

Amazon MQ provides managed Apache ActiveMQ and RabbitMQ brokers for applications that require standard messaging protocols and broker semantics (AMQP, MQTT, JMS). Use Amazon MQ when migrating legacy broker-based applications or when broker features are required.
An AWS architecture diagram for Amazon MQ showing a VPC with two Availability Zones, each containing a public subnet with an Amazon MQ broker protected by a security group. Messages from the brokers are sent to an AWS Lambda function, with a note that encryption is used at all times.
Security characteristics and best practices:
  • Encryption in transit via TLS and encryption at rest using AWS KMS.
  • Network isolation: place brokers in private subnets and control access with security groups.
  • Multi-AZ deployment for high availability. Although managed, brokers are provisioned (not serverless), so plan capacity and patching windows accordingly.
  • Use IAM policies, security groups, and broker-level authentication/authorization features for fine-grained access control.
A quiz-style slide asking which statement about Amazon MQ's encryption capabilities is correct, describing a financial firm's need for data encrypted at rest and in transit. Four numbered multiple-choice options mention AWS KMS and TLS as encryption methods.

​
Amazon EventBridge

EventBridge is a serverless event bus that ingests, filters, and routes events to targets using rules. It’s ideal for event-driven architectures connecting SaaS providers and AWS services.
A simplified diagram of Amazon EventBridge showing an event producer sending events to the EventBridge event bus, which uses rules to route events to targets like AWS Lambda, Amazon Kinesis Data Firehose, and Amazon SNS. A caption notes EventBridge is highly managed and uses AES-256 encryption by default.
Notes and security tips:
  • EventBridge uses KMS-backed encryption (AES-256 under the hood) for events at rest.
  • Use event bus resource policies and IAM to restrict who can put events onto buses or create rules.
  • Monitor with CloudWatch and CloudTrail; use X-Ray for distributed tracing where supported.
  • EventBridge is a managed event router — not a streaming platform or workflow orchestrator.

​
Simple Email Service (SES)

Amazon SES is a managed email platform for transactional and bulk mail. SES can ingest incoming mail (store in S3), publish events to SNS, or route to Lambda for custom processing.
A diagram titled "Simple Email Service" showing an AWS SES workflow: Route 53 routes mail to an SES domain which applies rules, stores emails and attachments in S3 buckets, and publishes to SNS. A Lambda function reads the SNS messages to extract email data and save it to a database.
Security and observability:
  • TLS for email transport; KMS for encryption of stored messages in S3.
  • SES Event Publishing captures detailed send/delivery events to CloudWatch, SNS, or Kinesis Data Firehose (deliveries, bounces, complaints, opens, clicks, etc.).
  • Use SES Reputation Dashboard to monitor bounce and complaint rates and maintain sending health to avoid sending restrictions.
A slide titled "Simple Email Service" showing an AWS SES console where an event destination is being configured to publish email sending events to Amazon SNS. The SNS topic "SES_tracking" is selected and the "Next" button is circled.

​
Workflows and orchestration

​
AWS Step Functions

Step Functions is a serverless state machine service to coordinate distributed tasks and microservices. Security revolves around IAM controls for who can start/manage state machines and the IAM roles state machines assume to call other services.
An AWS architecture diagram showing a Step Functions workflow that is triggered via EventBridge and orchestrates tasks like "Validate Policy", "Choose Action", "Temp Remove", "Ask User" and "Apply Choice." It also shows integrations with IAM, Lambda, Amazon SNS and API Gateway for user approval/notifications, with the note "Step Functions is mainly secured through the functions it calls."
Security and monitoring guidance:
  • Use IAM to restrict who can start or modify state machines and carefully scope the IAM role assumed by the state machine.
  • Observability: enable CloudWatch logs/metrics for executions, use CloudTrail for API history, and integrate AWS X-Ray for traces across supported integrations.
  • Use SNS or other human-approval mechanisms when workflows require manual steps or notifications.
A presentation slide titled "Step Functions" showing an AWS X‑Ray service map for a Step Functions state machine with connected AWS services (Lambda, DynamoDB, SNS) and a highlighted 67% error rate. The slide also notes monitoring via the usual tools and reminds viewers not to forget AWS X‑Ray.

​
Simple Workflow Service (SWF)

SWF is an older AWS workflow service for coordinating background jobs and workers. It requires you to manage worker resources and is monitored with CloudWatch and CloudTrail.
A diagram titled "Simple Workflow Service (SWF)" showing a linear order-processing flow: Customer Order → Verify Order → Charge Credit Card → Ship Order → Record Completion → End. Icons below represent the roles/systems involved: order verifiers, credit-card processors, warehouse employees, and database recorders.
Security points:
  • Standard AWS encryption and access controls (KMS, IAM, resource policies).
  • Use CloudTrail + CloudWatch for auditing and operational visibility.

​
Managed Workflows for Apache Airflow (MWAA)

MWAA is a managed Apache Airflow service that reduces operational overhead while providing Airflow orchestration integrated with AWS services.
A slide titled "Managed Apache Airflow" showing the Amazon MWAA architecture: a diagram of customer and service VPCs with Airflow schedulers, workers and web server, a DB proxy/meta-database, and connections to AWS services like CloudWatch, S3, SQS, ECR and KMS. The left side also has bullet points noting MWAA is complex but managed and enables encryption/IAM.
MWAA essentials and security practices:
  • Managed metadata store (Amazon Aurora) for Airflow state; secure it using IAM and standard DB access controls.
  • Store DAGs, plugins, and requirements in S3 and use KMS to encrypt sensitive artifacts.
  • Use CloudWatch metrics and logs for operators and task-level visibility and configure appropriate access control for the Airflow web UI.
  • Apply network controls (VPC, security groups) and least-privilege IAM roles for tasks.
A presentation slide titled "Managed Apache Airflow" with two bullet points about MWAA logging and documentation. On the right is a screenshot of the AWS "DAG code in Amazon S3" configuration panel showing S3 bucket, DAGs folder, plugins.zip and requirements.txt fields.
For end-to-end monitoring of MWAA pipelines, rely on CloudWatch metrics/logs produced by MWAA and instrumented task code (e.g., Lambda or ECS tasks).
A slide asking which AWS MWAA features can be used for comprehensive workflow monitoring, listing options like AWS MWAA Console, Amazon CloudWatch metrics and logs, AWS Step Functions, and AWS Lambda invocation logs. The design has a teal header, numbered rounded boxes for each option, and a KodeKloud copyright.

​
Summary — security patterns across integration services

Application integration services provide connectivity, messaging, and orchestration between components. Common security themes and recommended controls:
  • Encryption: Most services provide encryption at rest using AWS KMS and TLS for data in transit.
  • Access control: IAM and resource-level policies are the primary mechanisms to control access to resources and actions.
  • Observability: Use CloudWatch for metrics and logs; enable CloudTrail for API-level auditing; use X-Ray for distributed tracing where supported.
  • Content protection: To inspect, redact, or block sensitive message content, insert processing steps (Lambda, EventBridge rules, or dedicated data-protection tools) before storing or forwarding data.
  • Networking: Leverage VPC endpoints (PrivateLink) and security groups to minimize public network exposure.
Service quick reference
When designing integration pipelines, enforce least privilege for all service roles, enable CloudTrail for auditing, and use KMS to protect data at rest. Add processing steps (for example Lambda) to handle content inspection or redaction when necessary.
A presentation summary slide with a blue left panel and three numbered points on the right about AWS application integration services. The points mention enhancers/integration services, autoscaling/load balancing and serverless orchestration, and encryption at rest and in transit.
That concludes this lesson on security considerations for AWS application integration services. Thanks for following along.

Watch Video