AWS: Cloud Start

Cloud computing emerged as a response to the growing cost and complexity of maintaining on-premises data centers.

Traditionally, organizations had to purchase, install, and manage their own compute, storage, and networking hardware—requiring dedicated infrastructure teams and significant upfront investment. As demand grew, this model became inefficient and slowed innovation.

Cloud computing addresses this by providing on-demand IT resources over the internet with pay-as-you-go pricing. Instead of owning physical hardware, organizations consume virtualized infrastructure operated by providers such as Amazon Web Services, shifting maintenance, scaling, and availability responsibilities away from the business.

Key points to understand:

  • On-demand resources
  • Compute, storage, and networking can be provisioned instantly when needed, without long procurement cycles.

  • Pay only for what you use
  • No large upfront hardware costs—billing scales with actual usage.

  • Rapid environment replication
  • Identical environments (development, QA, production) can be created or destroyed in minutes instead of days or weeks.

  • Logical, software-defined infrastructure
  • Infrastructure is managed through APIs and consoles rather than physical installation and cabling.

  • Reduced operational overhead
  • Tasks like hardware maintenance, backups, and basic infrastructure management are handled by the cloud provider.

  • Focus on business differentiation
  • Teams spend more time on application logic and product value instead of undifferentiated infrastructure work.

  • Built-in scalability and availability
  • Applications can scale up or down easily and be designed for high availability from day one.

In practice, cloud platforms like AWS provide the services needed to design scalable, reliable, and cost-effective systems—allowing applications to reach users faster without the burden of managing physical data centers.

AWS Global Infrastructure: Regions, Availability Zones, and the Edge

When building our employee directory application, we need a safe place to store employee photos. Keeping a single copy on a laptop is risky—if the device fails, the data is lost. By uploading these photos to Amazon Web Services, the data is stored securely in professional data centers and remains accessible from anywhere: home, office, phone, or while traveling.

How AWS protects your data

  • Redundant storage
  • Photos are stored on servers inside AWS data centers, with copies designed to survive hardware failures.

  • Availability Zones (AZs)
  • An Availability Zone is a cluster of one or more data centers with independent power, networking, and connectivity. If one data center fails, others in the AZ continue operating.

  • Regions
  • Multiple AZs are grouped into a Region. If an entire AZ is affected by a large-scale event, workloads can continue running in another AZ within the same Region.

This layered design—data centers → availability zones → regions—is what gives AWS its high resilience.

md
AWS GLOBAL INFRASTRUCTURE (REDUNDANCY + PERFORMANCE)

You (Laptop)                          AWS Cloud
+----------------+          +----------------------------------------+
|  Only copy of  |  upload  |  Region (e.g., "North Virginia")        |
|  employee      +--------->|  +----------------------------------+  |
|  photos        |          |  | Availability Zone A (AZ-A)        |  |
|  (risk!)       |          |  |  +-----------+   +-----------+    |  |
+----------------+          |  |  | DataCtr 1 |<->| DataCtr 2 |    |  |
                            |  |  +-----------+   +-----------+    |  |
                            |  |   redundant power/network/links   |  |
                            |  +----------------------------------+  |
                            |  +----------------------------------+  |
                            |  | Availability Zone B (AZ-B)        |  |
                            |  |  +-----------+   +-----------+    |  |
                            |  |  | DataCtr 3 |<->| DataCtr 4 |    |  |
                            |  |  +-----------+   +-----------+    |  |
                            |  +----------------------------------+  |
                            |           AZ-A  <====>  AZ-B           |
                            |      (high-speed, low-latency links)   |
                            +----------------------------------------+


NESTED REDUNDANCY MODEL (FROM SMALLEST TO LARGEST)

+------------------------------+
| Region                       |
|  +------------------------+  |
|  | Availability Zone (AZ) |  |
|  |  +------------------+  |  |
|  |  | Data Center(s)   |  |  |
|  |  +------------------+  |  |
|  +------------------------+  |
+------------------------------+

Choosing the right AWS Region

When deciding where to place your resources, there are four key factors:

  • Compliance
  • Regulatory or legal requirements may force data to stay within specific country boundaries. If compliance dictates the region, this decision is final.

  • Latency
  • Resources should be geographically close to users to minimize delay. Distance matters, and latency is ultimately limited by the speed of light.

  • Pricing
  • Costs vary between regions due to local factors such as taxes and operational expenses.

  • Service availability
  • Not all AWS services or new features are available in every region at launch.

Reducing latency with the Global Edge Network

Even with the right region, users far away can experience slower load times. AWS addresses this with its Global Edge Network:

  • Edge locations and regional edge caches store copies of frequently accessed content closer to users.
  • Instead of every request traveling back to a single region, users retrieve data from the nearest edge location.
  • This dramatically reduces latency for global applications, especially websites and media-heavy workloads.

md

CHOOSING A REGION (DECISION FLOW)

+------------------+
| Compliance rules?|
+--------+---------+
         |
   yes   v   no
  +-------------+      +------------------+
  | MUST choose |      | Latency (users)  |
  | that region |      +--------+---------+
  +-------------+               |
                                v
                       +------------------+
                       | Pricing varies   |
                       +--------+---------+
                                |
                                v
                       +------------------+
                       | Service available|
                       | in that region?  |
                       +------------------+


GLOBAL EDGE NETWORK (FASTER FOR FAR USERS)

User in Japan                          User in Brazil
+-----------+                           +-----------+
| Browser   |                           | Browser   |
+-----+-----+                           +-----+-----+
      |                                         |
      | request website/photos                  | request website/photos
      v                                         v
+-------------------+                    +-------------------+
| Nearest Edge      |                    | Nearest Edge      |
| Location (cache)  |                    | Location (cache)  |
+---------+---------+                    +---------+---------+
          |  (cache hit)                          | (cache hit)
          | returns fast                          | returns fast
          v                                       v
     [Content delivered]                    [Content delivered]

          | (cache miss)
          v
+-------------------------------+
| Origin in AWS Region (Ohio)   |
| (where your app/storage lives)|
+-------------------------------+

In summary

  • Data is protected through multiple layers of redundancy.
  • Availability Zones and Regions provide fault isolation and resilience.
  • Region selection depends on compliance, latency, price, and service availability.
  • Edge caching brings content closer to users worldwide, improving performance.

Together, these components form the foundation of AWS’s global infrastructure and enable applications to be fast, resilient, and globally accessible.

Interfacing with AWS

When infrastructure is physical and on-premises, interacting with it is intuitive—you can see it, touch it, and manage it directly at every level. Once infrastructure becomes virtual, as it does in the cloud, that interaction model changes. Instead of physically managing servers and storage, you logically manage infrastructure through APIs provided by Amazon Web Services.

Every action in AWS—creating a virtual server, storing employee photos, deleting resources, or changing configurations—is performed through API calls. AWS offers three primary ways to make these API calls, each suited to different stages of experience and use cases.

Ways to interact with AWS:

  • AWS Management Console
  • A web-based, graphical interface accessed through a browser.

  • Ideal for beginners and exploration
  • Point-and-click interaction with guided prompts
  • No scripting or syntax knowledge required
  • Region-aware (switching regions changes where your resources are created)
  • Best for learning, testing, and occasional manual operations
  • AWS Command Line Interface (CLI)
  • A text-based tool for issuing commands directly to AWS services.

  • Enables scripting and repeatable workflows
  • Reduces human error compared to manual clicking
  • Can be run locally on your machine or via AWS CloudShell
  • Requires learning AWS command syntax
  • Well-suited for production environments and automation

bash
aws ec2 run-instance --image-id ami-0a606d8395a538502 --instance-type t2.micro

{

"Reservations": [

{"Groups": [],

"Instances": [

{"AmiLaunchIndex": 0,

...

  • AWS Software Development Kits (SDKs)
  • Language-specific libraries that allow applications to interact with AWS programmatically.

  • Available for popular languages like Python, Java, Node.js, .NET, and more
  • Ideal for integrating AWS services directly into application code
  • Enables use of programming constructs such as loops, conditions, and data structures
  • Commonly used for tasks like uploading files, querying databases, or triggering services from applications

python
impoty boto3

ec2 = boto3.client('ec2')

response = ec2.describe_instance()

print(response)

How these tools fit together:

  • The Console is great for learning and visual understanding.
  • The CLI enables automation, consistency, and infrastructure scripting.
  • SDKs allow AWS to become a native part of your application logic.

In practice, teams often start with the console, transition to the CLI for reliability and automation, and eventually use SDKs to tightly integrate AWS services into their applications. Together, these tools form a flexible and powerful interface for managing cloud infrastructure efficiently and safely.