Update SQS topology documentation (#7126)

* Update SQS topology documentation

* Fix broken link

Author: boblangley

transports/sqs/topology.md

@@ -11,7 +11,7 @@ partial: pub-sub-diagram
 
 ## SQS
 
-Amazon SQS exposes queue endpoints that are publicly available via [HTTPS](https://en.wikipedia.org/wiki/HTTPS). Endpoints may access SQS queues whether they are deployed in AWS or not; as long as the endpoint can reach both SQS and S3 via HTTPS it can use the transport.
+Amazon SQS exposes queues via [service endpoints](https://docs.aws.amazon.com/general/latest/gr/sqs-service.html#sqs_region) that are publicly available via [HTTPS](https://en.wikipedia.org/wiki/HTTPS). An [NServiceBus endpoints](/nservicebus/concepts/glossary.md#endpoint) can access SQS Queues whether they are deployed in AWS or not; as long as the endpoint can reach both SQS and S3 via HTTPS it can use the transport. By default, NServiceBus endpoints [process messages from an SQS queue with the same name](/nservicebus/endpoints/specify-endpoint-name.md#input-queue) as the endpoint.
 
 The transport initiates all network connections to SQS and S3; hence the endpoint itself does not need to be publicly accessible and can reside behind a firewall or proxy.
 

transports/sqs/topology_pub-sub_sqs_[5,).partial.md

@@ -1,12 +1,15 @@
 ### Publish/Subscribe
 
-The transport is a [multicast-enabled transport](/transports/types.md#multicast-enabled-transports) and provides built-in support for [publish-subscribe messaging](/nservicebus/messaging/publish-subscribe/) using Amazon Simple Notification Service (SNS). Publishing events to multiple endpoints is achieved by publishing a single message to an SNS topic to which multiple destination queues are subscribed.
+The transport is a [multicast-enabled transport](/transports/types.md#multicast-enabled-transports) and provides built-in support for [publish-subscribe messaging](/nservicebus/messaging/publish-subscribe/) using [Amazon Simple Notification Service (SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html). Publish and subscribe using SNS and SQS is achieved by publishing a message to a SNS topic to which none or more SQS queues are subscribed, with each SQS queue receiving a copy. The way the NServiceBus SQS transport leverages SNS and SQS, or topology, is by publishing events to the dedicated topics for the event type, with subscribing endpoints creating SNS subscriptions between the topic of events they handle to the endpoint's SQS queue.
 
-The topology (topics and subscriptions) is created automatically by the subscribing endpoints. Topology deployment can be automated, or manually created, using the transport CLI tool. Refer to the [transport operations section](/transports/sqs/operations-scripting.md) for more information.
+> [!NOTE]
+> By default, topic names are generated using the [message full type name and replacing characters](configuration-options.md#topic-name-generator) that are not allowed in SNS.
+
+Topology deployment can be automated, or manually created, using the transport CLI tool. Topics and subscriptions are created automatically by the subscribing endpoints. Publishing endpoints must create event topics manually before publishing events if there are no subscribers. Refer to the [transport operations section](/transports/sqs/operations-scripting.md) for more information.
 
 #### Message inheritance support
 
-By default topic names are generated using the message full type name and replacing characters that are not allowed in SNS. This has an impact on the way inheritance is supported by the transport. By default a subscriber will subscribe only to the most concrete type it knows about and a publisher will always publish the most concrete type it knows about. Inheritance at the subscriber level is not supported when using the automatically created topology.
+By default a subscriber will subscribe only to the most concrete type it knows about and a publisher will always publish the most concrete type it knows about. Inheritance at the subscriber level is not supported when using the automatically created topology.
 
 In case a subscriber needs to subscribe to a message type that is not the most concrete type as seen by the publisher, a custom mapping is needed. For example, if a subscriber is subscribed to the `IOrderAccepted` event defined in the `Contracts` assembly it will create and subscribe to a topic named `namespace-IOrderAccepted`. However, if in the same system the publisher publishes the `OrderAccepted` message that implements `IOrderAccepted` from the `Messages` assembly it'll try to publish to the `namespace-OrderAccepted` topic and the message won't be delivered to the desired destination.