TLDR; in AWS it's much easier to have an application span an availability zone (aka independent data centers built close together) than regions. AWS provides good support for this.
The longer story
AWS Regions are almost completely separate. There's no really easy automatic way to span regions in a single application, other than running separate copies of that application in each region. You typically use availability zones, which are a number of separate data centers located closely together but with independent infrastructure, usually <1ms apart. AWS will never move data outside a region without you explicitly telling it to, this is necessary for enterprises who may not want their data to leave a specific country. A region typically has three AZs, though in some areas AWS actually has many more data centers, I suspect people are assigned to them to spread the load.
A load balancer (ELB) easily distributes traffic between different AZs inside a region, so if one data center fails the others in the region can easily take over, including creating more resources if required and you've configured it to (auto scaling). AZs share resources much more easily as they're so close together, network latency wise. The Relational Database Service can keep synchronous databases in different AZs within a region, but not between regions, though you can have asynchronous replicas in another region.
If you want to load balance across regions the primary way is to use Route 53, AWS's DNS offering. This can load balance based on failover, geographic location, simple round robin, and probably others. The problem is if you need a single central database, that would need to be in one region. You can synchronise but it introduces risk and latency. If you can store your data in each region and the data is read only or write rarely this is much easier, but you'd have to work out database synchronisation yourself. Stateless applications or applications with rarely changing data would be particularly easy to spread across a region.
You can use the Cloudfront CDN to cache data at any of AWS's many edge locations, but the source of this will be a single region. It's typically done for performance.
Regions would used more in a DR scenario than for load balancing. You can reasonably easily copy your resources (data, virtual machine images) between regions and script loading creation of any other resources required, like queues, database, etc. If a whole region goes down, which is rare but can happen, DNS health checks will direct your users to another region.
You may be able to set up something like a VPN that lets your application span regions, but there are issues with consistency of databases and such, and probably few advantages. AZs are sufficiently robust in most cases. If you need very high availability you can architect what you need, but be prepared to pay for very smart people and sufficient resources.
You asked to be walked through how an application will load balance across AZ. Instead I suggest you read the extensive documentation AWS provides, including FAQs and product documentation.