SAP-C03 Hybrid Cloud Integration: Direct Connect Resiliency, Hybrid DNS, Data Sync, Legacy Integration and Hybrid Compute

Hybrid cloud integration is the set of designs that make an on-premises estate and AWS work as one system: a private network path that survives failures, data that stays synchronized in both places, legacy applications connected to cloud services without rewriting them, one DNS namespace that resolves from either side, and AWS compute running where the cloud Region cannot reach. SAP-C03 Task 1.3 has five skills, and each maps to a small family of services.

Neighbouring tasks own related material: VPC peering, AWS PrivateLink and multi-VPC design (Task 1.4), Route 53 routing policies for multi-Region traffic (Task 1.4), IAM Roles Anywhere (Task 2.1), DataSync and AWS DMS as one-time migration tools (Task 4.1) and disaster recovery (Task 4.2). This lesson covers DataSync only as an ongoing synchronization service.

Redundant Direct Connect means more than one connection, at more than one Direct Connect location, terminating on separate devices, sized so the surviving paths still carry the full load. AWS describes three resiliency models in the Direct Connect Resiliency Toolkit, and the scenario's failure requirement picks one.

Read the capacity requirement against the failure state, not the healthy state. If every path must carry 10 Gbps "while a failure is in progress", the connections that survive the worst stated failure must each provide it. Adding more connections at one location never protects against losing that location.

Link aggregation groups and minimum links

A link aggregation group (LAG) bundles dedicated connections of the same speed that terminate on the same AWS Direct Connect endpoint (the same AWS device) into one logical connection: up to four connections below 100 Gbps, or up to two at 100 or 400 Gbps. The LAG's minimum links attribute sets how many member connections must be up for the LAG itself to stay up. With the default of 0, a LAG that loses three of four members keeps running on one link and keeps attracting traffic it cannot carry. Setting minimum links to the number of members needed for the LAG's share of peak load makes a degraded LAG go down completely, BGP withdraws its routes, and traffic moves to the other location, which must have the capacity to absorb it.

Site-to-Site VPN as a backup path

A Site-to-Site VPN over the internet is the cheap backup for Direct Connect, but it crosses the public internet and each tunnel has a fixed bandwidth ceiling far below a multi-gigabit Direct Connect connection. It fits when the backup may run at reduced capacity; it fails any requirement that traffic never touches the internet or that full bandwidth survives the failure. Higher VPN capacity comes from ECMP across many tunnels on a transit gateway (see below), never from a single tunnel.

AWS always prefers the longest matching prefix first, and only among routes for the same prefix does it compare route sources. That one rule explains most "why is traffic using the VPN?" scenarios: whenever one path carries a summary route and the other carries more-specific routes covering the same addresses, the more-specific path wins for those addresses, however route sources or attachments are ranked. Advertise identical prefixes over both paths (or the more specific ones over Direct Connect) when Direct Connect must be primary.

For the same prefix, the two gateway types rank sources differently, and the difference is a common trap:

With BGP on both paths, failover is automatic: when the Direct Connect BGP session drops, its routes are withdrawn and the next-ranked VPN route is used; when the session returns, traffic moves back. As a general rule, any static route to a VPN attachment in a transit gateway route table outranks the Direct Connect gateway's propagated route for the same prefix, so it turns the backup into the primary path.

ECMP on a transit gateway

Equal-cost multi-path routing lets a transit gateway spread traffic across several Site-to-Site VPN tunnels, which is how a VPN backup reaches more capacity than one tunnel provides. It needs VPN ECMP support enabled on the transit gateway, dynamic (BGP) routing on every VPN connection (static VPNs are excluded) and the same prefixes advertised with the same AS path over each tunnel. ECMP never balances between different attachment types, so a Direct Connect gateway attachment and a VPN attachment advertising the same prefix are ranked, not shared. Virtual private gateways offer no equivalent aggregation.

Traffic has two directions and each is controlled on a different side. AWS decides how traffic flows from AWS to on premises based on what the customer advertises; the customer's routers decide how traffic flows from on premises to AWS based on their own BGP policy.

AWS to on premises: local preference communities

Tag the prefixes you advertise over a private or transit VIF with a Direct Connect local preference BGP community:

• 7224:7300 — high preference
• 7224:7200 — medium preference
• 7224:7100 — low preference

AWS evaluates local preference before AS path length, so communities override AS path prepending. For active/passive, tag the primary connection's prefixes high and the standby's low. AS path prepending also works for this direction, but you prepend on the path you want to make less preferred; prepending on the primary makes it the backup.

On premises to AWS: the customer router

AWS advertises the same VPC prefixes over every connection, so on-premises routers choose. Setting a higher BGP local preference on routes learned over the primary connection makes outbound traffic use it. A complete active/passive design therefore needs both a community on the advertisements and a local preference on the customer routers.

Active/active

AWS spreads traffic across connections only when it sees equal paths: the same prefixes, the same AS path length and the same local preference community (or none on either). Any difference AWS evaluates — a more specific prefix, a higher community, a shorter AS path — makes one connection preferred and leaves the other idle. Communities are static policy: they do not react to a degraded connection, which is why a partially failed LAG is handled with minimum links instead.

Direct Connect is private but not encrypted, so an encryption requirement adds one of three designs, chosen by connection type, bandwidth and whether public IP addresses are allowed.

One hybrid hub for many VPCs and Regions

The scalable pattern is a transit VIF on each Direct Connect connection to a single Direct Connect gateway, associated with a transit gateway in each Region. New VPCs only attach to their Regional transit gateway, so the Direct Connect configuration never changes as the estate grows. Private VIFs to virtual private gateways need per-VPC associations (or per-VPC VIFs) and do not scale to hundreds of VPCs; funnelling other Regions through one Region's transit gateway with transit gateway peering adds static routes and hairpins traffic. Inter-VPC design beyond the hybrid edge belongs to Task 1.4.

Pick the synchronization service by how the on-premises side keeps working. If applications keep using their existing storage and AWS needs a copy, use AWS DataSync. If on-premises applications should read and write storage that lives in AWS, use AWS Storage Gateway. If external partners exchange files over SFTP, FTPS, FTP or AS2, use AWS Transfer Family (next section).

AWS DataSync

DataSync copies data between on-premises NFS, SMB, HDFS or object storage and Amazon S3, Amazon EFS or Amazon FSx. An agent deployed on premises reads the source; a task defines source, destination and options, and runs on a schedule. Each run transfers only new and changed data, verifies integrity, and can be throttled with a bandwidth limit so it never saturates a shared link. Teams no longer write change-tracking scripts. For a fully private design, create an interface VPC endpoint for DataSync and activate the agent with that VPC service endpoint: control and data traffic then use private addresses reached over a private VIF or VPN. A public VIF still targets public addresses, FIPS endpoints are public endpoints, and DataSync has no gateway endpoint type.

AWS Storage Gateway types

Cached versus stored is the classic near-twin: stored keeps every block local (low latency for old data too), cached keeps only hot data local.

Keeping S3 File Gateway shares current

A file gateway knows about objects it wrote itself. Objects written to the bucket by anything else — a pipeline in AWS, another gateway — appear on the share only after the gateway refreshes its cached metadata. Automated cache refresh on the file share re-lists the bucket when a directory is accessed after a time-to-live you set, with no code; the RefreshCache API does the same on demand (for example from an event-driven function, which is custom code). Only a metadata refresh changes what the share lists; cache size and bucket settings do not.

When several gateways share a bucket, give each writable file share its own prefix so only one share ever writes a given object, and let other sites read that prefix through a read-only file share with automated cache refresh set to their freshness target. File locking is enforced by each gateway for its own clients and is not coordinated between gateways, and keeping earlier object versions records conflicting writes rather than preventing them.

AWS Transfer Family is a managed SFTP, FTPS, FTP and AS2 service that stores files in Amazon S3 or Amazon EFS, so partners keep their existing clients and processes while the company drops self-managed file servers. Three design choices define a server.

Endpoint type

Identity provider

• Service-managed users authenticate with SSH keys stored in the service; they cannot use directory passwords.
• AWS Directory Service authenticates against AWS Managed Microsoft AD or, through an AD Connector, the company's on-premises Active Directory, so users sign in with their existing usernames and passwords and access is granted per AD group.
• A custom identity provider (a Lambda function or an API Gateway endpoint) handles anything else, at the cost of code you maintain.

Processing and outbound transfers

Managed workflows run after an upload with built-in steps — copy, tag, delete and PGP decrypt — plus optional custom Lambda steps, so common post-upload processing needs no event-driven code. Connectors make AWS the client instead of the server: an SFTP connector sends files from S3 to a remote SFTP server the partner operates (or retrieves files from it), and an AS2 connector sends AS2 messages. A connector transfer is started with the StartFileTransfer API and explicit file paths, so any recurring outbound push needs an orchestration step that decides which files to send and calls that API. A Transfer Family server only receives connections; it cannot push to a partner.

Legacy modernization in this task means connecting systems you cannot change to cloud services by putting a managed broker, API front door or pipe between them and transforming the data in transit. Choose by the legacy interface: a message broker protocol points to Amazon MQ, a request/response service to API Gateway, and a queue feeding event-driven services to EventBridge Pipes.

Amazon MQ: move the broker, keep the code

Amazon MQ runs managed Apache ActiveMQ and RabbitMQ brokers that speak the industry protocols legacy applications already use, so applications move by changing a connection URL rather than code. ActiveMQ supports JMS clients over OpenWire plus AMQP 1.0, STOMP, MQTT and WebSocket; RabbitMQ uses AMQP 0-9-1. Rewriting producers and consumers for Amazon SQS, Amazon SNS or Amazon MSK is the cloud-native path, not the no-code-change one.

Broker HA is half the design: clients must also reconnect. With ActiveMQ, the client connection URL uses the failover: transport listing both broker endpoints, so applications move to the standby automatically.

API Gateway as a transforming facade

An API Gateway REST API can present a new contract while the back end keeps its old one: mapping templates (Velocity templates) rewrite request and response bodies declaratively, and a private integration through a VPC link reaches a load balancer whose IP targets are the on-premises service over Direct Connect or VPN. REST APIs also provide API keys and usage plans for per-client quotas. An HTTP API is cheaper and simpler, but its parameter mapping changes headers, query strings and paths, not bodies, and it has no usage plans.

When the transformation is more than a reshape of the body — decoding a non-JSON format or combining the response with data from another source — a Lambda integration is the right tool: the function calls the legacy service, transforms and enriches, and returns the new format. As a rule, mapping templates only rewrite the payload they are given, and load balancers route requests without transforming them.

EventBridge Pipes: legacy messages into events

An EventBridge pipe connects a source to a target with optional filtering, enrichment and input transformation, with no polling or delivery code. With an Amazon MQ queue as the source, a Lambda enrichment can convert each message (for example XML to JSON) and the pipe delivers the result to an event bus. The pipe's input transformer only reshapes JSON, so non-JSON payloads need an enrichment step. Two Amazon MQ details matter:

• A pipe consumes from queues, not topics. When legacy subscribers must keep their topic, make it an ActiveMQ virtual topic and point the pipe at one of its consumer queues.
• A broker in private subnets with no internet path is reached through an interface VPC endpoint for the pipes-data service, which keeps the pipe's polling on private addresses.

A Lambda function with an Amazon MQ event source mapping also works, but the function must then call PutEvents itself; a self-hosted container consumer is fully custom.

Hybrid DNS is built from Amazon Route 53 Resolver endpoints (the Resolver is now documented as Route 53 VPC Resolver): an inbound endpoint lets on-premises DNS servers resolve AWS names, and an outbound endpoint with forwarding rules lets VPCs resolve on-premises names. Start every design by asking which direction the query travels.

Two inbound rules decide most troubleshooting. First, the private hosted zone must be associated with the VPC that contains the inbound endpoint; a zone associated only with workload VPCs resolves there but returns NXDOMAIN through the endpoint. Second, NXDOMAIN means the query arrived and was answered, whereas a security group that blocks DNS (TCP and UDP port 53) causes timeouts. On-premises servers must never forward to the VPC's base-plus-two Resolver address; that address is not reachable from outside the VPC, which is why inbound endpoints exist.

Forwarding rules, system rules and sharing

A forwarding rule for a domain also covers all its subdomains. When a subdomain must resolve inside AWS instead — for example a private hosted zone for a cloud subdomain of a corporate domain that is forwarded on premises — create a system rule for the subdomain; Resolver then answers it locally, which also keeps it working when the Direct Connect link is down. In a multi-account organization, build one outbound endpoint and the rules in a central network account and share the rules with AWS Resource Access Manager (AWS RAM); member VPCs associate the shared rules and use the central endpoint through them, instead of each account running its own endpoint.

Route 53 Profiles

A Route 53 Profile bundles DNS configuration — private hosted zones, Resolver forwarding and system rules, DNS Firewall rule groups, interface VPC endpoints and Resolver query logging configurations — into one resource that is shared through AWS RAM and associated with VPCs; each VPC can be associated with only one Profile. Changes to the Profile apply to every associated VPC, which suits hundreds of VPCs that need the same DNS setup. Without a Profile, private hosted zones cannot be shared through RAM at all; cross-account association needs CreateVPCAssociationAuthorization per VPC.

Split-horizon DNS

Split-horizon DNS returns different answers to internal and external clients for the same name, built from a public hosted zone and a private hosted zone with the same name. Inside VPCs associated with the private zone, Route 53 answers from the private zone and does not fall back to the public zone for names the private zone lacks. A private zone named example.com holding one record therefore breaks every other example.com name inside the VPC. Scope each private zone to exactly the names that need an internal answer, typically one zone per such host name with the record at the zone apex, and associate it with the VPCs, including the inbound endpoint's VPC. On-premises clients see the internal answer only if their DNS servers conditionally forward that same narrow name to the inbound endpoint; forwarding the whole parent domain would send every public name through the private view. Mirroring every public record in the private zone also works, at the cost of maintaining each record twice.

Hybrid compute puts AWS-managed or AWS-orchestrated compute where the Region cannot serve the requirement. Three questions decide: must data or processing stay in the customer's own facility, who owns the hardware, and does the site keep a reliable connection to the Region?

Local Zones and Outposts both deliver low latency; the split is where the infrastructure sits. A Local Zone is outside the customer's building, so it fails an "inside the plant" residency requirement but suits city users; an Outpost is inside, so it needs space, power and a service link. AWS points disconnected, intermittent or limited-connectivity sites to EKS Anywhere rather than Hybrid Nodes, because Hybrid Nodes depend on the Region's control plane.

ECS Anywhere limits

Servers are registered as external instances (through an AWS Systems Manager activation) and services run with the EXTERNAL launch type. Tasks use the bridge, host or none network mode — awsvpc is not supported — and external instances do not support service load balancing, service discovery or capacity providers. ECS Anywhere therefore suits workers that make outbound calls (polling queues, writing to S3) rather than services that receive load-balanced inbound traffic.