Week 2: Compute & Networking

• Hey everyone, and welcome back. So far, you’ve been learning all about some higher level
  concepts regarding AWS, making sure you understand AWS in general, the global infrastructure, as
  well as setting up an account and providing yourself the
  right level of permissions. But you may also remember
  that we ended the last lesson by launching an EC2 instance
  to host our application. An EC2 instance is simply
  just a form of compute, meaning it gives our application
  power in the form of CPU, memory and networking capacity so that we can process our user’s requests. This concept of compute leads us into the next lesson where we
  discuss your compute options on AWS. Of course, you’ve already
  seen one of these options, EC2, but we’ll also discuss
  other common solutions such as container services like
  Amazon Elastic Container Service or ECS and Amazon Elastic
  Kubernetes Service or EKS as well as serverless
  options like AWS Lambda. After the upcoming lessons, you’ll not only understand
  each of these compute services but you’ll also be able to
  compare them to one another. That way you’ll know how and when to apply each service
  to different use cases. You’ll get an opportunity
  to see more demos with Amazon EC2, and we will go further into the details throughout this week. But as you imagine, we can’t just launch this EC2
  instance into space, right? We have to put it somewhere
  and where do we put it? Well, we put it in a
  network that we’ll need to customize for our application. Every EC2 instance needs to exist inside of a network and on AWS, those networks are called the VPCs. We’ll learn all about
  networking on AWS using VPCs but rest assured this won’t be too hard. We’ll give you all the
  information you need to launch an EC2 instance into a VPC. All right, so that’s what is on deck. Also, make sure you are checking out the readings that follow the videos. There’s additional information in those readings that you won’t see in the videos, like use cases, features we didn’t have
  time to cover and more. All right, I think that it’s
  time for us to get started. Enjoy the lessons and I will see you soon.

• Let’s talk about Compute. Every business needs raw compute capacity to run applications. These applications could be web servers, batch jobs, databases, HR
  software, machine learning, or just about whatever you can think of. The time, money, and effort
  it takes to get up and running with on-premises computing
  resources are fairly high. When you own your own
  fleet of physical servers, you first have to do a bunch
  of research to see what type of servers you want to buy
  and how many you need to buy. Then you need to purchase
  that hardware upfront. You’ll wait multiple weeks or months for servers to be delivered. You then take them to a data center space that you own or rent to install them, rack and stack them and wire them all up. Then you make sure the
  servers are secured, powered up and ready to be used. Only then can you begin
  to host your applications on top of these servers. The worst part is, once
  you buy these servers, you are stuck with them
  whether you use them or not. It’s not easy to just
  suddenly provision more physical compute capacity
  when you need it, and it’s even harder
  to get your money back on servers you no longer need. It’s impossible to get the time back. Following a Compute as a
  Service model is much easier to get started and support
  operations over time. AWS took care of the
  hard part for you already as far as getting started goes. AWS already built and
  secured the data centers. AWS has already bought the servers, racked them and stacked them, and they are already
  online ready to be used. In a previous lesson, we
  showed you how to launch the employee directory
  application with Amazon EC2. We didn’t really talk about
  the details, how EC2 works, what configurations exist
  for it, and we definitely didn’t discuss any other Compute
  options that exist on AWS. AWS has different services
  for different use cases, and Amazon EC2 is one of
  the basic AWS services that are important to understand. We’ll be spending most of our time in these upcoming lessons exploring EC2. That being said, though virtual machines like EC2 are great, there
  are other compute services out there too, like container services and serverless compute. You’ll learn about these
  other compute options and their use cases. Don’t always assume that
  VMs are the default answer. Sometimes it makes sense
  to architect applications for serverless compute or
  containers from the start, depending on what you are building and what you are optimizing for.

EC2: Orchestrating Your Cloud Infrastructure with Precision

Welcome to the world of Amazon Elastic Compute Cloud (EC2), where flexibility and control collide to empower modern cloud architectures. This tutorial delves into the core principles of EC2, demonstrating how you can meticulously sculpt your cloud infrastructure to perfectly harmonize with your unique needs.

Unleashing Customization:

Imagine a paradigm shift – no longer bound by the constraints of physical servers. EC2 transcends this limitation, offering a smorgasbord of virtual servers readily available in the cloud. With exquisite granularity, you can tailor resources to fit your applications like a bespoke suit.

This customization extends far beyond mere CPU and memory. You wield the power to choose:

• Operating Systems: Windows, Linux distributions, macOS, and more!
• Amazon Machine Images (AMIs): Pre-configured software stacks for specific use cases, from web servers to data analysis platforms.
• Instance Types: A meticulous spectrum of options, from compute-optimized behemoths for number crunching to cost-effective workhorses for light workloads.

This fine-tuning eliminates the “one size fits all” fallacy plaguing on-premises deployments. Need a powerhouse for scientific simulations? Choose a compute-optimized instance. Hosting a simple blog? A smaller, cost-optimized option awaits.

Scaling with Grace:

Gone are the days of frantic server procurement during traffic surges. EC2 empowers you to:

• Scale Up seamlessly: Launch additional instances in a flash to handle peak demand.
• Scale Down effortlessly: Terminate unused instances when demand ebbs, minimizing cost.

This elasticity fosters agility and cost-efficiency. No more overprovisioning resources that sit idle or scrambling for servers when the going gets tough. With EC2, you pay only for what you consume, ensuring optimal cloud spending.

Embracing Agility:

The cloud is a dynamic canvas, and your applications should be too. EC2 empowers you to:

• Resize Instances on the fly: Adapt your resource allocation as your workload evolves.
• Automate Management: Leverage tools like CloudFormation to orchestrate your infrastructure programmatically.

This flexibility allows you to adapt to changing circumstances and ensure your applications always have the resources they need to thrive.

Beyond the Foundation:

EC2 is just the cornerstone of your cloud empire. As you delve deeper, you’ll unlock a treasure trove of features:

• Security Groups: Granular network access control for enhanced security.
• Auto Scaling: Automate instance adjustments based on predefined metrics.
• Spot Instances: Access significant discounts on unused capacity from the EC2 pool.

These, and many more, empower you to build robust, scalable, and cost-efficient cloud solutions.

Taking the First Step:

Ready to orchestrate your cloud infrastructure with precision? Here are your guideposts:

• AWS EC2 Console: Your web-based control center for managing EC2 instances.
• AWS CLI: Automate EC2 tasks with the command-line interface.
• AWS Documentation: A comprehensive knowledge base to navigate the vast possibilities of EC2 and other AWS services.

Remember, the cloud is your canvas. Experiment, explore, and unlock the limitless potential of EC2. With its unparalleled flexibility and control, you can craft an infrastructure that perfectly aligns with your vision, paving the way for innovation and success.

We hope this professionalized version of the tutorial sparks your interest in EC2. With its powerful capabilities, you can become a master conductor of your cloud infrastructure, orchestrating its every note to create a symphony of success.

• EC2 instances give
  you a lot of flexibility and control in the cloud, and you configure them to meet your needs. You can provision one
  or many instances easily and at the end of the billing cycle, you only pay for what you use, either per second or per hour depending on the type of the instance. When you no longer need an instance, you can terminate or stop the instance and you will stop incurring charges. Not all servers are the same, and you are probably looking
  to run a specific type of operating system on your EC2 instance. AWS supports a range of operating systems including Linux, MacOS,
  Ubuntu, Windows, and more. To select the operating
  system for your server, you must choose an Amazon
  Machine Image or an AMI. The AMI contains information about how you want your
  instance to be configured including the operating system, possible applications to be pre-installed on that instance upon launch,
  and other configurations. You can launch one or many
  instances from a single AMI, which would create multiple instances that all have the same configurations. Some AIs are provided by AWS whereas others are
  provided by the community and could be found using
  the AWS Marketplace or you can build your own
  custom AMIs as needed. For example, Amazon Linux
  2 is the AMI we selected when we launched our Employee
  Directory Application. This AMI is provided by AWS and it’s essentially a pre-built
  EC2-optimized Linux Image that has long-term
  support provided by AWS. Beyond the properties
  determined by the AMI, you can also configure
  the instance type in size which correspond to the amount of compute, memory, and network capabilities
  available per instance. Different applications have
  different hardware requirements and choosing the instance
  type for your application gives you the ability to pick
  the hardware that it runs on. It’s also really nice that
  you have a wide variety of choices as it’s hard
  to achieve that same level of variety with on-premises resources. The instance types you can
  choose from are grouped for use cases like
  compute-optimized, memory-optimized, storage-optimized instances, and more. There’s a list of instance
  types you can find in the AWS documentation, and you can expect this
  page to be updated regularly as new instance types are released. For example, the G instance
  family are optimized for graphics intensive applications, which would work best for use cases such as 3D visualizations
  or video encoding. Whereas the M5 General
  Purpose EC2 instance family provides a balance of resources and are great for applications
  that use these resources in equal proportions like web servers, our Employee Directory
  Application example, or co-repositories. When you are launching an EC2 instance, you will see something like this when selecting an instance type and size. The T3 or A1 is the instance type that determines the blend
  of hardware capabilities, then the dot, then the size
  like small, medium, large. It goes down to nano and up to
  many, many extra large sizes. The great thing about this
  type of selection existing right at your fingertips is
  that you are no longer locked into hardware decisions upfront. You can choose an initial
  EC2 instance type, evaluate its performance
  for your specific use case, and then later change
  it to a different type that is better suited for the application. EC2 is also re-sizable with
  a few clicks in the console or can be done programmatically
  through an API call. All of these configurations
  being available to you via API enables you to embrace
  change over time easily as your workloads mature and change. So okay, virtual machines
  are cool and totally not new, so how exactly does this
  impact your business? Well, the important thing is this. The flexible and low-cost
  nature of EC2 instances as well as the ease of
  provisioning servers allows for programmers and businesses to innovate more quickly
  by spinning up servers for a short amount of
  time to run experiments and find optimal configurations
  for your applications. EC2 offers a wide variety of
  hardware options to choose from so you can optimize your solutions by selecting the right EC2 instance type for your application, and then you can optimize even further by right-sizing the resource
  or selecting an instance size that is appropriate for your application and not over provisioning like
  is often done on premises. This type of optimization is
  hard to achieve on your own because with traditional
  on-premises deployments, you are working with hardware constraints that simply don’t exist in
  the same way with the cloud. The ability to adapt to changes and choose really specific configurations for your virtual machines all
  through a couple of API calls is very powerful and EC2 is
  really just the beginning of the story.

Tutorial: Navigating the EC2 Instance Lifecycle and Costs

Welcome to the world of Amazon EC2! This tutorial will guide you through the lifecycle of an EC2 instance, from its creation to its termination, while keeping a watchful eye on the associated costs. By understanding these key aspects, you’ll be well-equipped to optimize your cloud resources and manage your budget effectively.

Phase 1: Launching Your Instance

1. Choosing the Right Image (AMI): Your journey begins with selecting an Amazon Machine Image (AMI) that serves as the blueprint for your virtual machine. Consider factors like operating system, software pre-installation, and resource requirements.
2. Instance Type: Next, pick an instance type that aligns with your application’s needs. Consider factors like CPU, memory, storage, and network performance. Remember, higher specifications come at a higher cost.
3. Launch and Configuration: Fire up your chosen instance! Configure security groups, network settings, and storage options as needed.
4. Pending State: As you launch, your instance enters the “pending” state while resources are allocated. You’re not charged yet.

Phase 2: The Running Instance

1. Operational State: Once configured, your instance transitions to the “running” state. This is where the fun begins – your application is live! However, keep in mind that you’re now incurring charges based on your chosen instance type and running time.
2. Optimizing Costs: To keep costs under control, consider:
   • Rightsizing: Scale your instance type up or down based on actual usage patterns. Don’t pay for more power than you need.
   • Scheduled Instances: Reserve instances for a fixed term at a discounted rate, ideal for predictable workloads.
   • Spot Instances: Bid on unused EC2 capacity for significant cost savings, suitable for fault-tolerant workloads.

Phase 3: Instance Management

1. Stopping and Starting: When your application isn’t in use, consider stopping your instance. It enters a “stopped” state, incurring no charges, but can be quickly restarted when needed.
2. Hibernation: For faster restarts, choose “stop-hibernate.” The instance’s state is saved to disk, enabling a near-instantaneous resume.
3. Termination: When you’re done with an instance permanently, terminate it. This releases resources and stops all charges. Remember, terminated instances are gone forever, so back up any critical data beforehand.

Phase 4: Understanding Costs

1. Billing: AWS charges you based on your instance type, running time, data transfer, and storage usage. Familiarize yourself with the pricing model to make informed decisions.
2. Cost Explorer: This tool provides detailed insights into your EC2 spending, helping you identify areas for optimization.
3. Reserved Instances and Spot Instances: Remember, these options offer significant cost savings compared to on-demand instances.

Bonus Tips:

• Leverage Auto Scaling to automate instance scaling based on predefined metrics, ensuring your resources adapt to changing demands.
• Explore AWS Trusted Advisor for personalized recommendations on optimizing your EC2 costs and resource utilization.

Remember: Mastering the EC2 instance lifecycle and costs is an ongoing journey. Experiment, monitor your usage, and leverage available tools to make informed decisions that keep your cloud environment efficient and budget-friendly.

By following these steps and exploring the mentioned resources, you’ll gain a solid understanding of EC2 instance management and navigate the cost landscape like a pro!

• One of the main reasons why EC2 provides so much value is the fact that you can provision new
  EC2 instances on demand, and just as easily, you
  can get rid of instances that you no longer need. In most cases, you only get charged for instances that are currently running. EC2 allows you to stop and
  start instances at will, which enables you to treat
  your fleet of EC two instances as elastic, scaling them in or out. Then at the end of the billing cycle, you only pay for what you use. We are building up to the
  idea of scaling your fleet of EC2 instances in and
  out to serve demand. But before we get there,
  it’s important to understand some of the more basic things about EC2. Let’s talk about the
  EC2 instance lifecycle. An Amazon EC2 instance transitions through different states from the moment you launch it
  through to its termination. You launch an EC2 instance from an AMI, and as you learned in a previous lesson, once the EC2 instance is launched, it enters a pending state. This state is essentially
  your VM booting up. Once the instance is ready for use, it enters the running state. In the running state, you will be charged for the EC2 instance. From running, you have a
  couple of different options. You can reboot the instance, which is similar to
  rebooting, say, your laptop. It turns off, then it turns back on again. Pretty straightforward. You can also choose to stop your instance. It will enter a stopping phase, then enter the stopped phase. Stopping an instance is like
  powering down your laptop. You can always turn it back on and it will go through
  its usual boot sequence, moving through the pending state and back to the running state. The other option, which
  is similar to stop, is to stop-hibernate your instance. This also enters the stopping phase and then the stopped phase. You can compare this to
  how you lock your laptop and shut the lid, but
  when you open it back up, everything is still in
  place where you left it. No boot sequences required. You are back up and running after a couple of seconds
  of the computer waking up. Since the state of the machine was written to memory when you stopped it, the state of the machine can be drawn from memory and put back into place. Then, you’re back up and running. Now, the last option depicted
  here is the terminate option. When you terminate an instance, it enters the shutting down phase then the terminated phase. Terminating an EC2 instance
  is like taking your laptop out for a long boat right off the coast and throwing it into the ocean,
  getting rid of it forever. It’s now lost in the great blue sea. There is no hope of finding your laptop on an island, shipwrecked
  one day, having been saved after spelling SOS in the sand. Anyways, I hope you had
  any data or state stored on that instance backed up because once you terminate an instance, it’s gone. That being said, there is a feature called termination protection that you can enable if you’re worried about instances being
  terminated accidentally. You also will learn about
  persistent storage and EC2 in future lessons, so don’t fret. We will show you ways you can make sure your data sticks around, even if the EC2 instance doesn’t. So that is the EC2 instance lifecycle. It’s definitely a good idea to remember how all of this works if you plan on using EC2
  to host your applications. And don’t think of terminating
  instances as a bad thing. If your EC2 instances is
  having technical trouble for one reason or another, maybe it needs an update or a patch, instead of logging into the instance to fix it or install software, you can launch a new one with
  the new changes in its place and then you could
  terminate the old instance, having a new instance take that place. You of course can do in
  place updates as well, but just know that you have the option to decide how to handle
  these sorts of tasks. You can launch or terminate
  EC2 instances to meet demand. So as demand for your
  application increases, you can launch more instances and as it decreases, you
  can terminate instances. This keeps your EC2 instance
  fleet in line with demand. So again, terminating an
  instance isn’t a bad thing and shouldn’t be feared. Now, let’s discuss the
  cost aspect of this. You only get charged for an EC2 instance if you’re in the running state or if you are in the stopping state when preparing to hibernate. This means that you can stop instances when they aren’t in use, say if you have applications
  that are only used during the work week. Run them when your
  employees are clocked in and then stop them when they aren’t. Remember, you can always
  start from a stop state, allowing them to resume
  working when necessary.

• [Instructor] Hello everyone. In this video, we are going to launch the
  employee directory application on an Amazon EC2 instance
  using the default VPC. So, you can see I’m
  already in the AWS console and I’m going to navigate
  to the EC2 dashboard. From here, I want to
  launch a new instance. So I’m going to select launch instance and then select launch instance again. And now this brings us to a page where we can
  provide the configurations for our EC2 instance. I’m gonna give this a name,
  employee directory app and then we can scroll down and we can view what
  AMI we want to choose. The AMI is the Amazon
  machine image, and this is a template that contains
  the software configuration for your instance on boot like the operating system, any sort of application server or any
  applications that you wanna have pre-installed when
  you launch your instance. We’re gonna be using the
  Amazon Linux 2023 AMI for this, though you could
  browse the AWS marketplace to get access to the
  different types of AMIs that vendors offer. So, if you’re using some sort of third party software
  that you want to launch on an EC2 instance, they
  might have an AMI out there that you could use to make
  your life a little bit simpler. You also can create and manage your own AMIs
  and share them internally within your organization
  to say you can only launch an EC2 instance using one of our approved AMIs that might
  have some specific security or compliant sort of
  packages pre-installed. That’s another option. So leaving the Amazon
  Linux 2023 AMI selected I’m going to scroll down and then we can select our instance type. The instance type will
  determine how much CPU, how much memory, what types of hardware is available
  to you on this instance. Some instances come
  with a GPU, for example. In this case, we are
  gonna use the free-tier eligible EC2 instance type, T2 micro which is the default that’s selected. So we’ll leave that the way it is. Then we can scroll down and select whether we want to use a key pair. The key pair is going to
  allow you to have access to this instance doing something like SSH. I’m going to select
  proceed without a key pair because if I need to
  connect to this instance, I’m gonna use the connect button in the AWS console where
  I don’t need to have a key pair to connect to this instance to view things like logs. Then scrolling down some more we then can configure
  our network settings. This is using a default
  VPC and a default subnet. This default VPC is going to have subnets that have internet access, so meaning that there is an internet gateway attached to this VPC that allows
  internet traffic to flow into this default VPC. You’ll learn more about VPCs
  coming up, but just understand that this default VPC does
  allow public internet access which is good for our use
  case, but might not be great for other use cases where you would more than likely put your
  instance behind something like a load balancer and then
  you would use private subnets. But we wanna be able to
  access this instance directly. So with that in mind, we’re going to use the default
  VPC and we’re also going to leave this auto-assigned
  public IP to enable and this will allow our
  EC2 incidents to have a publicly reachable IP address
  once it’s been launched. Then scrolling down a little bit more we have to configure our firewall. This is going to be our security group. Security groups are
  instance level firewalls. We want to disable traffic from SSH because we’re
  not going to need that. Then we’re going to allow
  HTTPS and allow HTTP. In our application, we’re
  gonna be using HTTP directly. Then scrolling down, we
  can configure some storage. We’re gonna leave our root volume here, but we’re not going to
  add any more EBS volumes. Then we can expand the
  advanced details section and then we need to select
  an IM instance profile. In this case, I’ll be selecting
  the employee web app role and this role has permissions attached to it to allow whoever’s
  using the role to make calls to S3 or to Dynamo DB. We know that our application has some code that’s running that’s going
  to be making API calls to S3 and Dynamo DB. We need to allow our AWS
  SDK to actually get access to these credentials, and
  the way that we do that is through this IM instance profile. So we’re associating this
  role with this instance profile that will allow
  our code to get access to these temporary credentials. Then scrolling down some more we will come to the user
  data section, and this is where you can provide a bash
  script that will run on launch. So, this script here is what’s
  gonna be used to download and install our application. Our application was
  written in Python using Flask as the web server,
  and this is going to be for our employee directory application. So on the first line,
  we are just declaring that this is a Bash script. Then we are using Wget to
  download a zip file from S3. So we hosted the zip file in an S3 bucket for this to be downloaded. Then we’re unzipping that,
  and then we’re changing directories into that new directory. Then we’re using Yum to
  install Python three and PIP. Then we’re using PIP to
  install any dependencies for our Flask application,
  which will all be listed in a file called requirements.txt,
  which got downloaded from this zip file. Then we’re installing a
  package called stress. This stress package is going
  to be used to simulate a CPU spike on this instance,
  which is going to allow us to simulate autoscaling
  whenever we use Amazon EC2 autoscaling in a future lesson. Then we have three different
  environment variables. One for our photos bucket,
  we’re gonna be using S3 to store our photos. We don’t have that
  value yet, so we’ll just leave this place holder there. Then we have the default
  region we’re operating out of Oregon, and then we
  have our Dynamo mode on and this means that we want our
  application to use Dynamo DB and then we’re running this
  application and hosting it on port 80. Now we can select launch
  instance, and this will begin to go build out the
  different things that we need like our security group and we can see that our
  instance has launched. Now if I select this instance ID, that brings us to a page
  where we can then select our instance and view
  some information about it. We can see things like
  our public IP address our private IP address,
  and our public DNS name. But we can’t access this directly yet. We can see that our
  instant state is running. But if I refresh this,
  you can see that we have some status checks that
  are still initializing. I wanna wait until both of
  these status checks have passed. So we’ll give this a few
  minutes and then we’ll come back once it’s ready. Okay, we’re back and we can see that our instant state is running and this status checks have passed. Now, if I select this instance again we can then open up our
  IP address in a new tab. All right, and we can see that our employee directory
  application has been opened in a new tab and we have an
  empty employee directory. This is exactly what we
  would expect at this point as we don’t have a place
  to store our photos or the employee information with our S3 bucket or Dynamo DB table. We’re gonna look at how to build out a
  custom network for this the S3 bucket and the Dynamo DB table and make all of this highly
  available in an upcoming lesson. So stay tuned.

• EC2 is great for all sorts
  of different use cases, from running basic web servers, to running high-performance
  computing clusters. That being said, though EC2 is incredibly
  flexible, reliable and scalable, depending on your use case, you might be looking at alternatives for your compute capacity. For example, let’s say
  you are looking for a way to run containers at scale on AWS. Containers can provide you with
  efficiency and portability. In this context, I am specifically referring to containers like docker containers or containers that use
  the containered runtime. If you aren’t sure what containers are, please review the readings on containers. Containers are portable because everything an
  application needs to run, including the application
  code, dependencies, and configuration are
  all packaged up together as one executable, which
  is the container itself. Since everything is self-contained, it means that you can
  expect your containers to behave the same way across
  different environments, like development, QA and production. AWS offers container services like Amazon Elastic Container Service, otherwise known as ECS, or Amazon Elastic Kubernetes Service, otherwise known as EKS. Both of these services are
  container orchestration tools. When you use containers on AWS, you need processes to
  start, stop, restart, and monitor containers running across, not just one EC2 instance, but a number of them
  together, called a cluster. The process of doing these tasks is called container orchestration. And turns out, it’s really
  hard to do on your own. If you have a few
  containers, it’s not so bad. But once you get to hundreds or thousands of containers
  you are managing, it can be quite complex. Orchestration tools were created to help you run and manage containers. ECS is designed to help you run your containerized
  applications at scale without the hassle of managing your own container
  orchestration software. EKS does essentially the same thing, but uses different tooling
  with different features. We aren’t going to go
  too much into this now. However, I did include a link
  to more learning resources around containerized applications on AWS in the readings following this video. The way you can interact
  with these container services is you manage the containers
  running on a cluster through the orchestration tool’s API. And then the orchestration tool carries out the management tasks. You can automate scaling of your cluster hosting your containers, as well as automate scaling
  of the containers themselves. Containers have a shorter boot-up time when compared to virtual machines. So if you need super fast
  response to increasing demand, then containers might
  be the service for you. Personally, I think the portability aspect that containers give
  are my favorite benefit of containerized applications. So you can choose to host containers on top of a cluster of EC2 instances as your hosting options
  either for ECS or EKS. However, what if you were
  looking for an alternative to hosting your containers, because you either don’t need
  access to the underlying OS, or you don’t want to
  manage those EC2 instances? Well, you can use a compute
  platform called AWS Fargate, which handles most of the
  underlying details for you. Fargate is a serverless compute
  platform for ECS and EKS. And we’ll talk more about what
  serverless is coming up next.

Navigating the Cloud: Choosing Your Compute Platform on AWS

When venturing into the vast landscape of AWS cloud computing, selecting the right platform for your needs is crucial. This tutorial explores two primary options: Amazon EC2 and serverless services, guiding you through the trade-offs between control and convenience.

Part 1: Understanding the Spectrum

Imagine a spectrum, with “control” on one end and “convenience” on the other. Each AWS service resides somewhere on this spectrum, catering to different priorities.

Part 2: Delving into EC2 – Control at Your Fingertips

• EC2 (Elastic Compute Cloud): Rent virtual servers (instances) with granular control over configuration, security, and scaling.
• Pros:
  • Ideal for complex setups requiring fine-grained customization.
  • Perfect for applications demanding full control over underlying infrastructure.
  • Offers flexibility to tailor solutions to specific needs.
• Cons:
  • Requires managing patches, scaling, and high availability (e.g., deploying across multiple zones).
  • Involves more operational overhead compared to serverless options.

Part 3: Embracing Convenience with Serverless Computing

• Serverless Services (e.g., AWS Lambda): Focus on your application logic, leaving infrastructure management to AWS.
• Pros:
  • Abstracted infrastructure eliminates tasks like server provisioning, scaling, and patching.
  • Faster development cycles and easier deployment due to reduced operational burden.
  • Cost-effective, as you only pay for resources used.
• Cons:
  • Limited control over underlying environment and instance configurations.
  • Might not be suitable for applications requiring deep customization or specific hardware access.

Part 4: Making the Choice – Control vs. Convenience

Carefully consider your priorities when selecting your platform:

• Control-centric: Choose EC2 if fine-grained control over every aspect is paramount for your application.
• Convenience-driven: Opt for serverless options if ease of use, rapid development, and minimal operational overhead are your primary concerns.

Part 5: Beyond the Basics – Additional Considerations

• Shared Responsibility Model: Understand AWS’s and your responsibilities for security and management (e.g., data encryption remains your responsibility in serverless).
• Cost Optimization: Evaluate costs associated with each option, considering factors like resource usage, instance types, and service pricing models.
• Hybrid Approaches: Explore combining EC2 and serverless for scenarios demanding specific control elements alongside serverless convenience.

Remember: The “best” platform depends on your unique requirements. Experiment, assess your needs, and don’t hesitate to consult AWS resources for further guidance. By understanding the control-convenience spectrum and carefully weighing your priorities, you’ll make an informed decision that empowers your cloud journey on AWS.

• When using Amazon EC2
  or container services running on top of EC2
  as a compute platform, you are required to set up and manage your fleet of instances. This means that you are
  responsible for patching your instances when new software packages or security updates come out, setting up the scaling of those instances, as well as ensuring
  that you’ve architected your solutions to be hosted
  in a highly available manner which means deploying instances
  across two AZs at a minimum as we discussed earlier. This is less management
  and operational overhead than you would have if you hosted the same
  solutions on premises but management processes will
  still need to be in place, and it’s your responsibility
  to create those processes to fit your use case. This is actually really
  great and in many use cases is exactly what you want because it gives you a
  great deal of control over your solutions. Whatever happens on your instances and with your instances is in your hands. You can create simple
  or complicated setups that run in scale on AWS
  exactly to your specification. That being said, not every single solution
  requires this level of control over the underlying environment. Oftentimes, you might
  be looking to focus on your own business solutions and let someone else take care of the undifferentiated
  heavy lifting for you. Or perhaps you just simply
  don’t want to fiddle around with scaling controls and
  fault tolerant designs but you still want all of
  the benefits of doing so. This is where the term
  serverless comes in. A lot of AWS services
  are serverless in nature. Serverless means that you cannot see or access the underlying infrastructure or instances that are
  hosting your solution. Instead, all of the management
  of the underlying environment from a provisioning,
  scaling, fault tolerance, and maintenance perspective
  are taken care of for you. All you need to do is
  focus on your application. The rest is taken care
  of, or more accurately the rest is abstracted from you. This means that serverless offerings are very convenient to use. You get to focus on the value
  that the service delivers and not the underlying
  implementation details thus reducing the number of
  operational support processes that you need to have in place. Remember the shared responsibility
  model that we covered in a previous lesson? This idea of serverless
  impacts that as well. For example, with Amazon EC2 instances, you are required to patch the OS when new security updates are released. With serverless offerings, the line between what
  you are responsible for versus what AWS is
  responsible for moves up. You do not have access to the
  underlying operating system that is running the service. Therefore, you cannot be responsible for carrying out tasks like patching. You are, however, still
  responsible for things like data encryption and access management. Let’s wrap this up. I like to think of AWS services
  as existing on a spectrum. On one side of the spectrum,
  you have convenience and on the other side, you have control. Many services exist to give
  you control like Amazon EC2 whereas other services exist
  to give you convenience, like the serverless compute AWS Lambda. We’ll dive deeper into some of these serverless compute technologies coming up.

Unleash the Power of Serverless Containers with AWS Fargate: A Step-by-Step Tutorial

Welcome to the world of simplified container management with AWS Fargate! This tutorial dives into the heart of Fargate, empowering you to leverage its serverless capabilities for efficient and scalable deployments.

Part 1: Understanding the Serverless Advantage

Imagine managing containers without worrying about EC2 instances, scaling, or infrastructure complexities. That’s the magic of Fargate! It frees you from operational burdens, letting you focus on building incredible applications.

Part 2: Getting Started with Fargate

1. Prepare Your Containers: Build and store your container images in a repository like Amazon Elastic Container Registry (ECR).
2. Define Your Needs: Determine the memory and CPU requirements (vCPU) for your containerized applications.
3. Choose Your Orchestrator: Decide whether to use Amazon ECS or EKS to manage your Fargate deployments.

Part 3: Deploying with Ease

1. Define Your Task or Pod: Configure your containers, network, storage, and scaling requirements within ECS or EKS.
2. Let Fargate Take Care: Sit back and relax! Fargate provisions, manages, and scales your infrastructure seamlessly.
3. Pay-as-You-Go: You only pay for the resources your containers use, maximizing cost efficiency.

Part 4: Advanced Features and Best Practices

• Spot and Savings Plans: Leverage cost-optimization options like Spot Instances and Savings Plans for even greater affordability.
• Security: Implement access control measures and container image scanning to ensure robust security.
• Monitoring and Logging: Utilize AWS CloudWatch to monitor your Fargate deployments and troubleshoot any issues.

Part 5: Real-World Use Cases

• Microservices Architecture: Scale your microservices independently with Fargate’s built-in autoscaling.
• Batch Processing: Run batch jobs efficiently without manually managing infrastructure.
• Machine Learning: Deploy ML models seamlessly with simplified infrastructure management.
• Cloud Migration: Move containerized applications from on-premises to the cloud effortlessly.

Bonus Tip: Explore the AWS Fargate console and documentation for more in-depth guidance and best practices. Remember, Fargate is just one piece of the serverless puzzle. Combine it with other AWS services for a truly powerful and efficient cloud journey.

By following these steps and embracing the serverless approach, you can unlock the full potential of AWS Fargate for managing your containerized applications with ease and efficiency. Get started today and experience the freedom of serverless container management!

• Now that you have learned
  about what container services AWS offers and what serverless means, let’s continue our
  conversation about containers. To recap, ECS or EKS is
  the container orchestrator. This is the tool that is managing
  the container’s lifecycle. Then you need the compute platform. This is where the containers actually run. Previously, you learned that ECS and EKS run containers on
  clusters of EC2 instances. And in that case, you were using EC2 as the compute platform
  for your containers, and you also have tight
  control over those instances. Now, EC2 is certainly not serverless. So thinking about serverless
  compute for containers, I want to introduce to you
  a service named AWS Fargate. AWS Fargate is a serverless
  compute platform for containers that you can use with either ECS or EKS. With AWS Fargate as the compute platform, you run your containers on a
  managed serverless platform. The scaling and fault
  tolerance is built-in, and you don’t need to worry about the underlying operating
  system or environment. Instead, you define your
  application content, networking, storage and
  scaling requirements. There is no provisioning, patching, cluster capacity management or infrastructure management required. To break that down a bit,
  the way you work with Fargate is you first build your container images and push them into a repository like Amazon Elastic Container
  Registry, for example. Which is a place where you
  can store container images for them to be pulled and deployed from. So you have your container
  images in your repo, and then you define memory
  and compute resources for your task if you’re
  using ECS or your pod if you’re using EKS. Then you run your containers. And at the end, you only
  pay for the amount of vCPU, memory and storage resources consumed by your
  containerized applications. Fargate does support spot and compute savings plan pricing options just like with Amazon EC2 instances. So there is some flexibility on how you plan to run
  containers on Fargate. So you can still get a
  good amount of control for your container’s
  deployment, but without needing to worry about the provisioning, patching and managing the underlying
  operating systems or instances. And no need to scale the
  infrastructure in and out to meet demand like you do with EC2. As far as use cases go,
  AWS Fargate can be used for all of the common container use cases including microservice
  architecture applications, batch processing, machine
  learning applications and migrating on-premises
  applications to the cloud. All right, hopefully, you now have a 10,000-foot
  view of AWS Fargate. You can see how Fargate is
  an example of how serverless simplifies your operations and management for running scaled container solutions.

Step into the Serverless Zone: Building Efficient Workflows with AWS Lambda

Are you ready to ditch server management and focus on pure coding magic? Then join me on an exploration of AWS Lambda, the serverless compute service that takes care of the infrastructure while you unleash your code’s potential. Buckle up for a tutorial that guides you through building efficient processing workflows with Lambda!

Part 1: Demystifying Serverless with Lambda

Imagine a world where you write code, define triggers, and let AWS handle the rest. That’s the beauty of Lambda! It’s a serverless compute service that runs your code in response to events, eliminating the need for server provisioning, scaling, and maintenance.

Part 2: Putting Power in Your Code’s Hands

• Packaging Your Code: Craft your code as a Lambda function, choosing from popular languages like Python, Node.js, Java, and more. Think of it as a self-contained unit ready for action!
• Triggering the Action: Define what sparks your function’s execution. A plethora of triggers are available, from HTTP requests and file uploads to events from other AWS services. It’s like setting the stage for your code to shine!
• Scaling on Demand: No need to worry about server capacity; Lambda automatically scales your function up or down based on incoming triggers. Focus on your code, and let the infrastructure adapt seamlessly.
• Paying Only for What You Use: Unlike traditional servers, you only pay for the resources your code consumes during execution. It’s a pay-per-use model that rewards efficiency!

Part 3: Diving into a Real-World Example – The Photo Resizer

Let’s put theory into practice by building a Lambda function that resizes images uploaded to an S3 bucket.

1. Create the Function: Choose your preferred language and name your function (e.g., “PhotoResizer”).
2. Write the Code: Implement the image resizing logic using your chosen language’s libraries.
3. Connect the Trigger: Set up an S3 trigger that fires your function whenever a new image is uploaded to a specific folder.
4. Define the Output: Specify where the resized image should be saved within the S3 bucket.
5. Test and Deploy: Upload a test image, trigger the function, and verify the resized image appears in the designated location. Congratulations, you’ve built your first serverless workflow!

Part 4: Exploring the Vast Potential

While our photo resizer was a simple example, Lambda’s capabilities extend far beyond. Use it for:

• Web backends: Handle API requests and process data behind your web applications.
• Microservices: Architect smaller, independent services that communicate seamlessly.
• Data processing: Clean, transform, and analyze data triggered by events.
• Scheduled tasks: Execute periodic jobs like sending reports or updating databases.

Remember: Lambda is not a one-size-fits-all solution. It excels at short-lived tasks and event-driven workloads. For long-running processes, consider other AWS services like EC2.

Bonus Tip: Explore tools like AWS Serverless Application Model (SAM) to simplify building and deploying serverless applications on Lambda.

By embracing the serverless approach with Lambda, you’ll unlock a world of efficient code execution, scalable infrastructure, and cost-effective solutions. So, start building and experience the freedom of serverless computing!

• AWS Lambda is one of the
  serverless compute options you have available to you on AWS. Lambda allows you to package and upload your code
  to the Lambda service, creating what is called a Lambda function. Once you create a Lambda function, it isn’t always running all of the time. Instead, Lambda functions
  run in response to triggers. You can configure a trigger for when you want your function to run, and from there the Lambda
  service waits for the trigger or polls for an event
  to trigger the function depending on what the
  trigger is that you choose. There’s a long list of available
  triggers for AWS Lambda, and new ones are being
  supported all of the time, so I won’t run through them all now. However, a couple of common examples of triggers for Lambda functions are an HTTP request, an upload of a file to the storage service Amazon S3, events originating from
  other AWS services, or even in-app activity
  from mobile devices. When the trigger is detected, the code is automatically
  run in a managed environment, an environment that you do not
  need to worry too much about because it is automatically scalable, highly available, and
  all of the maintenance of the environment itself is done by AWS. You do, however, get
  to choose the language your Lambda function is coded in, the amount of memory and CPU your function is allocated
  in the environment, permissions, dependencies, and many other aspects
  of how the function runs. If you have 1 or 1,000 incoming triggers AWS Lambda will scale your
  function to meet demand, each in its own isolated environment. Lambda is currently designed to run code that has a runtime of under 15 minutes. So this isn’t for long running processes like deep learning or batch jobs. You wouldn’t host something like a WordPress site on AWS Lambda. It’s more suited for quick processing like a web backend handling request, or a backend report processing service or microservice hosting. One of the best things about Lambda is that you aren’t billed
  for code that isn’t running. You only get billed for
  the resources that you use rounded up to the nearest
  one millisecond interval. To understand Lambda more thoroughly, let’s run through a quick demo. In this demo, I will
  create a Lambda function that resizes images uploaded
  into the employee directory to be uniform thumbnail size. It makes sense to create
  this sort of logic with a Lambda function. You don’t need an application
  to be running 24/7 on EC2 to resize photos uploaded
  to the application. You really only need
  to run the resize logic when a new photo is uploaded. So here’s our diagram for the app. What I want to do here is when a new photo is uploaded to S3, it triggers a Lambda function that then resizes the image and uploads it into that same S3 bucket, but to a different location than where the original image is stored. All right, let’s go
  ahead and build this out. You can see that I’m already
  in the AWS Lambda console and I’m going to first
  click Create function. Next, we get to select
  what type of function we want to build. Do we want to author a
  function from scratch? Do we want to use a blueprint which will give you some sample code and configuration presets? Or you can use a container
  image with AWS Lambda as Lambda does support running containers. We are going to author
  a function from scratch. For the function name, we will call this ResizeImage, and then we get to select the runtime. The runtime is the language that your Lambda function is written in, because with Lambda, it runs in the Lambda environment, but it’s still your code. So I’m gonna go ahead and
  select Python 3.9 for this as we wrote this function in Python. And then we have to
  select the permissions. And the permissions are
  going to be delegated to the function through IAM roles. So I’m gonna click Use an existing role, and then if I expand this dropdown, we can select LambdaS3FullAccess which is an IAM role that I’ve already created in this account that will give this function permissions to read and write from S3. Now we can scroll down and
  select Create function. Now we can add a trigger
  for this Lambda function, and I’ll select Add trigger. And here we get to configure
  the trigger source, and if we expand this dropdown, you can see a list of AWS services that can act as triggers like API Gateway, an Application Load Balancer, DynamoDB. We’re going to scroll down and select S3 for our trigger. And then we need to select which S3 bucket will be the event source. I already have an S3 bucket
  created in this account called photo-upload-bucket-mw, we’ll select that one. And then if we scroll down, I’m going to select the event type. I want to select only a PUT, so I want PUT operations to trigger this AWS Lambda function. Then we can provide a prefix. With this prefix, what we’re essentially
  doing is we’re going to say: I only want to trigger
  this Lambda function if a PUT occurs in a specific location inside of this bucket. We’re going to upload
  photos to an input prefix and that will then trigger
  the Lambda function. We then need to acknowledge that if we’re using the same S3 bucket for both input and output that it could cause recursive invocations. So the way that we’re getting around that is by supplying this input prefix, the event will be triggered when an image is uploaded to this prefix, but then the output will
  actually be uploaded to a different location. We’ll have an output prefix where the image will be uploaded to. So we’re gonna go ahead and acknowledge by checking this checkbox
  and then click Add. Now back on our Function overview page, what we need to do next is actually upload the code for this. So if we scroll down, we
  can select the Code tab, and then you can see that there’s a stubbed
  out Lambda function here that essentially just says, “Hello world, hello from Lambda.” And what we need to do is upload our code. So I’m going to click Upload from, and then select zip file. Click Upload, and then I will
  select this ResizeImage.zip, click Open, and then click Save. All right, our function has
  been successfully created. We have our trigger defined, and we have our code uploaded. What I want to do now is test this out by actually uploading an image to S3 and then viewing the output. So in the search bar, I’ll type in S3 and then select S3. Then from here we’ll select the bucket, and then we’ll go into the input folder and then select Upload, click Add files, and then
  I’ll upload Seph’s image, and select Open, and then Upload. We can see that that
  upload was successful. So now if we go check,
  we should see the output with the thumbnail version of that image. So now going back into our bucket, if we go up one level, we can now see that the output
  prefix has been created, so I’ll select that, and we can see that the thumbnail image was created. And that’s it, that’s how you create an AWS Lambda function. You could host the entire employee directory
  applications backend on Lambda with some refactoring,
  but I’m gonna go ahead and save that for a later conversation.

• At this point, you’ve covered a few different
  AWS compute services. The services covered so far can handle a wide variety of use cases. So how do you know when to use each one? To figure that out, I think
  it’s time to play a game. (playful music) Welcome to the “Which AWS Compute Service Should I Choose For My
  Use Case?” game show. We are your hosts and
  you are the contestant. (playful music) – We will present three
  different use cases that require compute on AWS, and it’s up to you to
  choose the right service for the use case. You’ll have five seconds
  to answer each question. Ready? – I’m ready and I hope you are, too. Let’s do it. First question is up. Consider a scenario
  where you are a developer who is tasked with creating a new feature for a web application being hosted on EC2. The web application is an online store. And right now, all the items
  being sold in the store are loaded into a database
  manually behind the scenes. By manually, I mean there is a person who adds a new row to a database for each new item to be sold in the store. This process takes a long time, isn’t very scalable,
  and is prone to error. You are tasked with automating the process of getting the new item information loaded into the inventory database. The goal is to have a person upload an inventory
  spreadsheet into Amazon S3, the object storage service, then have a process
  automatically load the data into the inventory database. What compute would you use
  to host the processing logic to load the items from the
  file into the database? Five seconds on the clock. (clock ticking) – All right, let’s discuss how you could have answered this question. You could have decided
  to use Amazon EC2 here. You could spin up a new instance specifically for this process and write some code that polls the location of the spreadsheet for a new upload every so often. Updating the database
  when it finds a new file, that would work, but before I make my final
  answer here, I have a question. How often does new inventory
  get added to the database? – New inventory gets
  updated once a quarter. – Good to know. So it’s not very often, which means this process
  would only run once a quarter and that does change my answer. Here’s why. Amazon EC2 charges per second or per hour. So if I have an instance
  running all the time to serve requests that
  happens once per quarter, that seems like a lost
  opportunity to optimize for cost. I would be spending money
  on a resource I rarely use. It certainly would work, but it may not be the best
  fit for this use case. I could automate the process of starting and stopping
  the instance when needed. But instead, what about using AWS Lambda? – Bingo. AWS Lambda is the correct
  answer for this one. There are a few reasons. First of all, to address
  your concern on cost, AWS Lambda only charges you
  for the compute you consume when the code is actually running. And code is only run in response to triggers
  or a direct invitation. So here’s my suggestion. You know that the goal is to have someone upload
  an inventory document to S3, which should kick off the
  process of updating the database. You also learned that
  AWS Lambda has triggers that run your Lambda functions code. AWS Lambda integrates
  with many AWS services to act as triggers, and Amazon S3 is one of them. So my suggestion would be to
  create an AWS Lambda function; configure a PutEvent as
  the trigger from Amazon S3; then when the inventory is uploaded, Amazon S3 will trigger
  the Lambda function to run and the code in the function will parse the inventory document and add each item to the database. – [Instructor] Okay, great. Time for the next question. Let’s say you have an
  application currently hosted in your on-premises data center, which needs to be migrated to AWS. It’s currently running on Linux
  servers in the data center, and you want to minimize the
  amount of refactoring needed to migrate to AWS. It’s important that
  this workload is elastic and can support varying demand. What compute option would you choose? Five seconds on the clock. (clock ticking) – Time’s up. Now, I’ll go over the answer. Considering the fact that
  minimizing refactoring is an important aspect of this workload, I would architect a solution using Amazon EC2 as the compute service. EC2 instances can be launched
  from Linux-based AMIs, and the application could be
  hosted on the EC2 instance the same way it would be hosted on a Linux server on premises. Amazon EC2 also has the ability to scale in or out based on demand, so I think EC2 is the
  best service for this one. – That’s correct. So if you answered EC2 at home, good work. Before we move on to the final question, let’s dive into this answer a little more. Morgan, can you explain
  the thought process behind eliminating the other
  compute services we covered in the answers to this question? – Sure thing. So AWS Lambda could work, but you can’t just upload the same code you would run on Amazon
  EC2 into a Lambda function. There would have to be a
  decent amount of refactoring in order to take
  advantage of that service. Same idea with any of the
  AWS container services, like ECS or EKS. Again, you’d have some
  amount of rework required to migrate to containers. Therefore, Amazon EC2 is the best option for this migration. Now, time for one final use case, and this one is for all the marbles. Imagine a scenario where you are planning to write a brand-new application using a microservices or
  service-oriented design. And you want to architect the application where it can scale up or down quickly, and you want to lower the risk of deploying new changes to production. Which AWS compute service would you use? Five seconds. (clock ticking) – Okay, time’s up. The answer for this use case is… One of the AWS container services like Amazon ECS or Amazon EKS. – Correct. The answer is either
  ECS or EKS for this one because using containers makes it easier to support microservice or service-oriented designs. Containers boot up quickly, so scaling is quicker than EC2 instances, and the use of containers
  helps with code portability. Meaning, if I write the code on my laptop and run it in a container, test it in QA in a container, I can then expect the same container to behave the same way once
  deployed to production, thus reducing the risk of
  deployments causing errors because of environmental issues. – All right, there you have it. Different use cases for a few
  of the AWS compute services. Make sure you read up on
  AWS’s other compute offerings and make informed decisions when architecting your solutions. You’ll find there are a lot of options. – Remembering that these services exist to best suit different use cases helps. Don’t try to use the same compute service for all of your use cases. Instead, pick the right one for the job and consider reevaluating
  choices for existing workloads as AWS continues to release
  and improve offerings. (playful music)

Understanding VPCs for Secure AWS Applications: A Step-by-Step Tutorial

In this tutorial, you’ll learn how to create and configure a secure Virtual Private Cloud (VPC) on Amazon Web Services (AWS) for your applications. By using a custom VPC instead of the default option, you can achieve better security and more granular control over internet access for your resources.

Prerequisites:

• An AWS account with basic understanding of the AWS Management Console.
• Familiarity with basic networking concepts like IP addresses, subnets, and firewalls.

Steps:

1. Understanding Default VPCs:

• AWS automatically creates a default VPC in each region you use.
• These VPCs are designed for quick and easy deployment of EC2 instances with public internet access.
• Security concern: Resources in default VPCs are directly exposed to the internet, increasing vulnerability.

2. Creating a Custom VPC:

• Go to the VPC Console in the AWS Management Console.
• Click on Create VPC.
• Choose a VPC name and CIDR block (e.g., 10.0.0.0/16).
• Select the region where you want your VPC to reside.
• Click Create.

3. Creating Subnets:

• Subnets divide your VPC into smaller, isolated networks.
• Create two subnets:
  • Public subnet: With a public route table, allowing internet access for specific resources.
  • Private subnet: Without a public route table, restricting internet access for sensitive resources.
• In the VPC Console, select your VPC and click on Subnets.
• Click on Create subnet.
• Choose a subnet name, CIDR block within your VPC’s CIDR block (e.g., 10.0.1.0/24 for public subnet), and Availability Zone.
• Select Yes for “Map Public IPv4 address” for the public subnet.
• Repeat the process for your private subnet, selecting No for “Map Public IPv4 address”.

4. Configuring Route Tables:

• Route tables determine how traffic flows within your VPC and to the internet.
• Create two route tables:
  • Public route table: With a route to the internet gateway (allows outbound traffic).
  • Private route table: No internet gateway (restricts outbound traffic).
• In the VPC Console, select your VPC and click on Route tables.
• Click on Create route table.
• Choose a name and VPC for the route table.
• For the public route table, add a route with a destination of “0.0.0.0/0” and target the internet gateway (created automatically by AWS).
• For the private route table, leave it empty (no internet access).

5. Associating Subnets with Route Tables:

• Associate your public subnet with the public route table and your private subnet with the private route table.
• In the VPC Console, select your VPC and click on Subnets.
• Select your subnet and click on Edit subnet association.
• Choose the appropriate route table and save the changes.

6. Launching an Instance in your VPC:

• Now you can launch an EC2 instance in your secure VPC.
• When choosing a subnet, select the appropriate one based on your desired internet access (public or private).
• Configure security groups to further control inbound and outbound traffic for your instance.

7. Additional Considerations:

• You can add additional features to your VPC, such as:
  • Internet Gateways: For controlled outbound internet access.
  • NAT Gateways: Allow private subnets to access the internet without public IP addresses.
  • Security Groups: Define firewall rules for inbound and outbound traffic at the instance level.
• Remember to apply the principle of least privilege when configuring network access.

Congratulations! You’ve now created a secure and flexible VPC for your AWS applications.

Further Resources:

• AWS VPC Documentation: https://docs.aws.amazon.com/vpc/
• VPC Best Practices: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html
• AWS Networking Blog: https://aws.amazon.com/blogs/networking-and-content-delivery/

By following these steps and exploring the provided resources, you’ll gain a solid understanding of VPCs and their role in securing your AWS applications. Remember, security is an ongoing process, so keep learning and refining your VPC configurations as your needs evolve.

• Looking back at the architecture
  diagram for application the part we want to focus on
  for this section of the course is this part, the network or VPC, and its many components. But before we dive into networking on AWS, let’s first put this into context. In a lesson you saw earlier,
  we launched an instance and connected to that
  instance over the internet but to launch this instance,
  we needed to select a network. How you configure this
  network or VPC is actually what helps enable internet traffic to flow into your application. You might be asking, Seph, how did we select a VPC
  when we haven’t even built a VPC yet? You’re right, we haven’t built a VPC, but fortunately AWS creates VPCs for us in every region by default. When we launched our EC2
  instances earlier in the course we simply chose the default VPC. These default VPCs are
  meant to provide an easy way for you to get started
  with EC2 instances quickly and view your applications
  over the internet. However, you have to be careful with what you put inside
  of these default VPCs, as those resources will be
  subject to well, the internet. And with internet access
  comes potential dangers. If we didn’t select this default VPC, we would’ve needed to select
  a VPC that we custom-built. In this section of the course we’ll focus on doing just that, building a custom VPC for our application that is more secure and provides more granular
  access to the internet than the default option
  we originally chose. While viewing this section, keep in mind that this information is geared towards EC2-related services. If you are using a
  different kind of compute, such as a lambda function, you might not need a network at all. However, that doesn’t
  mean this isn’t important. Networking on AWS is the
  basis of most architectures, so consider this
  information highly valuable. Coming up, we’ll dive into
  some key VPC concepts, but for now, take some time
  to review the upcoming notes, which will cover some
  important networking basics that you should know before
  jumping into networking on AWS.

• In this video, you’ll be learning how to
  create a VPC with Morgan’s help. We’ll both be conceptualizing and building a VPC throughout
  the next few videos. The idea of a VPC is similar to how you think of walls
  around a data center. In a data center, walls act as a boundary between the outside world and
  all of your infrastructure. A VPC in AWS acts the same way. It creates a boundary where your applications and resources are isolated from any outside movement, so nothing comes into the VPC and nothing comes out of the VPC without your explicit permission. When you create a VPC, you have to declare two specific settings; the region you’re selecting, and the IP range for the VPC
  in the form of CIDR notation. (notification dings)
  For our VPC, we’ll be locating it in the region where the rest of our
  infrastructure will be, the Oregon region. and our IP range will say is 10.1.0.0/16. Alright, so currently our
  VPC looks just like a box. Time to build the VPC. (swoosh effect)
  Okay, Morgan, let’s build out a VPC for
  the Employee Directory app. I was hoping you could build us a VPC that matches this diagram. – Sure, let’s do it. If you’re looking at the
  console, you’ll first check to make sure that you’re
  in the correct region by clicking on the
  upper right hand corner. Seph mentioned we’re going to
  run out of the Oregon region, so we’ll go ahead and make
  sure that this says Oregon. Once we choose the right region, we can now build our network. You’ll type in VPC in
  the service search bar and that’ll bring up your VPC
  dashboard for this region. From there, you’ll click your
  VPCs and then Create VPC. Now we’ll have a few
  settings to configure. We’ll put in the CIDR
  block, which is 10.1.0.0/16, and the VPC name, which
  we’ll say is app-vpc. We’ll leave the rest as default, and then we’ll click Create VPC. Easy as that. Okay, Seph, what’s next? – Nice, that was fast. After you create your VPC, you then divide the space inside the VPC into smaller segments called subnets. You put your resources,
  such as your EC2 instances, inside of these subnets. The goal of these subnets is to provide more granular control over access to your resources. So if I have public resources, like our Employee Directory app, that we want to be
  accessed over the internet, I could put these resources inside a subnet with
  internet connectivity. If I have more private
  resources, like a database, I could create another subnet and have different controls to
  keep those resources private. To create a subnet, you
  need three main things; the VPC you want your subnet
  to live in, which is this one, the AZ you want your subnet to live in. In this case, we’ll choose AZ A, or in other words us-west-2a, and then the CIDR range for your subnet, which must be a subset
  of the VPC CIDR range. For this, we’ll choose
  the range 10.1.1.0/24. We’ll call this our Public Subnet for public facing resources. Then we’ll create another subnet
  for our private resources. We’ll place it in the same AZ, specify a different
  non-overlapping CIDR range, say 10.1.3.0/4, and then name it our Private Subnet. Alright, now that we’ve got
  two subnets added to our VPC, it’s time to put Morgan to the test again and have her build these out. And this time I’m timing her. – All right, we’re on a time limit here, so let’s create these subnets. Let’s go ahead and start
  creating the public subnet. Back in the console, we’ll click on Subnets in the side panel, and then select Create subnet. Then we’ll select the
  VPC we’re working with, in this case is app-vpc. Once you do that, you’ll be
  prompted to provide a name. We’ll say this one is Public Subnet 1. Then we’ll choose the AZ, which Seph mentioned was us-west-2a, and then the CIDR range
  will be 10.1.1.0/24. We’ll leave the rest as defaults, scroll down to the bottom,
  and click Add new subnet. We’ll now repeat the same
  steps for our private subnet. Give it a name such as Private Subnet 1. Put it in the same
  availability zone, us-west-2a, and then type in the CIDR range, which is 10.1.3.0/24. Now we can click Create subnet, and both subnets will be created. All right, Seph, what was my time? – That was so fast that my
  watch didn’t even register it. (swoosh effect)
  Okay, moving on. As we mentioned earlier,
  when you create a new VPC, all the resources you
  put in it are isolated, and only have access to other resources in that VPC by default. For websites like our corporate
  directory application, we want users to access
  our site over the internet. To enable internet connectivity, we need a component called
  an internet gateway. Think of this gateway
  as similar to a modem. Just as a modem connects your
  computer to the internet, the internet gateway connects
  your VPC to the internet. When you create an internet gateway, you then need to attach it to your VPC. If you create an internet
  gateway and don’t attach it, it won’t do anything except sit there. (swoosh effect)
  Okay, Morgan, show us how it’s done. Create an internet gateway
  and attach it to our VPC. – Okay. Back in the VPC dashboard, you’ll click on Internet
  gateways on the side panel, then Create internet gateway. You’ll give the internet gateway a name, and then click Create. On the details page, you’ll then select the
  Actions dropdown box and select Attach to VPC. Choose the app-vpc
  we’ve been working with, and then click Attach. Okay, Seph, what’s next? – Oh, sorry, I thought I’d
  have more time to drink my tea. So we have an internet gateway that we can use to allow
  access from the internet, but what if we had a VPC with
  all internal private resources that we want to reach only from
  our on-premises data center? If we only want traffic
  to flow between AWS and our data center, and we don’t want to allow
  direct access from the internet, what do we do? Luckily, there’s another gateway
  designed for this very purpose called a virtual private gateway or VGW. It allows you to create a VPN connection between a private network,
  like an on-premises data center or internal corporate
  network, to your VPC. With the help of a VGW, you can establish an
  encrypted VPN connection to your private internal AWS resources. We won’t be using a
  VGW for our application but it’s good to know. We’ll talk more about that
  in an upcoming lesson. Alright, so we have one VPC, two subnets, and an internet gateway. Now, every time you
  look at an architecture, you should begin to think,
  how do I make this better? You’re not going to have all
  of the answers right away, but I do want you to take 10 seconds and think about some solutions. (light jazz music) Okay, well, one option to make this better is the idea of having high availability. What that means is if this AZ
  goes down for whatever reason, what happens to our resources in that AZ? They go down too. So ideally we would have
  resources in another AZ to take on the traffic
  coming to our application. To do this, we’d need to
  duplicate the resources in the first AZ to the second AZ, so that means we’d need to create
  two additional subnets, each within another AZ, say AZ B. As a best practice, you should always be
  using at least two AZs, and hosting your resources redundantly. Morgan is going to build out some subnets in another AZ in the background
  for the rest of our demos. She’s also going to launch an EC2 instance hosting our application in
  one of the public subnets. Sound good, Morgan? – Sounds good. Okay, we’ll see you in an upcoming video. This time with one VPC,
  four subnets across two AZs, and one running EC2 instance.

• Let’s take a look at
  our current VPC state. In the last video, we left off with a VPC with an internet gateway attached to it, and two subnets one public, one private, and one availability zone. However, Morgan was kind enough to build additional
  resources in the background to make sure our application
  was highly available. So now we have two additional subnets, one public, one private,
  and a different AZ for a total of four subnets. She also created an EC2 instance hosting our employee directory inside of the public subnet in AZ A. But we are missing one
  large component here. Say we have a user and
  that user wants to access our employee directory. Eventually that internet traffic would flow through the internet gateway, but then where would it go? Just because the traffic entered through the door of the VPC it doesn’t mean it ever
  made it to the right room. What we need to do is to provide a path for the internet traffic,
  not only to enter the door but also make sure traffic
  reaches the right room or in other words, enter
  the internet gateway and then find the right subnet. The way we provide that path
  is through route tables. A route table contains a
  set of rules called routes that are used to determine where the network traffic is directed. These route tables can be applied at either the subnet
  level or at the VPC level. When you create a brand new VPC, AWS creates a route table
  called the main route table and applies it to the entire VPC. AWS assumes that when you
  create a new VPC with subnets you want traffic to flow
  between those subnets. In the last video when we talked
  about VPCs being isolated, this is what we meant. The default configuration
  of the main route table is to allow traffic between
  all subnets local to the VPC. Let’s get a quick look
  at the main route table of the VPC we just built out
  in the last video for that. Let’s get Morgan out here. – Hey, I understand that
  you wanna take a look at the main route table for the VPC. – That’s right. Can you
  walk us through that? – Yeah, let’s go ahead and take a look. In the VPC console, we’ll
  click on route tables on the side panel and it will bring up all of the route tables
  that exist in this region. If we scroll to the side, we can see the main
  column and the VPC column. We’re going to look for
  the main route table for the app VPC, which is this one. When we click on it, we can
  bring up the bottom panel and then click on routes. Here we can see the local route that has the destination of the VPC range. This means that all of the
  components inside of our VPC can communicate with one
  another locally by default. This local route will be present in every route table that you create. Alright, that’s the main route table. – While the main route
  table controls the routing for your entire VPC, you
  may want to be more granular about how you route your
  traffic to specific subnets. Remember when we mentioned
  that subnets can be used to group your resources together based on whether they are
  publicly or privately accessible? Well, the subnet itself
  doesn’t provide that access. Whether a subnet has access
  to the public internet or not, depends on its associated route table. If a route from the internet
  gateway to the subnet exists, it has public access. If the route table doesn’t have a route between the subnet and
  the internet gateway then it doesn’t have public access. So we call subnets public or private but it’s really the route table
  that provides that access. So for your subnets, you’ll
  create custom route tables. Inside these custom route tables, you’ll have that default
  local route inside of it that allows traffic to
  flow freely within the VPC but then you’ll need to
  create additional routes. So the subnet with the
  internet facing resource in this case, our EC2 instance with the employee directory website on it, will need a route to the internet gateway. So that means, Morgan,
  we need your help again. Do you mind creating a custom route table and associating it to our public subnet? – Sure can. Let’s get started. Let’s create the route
  table for our public subnet. Back in the VPC console once again, we’ll click on Route
  tables on the side panel and then Create route table. We’ll give it a name such
  as app-routetable-public, choose the app-vpc, and then click Create. Our route table has been
  created, but we’re not done yet. We still have to edit the routes to allow traffic to flow
  from the internet gateway. To do this, we’ll click on
  the ID of the route table and then go to the route section in the bottom of the summary table. We’ll click Edit routes, Add route, put 0.0.0.0/0
  for the destination, meaning it can take and
  deliver traffic from anywhere and then specify the target
  as an internet gateway. This will bring up
  available internet gateways to attach it to and from here,
  we’ll select the app IGW. We’re done with the routes,
  so we’ll click Save. But how do you know which subnet this route table applies to? Well, we have to configure that. If we only want this route table to apply to our public subnets, we’ll need to associate it with
  our two public subnets only. To do this, we’ll click on
  the Subnet associations tab. Select Edit subnet associations and choose the public
  subnets we created earlier. Then click Save. Alright, we’ve hooked
  up our public subnets to a route table that
  allows internet traffic from the IGW to our employee
  directory application. If we wanted to create a route table for the private subnets, we
  would follow the same steps. Create the route table,
  make sure there’s no route to the internet gateway this time and then associated to
  the private subnets. Okay, now we’ve configured a
  route to the internet gateway and we’ll configure additional
  firewall rules later on. – Nice. So this is our final state of the diagram. One VPC, four subnets,
  one public, one private in both availability zones. Our two public subnets are associated with a route table that allows traffic from the internet gateway. Our private subnets
  don’t have a route table associated to them yet, so they follow the rules
  of the main route table, local traffic only.

Securing Your VPC: A Tutorial on Network ACLs vs. Security Groups

Protecting your Amazon Virtual Private Cloud (VPC) is crucial for safeguarding sensitive data and applications. This tutorial delves into two key security features – Network Access Control Lists (ACLs) and Security Groups – to guide you in securing your VPC effectively.

Understanding the Threats:

Before diving into specifics, let’s understand the potential risks:

• Unauthorized access: Malicious actors might try to access your resources through open ports or vulnerabilities.
• Data breaches: Sensitive data leaks can occur due to insufficient security measures.
• Denial-of-service attacks: Overwhelming your resources with traffic can disrupt operations.

Securing Your VPC:

Now, let’s explore the two main tools at your disposal:

1. Network Access Control Lists (ACLs):

• Think of them as firewalls at the subnet level.
• Control inbound and outbound traffic to the entire subnet.
• Default configuration allows all traffic, but you can create customized rules:
  • Allow rules: Specify permitted traffic (e.g., HTTPS on port 443).
  • Deny rules: Block unwanted traffic (e.g., all traffic except HTTPS).
• Stateless: Require both inbound and outbound rules for specific protocols.

2. Security Groups:

• Firewalls attached to individual EC2 instances.
• Mandatory for every EC2 instance.
• Default configuration blocks all inbound traffic and allows outbound traffic.
• Stateful: Remember connection initiation, allowing responses without an outbound rule.
• Limited to allow rules only.

Choosing the Right Approach:

The best approach depends on your specific needs:

• Convenience: For basic control, use security groups with default ACLs.
• Fine-grained control: Configure ACLs further for stricter security measures.

Tutorial Steps:

1. Identify your security needs: Consider factors like application requirements, sensitivity of data, and compliance regulations.
2. Choose your approach: Decide whether to prioritize convenience or granular control.
3. Configure security groups:
   • Define inbound rules for allowed traffic based on your application’s ports and protocols.
   • Remember, outbound traffic is generally allowed by default.
4. Configure network ACLs (optional):
   • If needed, create allow/deny rules to further restrict traffic at the subnet level.
5. Test and refine: Thoroughly test your configurations to ensure they function as intended and adjust rules as needed.

Additional Tips:

• Follow the principle of least privilege: Only allow the minimum necessary traffic.
• Keep security groups and ACLs updated: Regularly review and adjust rules as your application and needs evolve.
• Monitor your VPC: Use VPC flow logs and other monitoring tools to detect suspicious activity.
• Utilize additional security measures: Consider IAM roles, encryption, and other AWS security services for comprehensive protection.

By understanding and effectively utilizing Network ACLs and Security Groups, you can build a secure and resilient VPC that safeguards your valuable assets.

Remember: Security is an ongoing process. Continuously evaluate your security posture and adapt your defenses to stay ahead of evolving threats.

• Now we have a complete network that enables internet traffic
  flow to our public subnet. But how do we know it’s secure? Well, at the base level, we know that any new VPC is isolated from internet traffic,
  so that prevents risk. But when you start
  allowing internet traffic by opening up routes, you need other options to
  keep your network secure. In AWS, you have two options
  to secure your VPC resources, network access control lists, often referred to as network
  ACLs, and security groups. We’ll start with network ACLs. You can think of a network ACL as a firewall at the subnet level. With network ACLs, you can
  control what kind of traffic is allowed to enter and leave your subnet. So if I were to draw
  network ACLs in our diagram, they are placed around each
  of our subnets by default. The default network ACL allows traffic in and out of your subnet. Using this default configuration
  is a good starting place but if needed, you can
  change the configurations of your network ACLs to
  further lock down your subnets. For example, if I only
  wanted to allow HTTPS traffic into my subnet, I can do that. I can create a rule in my
  ACL that allows HTTPS traffic from anywhere on port 443
  and denies everything else. However, just because I
  allow inbound HTTPS traffic does not mean my job is done. If I don’t open up the
  corresponding outbound port used for the protocol, then that
  means the traffic is allowed in but the web server’s response
  will never leave the subnet. This is because network ACLs
  are considered to be stateless. I need to include both the inbound and the outbound ports
  used for the protocols. What that means for our HTTPS example is that I need to allow
  outbound HTTPS traffic from the subnet to the internet by creating an outbound rule. The other security feature
  is security groups. These are firewalls that exist
  at the EC2 instance level. Security groups are not optional, so anytime you create an EC2 instance, you need to place that EC2 instance inside of a security group that allows the appropriate
  kinds of traffic to flow to your application. In our diagram, if I were
  to draw security groups, I would draw them around
  every EC2 instance in the VPC. In our case, we simply
  just have one EC2 instance. So we would need a security
  group around that instance. You know what? I think it’s time for a demo. Let’s get Morgan back in here. – Hey, Seph, what should
  I demonstrate next? – Do you have some time to
  build out a security group for our employee directory application? I think we need an example. – Sure, let’s get started. The default configuration
  of a security group blocks all inbound traffic and
  allows all outbound traffic. If you want your EC2
  instance to accept traffic from the internet, you’ll
  need to open up inbound ports. If you have a web server,
  you may need to accept HTTP and HTTPS requests to
  allow that type of traffic through your security group. You can create an inbound rule that will allow port 80, HTTP, and port 443, HTTPS, as shown here. The beauty of security groups is that I don’t have to
  open up an outbound port for traffic to be able
  to leave the instance. Security groups are considered
  to be stateful resources. They will remember if a
  connection is originally initiated by the EC2 instance or from outside and temporarily allow traffic to respond without having to modify
  the inbound rules. All right, is that everything? – That’s it for this one, thanks. Remember that security
  groups and network ACLs are powerful tools to
  filter network-wide traffic for a single instance or subnets traffic. With security groups,
  everything is blocked by default so you can only use allow rules,
  whereas with network ACLs, everything is allowed by default but you can use both allow and deny rules. These configurations
  are largely up to you. For example, if you want
  ultimate convenience, you can leave the network ACLs
  in the default configuration and use mainly security
  groups to restrict access. We’ll be doing just that with our employee directory application and it will still be secure. But if you want an
  added layer of security, you can configure your
  network ACLs further for more fine-grained control.

• The solution we are building out with the employee directory
  application is an all in cloud meaning that the components needed to run and operate the
  application will be in AWS. However, many solutions require a hybrid model to be followed, where some components are in AWS and others are hosted in
  an on-premises data center. Let’s take some time to talk
  about connectivity to AWS for hybrid deployments. For hosting your resources in AWS you would use a VPC
  which you learned about in the previous lessons. For hosting resources on-premises you’d have your own solutions
  in an on-premises data center. So for connectivity to AWS how will you connect the
  remote data center to AWS? Let’s talk about a few
  choices you can pick from where you’re looking at
  connectivity between AWS and a remote site like a data center. First, let’s talk about AWS Virtual Private Network or AWS VPN. VPNs are a really common and popular way to securely connect your
  remote network to AWS. AWS VPN consists of
  two different services, AWS Site-Site VPN and AWS Client VPN. AWS Site-Site VPN is used
  to connect a remote network like a data center to a VPC. This would allow resources
  living in a customer managed data center to connect to AWS. Then there is AWS Client VPN which is more for connecting
  your administrators to AWS or to your data center. So this is more like when you need to log into a VPN on your laptop to
  access corporate resources. Using AWS VPN you can connect to your VPC through the virtual private gateway which we covered in an earlier video. Just like the internet gateway is the doorway to the internet. The virtual private gateway is the doorway to your private data center through a VPN connection or through another service
  called AWS Direct Connect. AWS Direct Connect is
  a service that provides a hosted private connection to AWS through a Direct Connect
  delivery partner, or through AWS. Direct Connect provides a
  private dedicated connection. This isn’t using the regular open internet to send data between point A and point B. While the data sent over
  Direct Connect is in transit the network traffic remains
  on the AWS global network and never touches the public internet. This reduces the chance
  of hitting bottlenecks or unexpected increases in latency when compared to a VPN connection. AWS Direct Connect supports a larger and more reliable throughput. If you plan to send a high
  volume of traffic to AWS and you do need reliability in throughput for this connection AWS Direct Connect would be a good choice. It really depends on your use
  case which one you would use or in some cases you may use both. Where VPN is a failover
  for Direct Connect. Now, let’s get back to building the employee directory application.

• In this next lab, you’ll have the opportunity
  to build out a network on AWS, and host the employee
  directory application. Once you have the network in place, you will launch an Amazon EC2 instance into one of the public subnets and use the user data script we have shown throughout the course to download and install the
  application at launch time. You will also create a security group which will be used by the EC2 instance to enable traffic from the
  internet to reach the instance. This is a great
  opportunity to put together everything you’ve been learning so far. So make sure you take
  your time with this lab, and really try to recall the
  purpose of doing each step. Practice makes perfect. So if you miss a step and
  something isn’t going right, try to go back a few steps and try again. This is a learning process,
  good luck and have fun.

Tutorial: Summary of VPC and Subnet Creation with Route Table Configuration and Instance Launch

Welcome to this tutorial, where we’ll explore the steps involved in creating a Virtual Private Cloud (VPC), subnets, configuring route tables, and launching an instance within this newly created network configuration. By following these steps, you’ll gain a practical understanding of essential AWS networking concepts.

Prerequisites:

• Basic understanding of cloud computing concepts
• familiarity with the AWS Management Console

Steps:

1. Creating a VPC:

• Open the VPC dashboard in the AWS Management Console.
• Click “Create VPC” and select “VPC only.”
• Give your VPC a name (e.g., app-vpc) and select a CIDR block (e.g., 10.1.0.0/16). This defines the address space for your entire VPC.
• Click “Create VPC.”

2. Creating Subnets:

• Click “Subnets” in the left-hand navigation and then “Create subnet.”
• Select the VPC you just created (app-vpc).
• Create two subnets for each availability zone (AZ):
  • Public Subnets: These will have internet access. Name them (e.g., Public Subnet 1, Public Subnet 2) and assign non-overlapping CIDR blocks within the VPC’s range (e.g., 10.1.1.0/24, 10.1.3.0/24). Select the appropriate AZs.
  • Private Subnets: These won’t have direct internet access by default. Follow the same naming and CIDR allocation but choose different AZs (e.g., Private Subnet 1, Private Subnet 2, 10.1.2.0/24, 10.1.4.0/24).
• Click “Create subnet” for each subnet.

3. Creating and Attaching an Internet Gateway:

• Click “Internet Gateways” in the left-hand navigation and then “Create internet gateway.”
• Give your gateway a name (e.g., app-igw) and click “Create internet gateway.”
• On the internet gateways page, select the newly created gateway and click “Attach to internet gateway.”
• Choose your app-vpc and click “Attach.”

4. Creating and Configuring a Public Route Table:

• Click “Route Tables” in the left-hand navigation and then “Create route table.”
• Name your route table (e.g., public-route-table) and associate it with app-vpc.
• Click “Create route table.”
• Edit the route table and add a route:
  • Destination: 0.0.0.0/0 (all traffic)
  • Target: The internet gateway you created (e.g., app-igw)
• Click “Save changes.”
• Go to “Subnet Associations” and edit the associations for your public subnets (e.g., Public Subnet 1, Public Subnet 2).
• Select the public-route-table and save the changes.

5. Launching an Instance in the New VPC:

• Go to the EC2 console and select “Instances.”
• Click “Launch Instance” and choose an existing AMI (e.g., Amazon Linux 2).
• Under “Network Settings,” select your app-vpc and a public subnet (e.g., Public Subnet 1).
• Ensure “Auto-assign Public IP” is enabled.
• Create a new security group that allows incoming traffic on ports 80 (HTTP) and 443 (HTTPS) from the internet.
• Launch the instance.

6. Verifying Access:

• Once the instance is running, note its public IP address.
• Open a new browser tab and paste the IP address.
• If successful, you should be able to access your application running within the newly created VPC with configured subnets and route table.

Congratulations! You have now created a VPC, subnets, configured a route table, and launched an instance within this network configuration.

Additional Notes:

• This is a basic example. In real-world scenarios, you might need to customize settings based on your specific needs and security requirements.
• Consider implementing additional security measures like access control lists (ACLs) within security groups for enhanced network protection.
• Explore further AWS documentation and resources for deeper understanding of VPC components and advanced configurations.

By following this tutorial and practicing, you’ll gain valuable skills in managing AWS VPCs and secure network environments for your applications.

• [Instructor] Hello everyone. In this video we are
  going to create a VPC, create four subnets, create a route table
  for the public subnets, and then we will attach an
  internet gateway to the VPC and then relaunch the
  employee directory application in the new VPC. So you can first see that I
  am in the VPC dashboard here, and I’m going to click on Create VPC. Now I want to select, this is a wizard that’s going to help you create your VPCs, your subnets, things like that. I’m gonna create just the VPC for now. So I’m gonna select VPC only, and then I’m gonna give this VPC a name. Let’s call it app-vpc. And then I want to enter in
  the CIDR range for this VPC. So to do that, I’m going
  to give the CIDR range to be 10.1.0.0/16. And then I’m going to scroll
  down and click Create VPC. Now we have our VPC, the next thing that I want to
  do is to create the subnets. So now I’m gonna select the subnets on the left-hand navigation and then I’m gonna click Create subnet. And then we’ll select a VPC for this. And we will select the VPC
  we just created, app-vpc. And now for our first subnet. We’ll give this a name, Public Subnet 1. And then we’ll select
  the availability zone which will be us-west-2a. And then we’ll give this a CIDR range which is gonna be 10.1.1.0/24. And then we can go ahead
  and add our next subnet. So we’re gonna have a
  public and a private subnet in each availability zone. So we’ll create our private one next. So Private Subnet 1, availability zone, same one us-west-2a. And then providing the CIDR range, we’ll say this is 10.1.2.0/24. And now we can add our subnets into the other availability zone. So this one is gonna be Public Subnet 2. And let’s say this time, we
  wanna put it in us-west-2b. And then for the subnet
  range we can say 10.1.3.0/24. And then finally we’ll
  create one more subnet which will be our Private Subnet 2. And then selecting the availability zone we’ll say is us-west-2b, and we’ll give this the
  CIDR range of 10.1.4.0/24. So you can see that we have,
  if I scroll back up to the top, you can see we have four
  different subnets being created with non-overlapping CIDR ranges. All of those CIDR ranges being a subset of the CIDR range that
  we created for our VPC. So we have 10.1.1.0, 10.1.2.0, 10.1.3.0 and 10.1.4.0. All right, now we can go
  ahead and click Create subnet and that will create all four. All right, so now we have four subnets, Public Subnet 1 and 2, and
  Private Subnet 1 and 2. Next what I wanna do is
  create an internet gateway. So I will select internet gateways in a left-hand navigation and then click Create internet gateway. We’ll give this a name. Let’s say it’s app-igw and then click Create internet gateway. Then we can go back to
  the internet gateways page where we can view all of
  our internet gateways. We currently have one internet gateway attached to our default VPC. What we wanna do is select
  the new internet gateway that we just created, and we
  want to attach this to a VPC. And then we’ll select our app VPC and then click Attach to internet gateway. For internet gateways
  and one internet gateway can only ever be attached to one VPC. So it’s a one-to-one relationship there. All right, next what we need to do is configure our route tables. So to do that I’m going
  to click route tables in the left-hand navigation. And you can see that we have
  two route tables already. We have the main route
  tables for both of our VPCs, our default VPC, and our app-vpc, which we can scroll to the right and expand this and read that VPC. There’s for our app-vpc. So now scrolling back over, I’m going to click create route table and then we’ll give
  this route table a name. We’ll save public-route-table. And then I want to associate
  this with our app-vpc and then click Create route table. So now we have a route
  table that’s been created but we want to now add
  a route that will allow any subnet that has this route
  table associated with it. We want to add a route
  that will allow traffic from the internet, 0.0.0.0/0. To where? The internet gateway. And the internet gateway we wanna choose the one that we just created and then we’ll click Save changes. Now, scrolling back down,
  we are not done yet. Now what we have to do is
  associate these subnets with this route table. So I’ll click Subnet associations
  and then scrolling down, we can see we currently have this associated with no subnets. I’m gonna click Edit subnet associations and then I’m gonna select our
  first two public subnets only. So there’s nothing
  inherently about a subnet that makes it public or private. The only thing that makes
  it public or private is whether or not it has
  a route table association that includes a route from that subnet to the internet gateway. All right, so we’ll go ahead and click Save associations here. And then we can scroll back down, click on the subnet association’s tab, and we can now see that we
  have our two public subnets associated with this route table. And then again, reviewing the routes, clicking back on the routes tab. We can see we have our local route and we have our route to the internet through the internet gateway. So now the last step here is
  let’s go ahead and relaunch our employee directory application. So I’m gonna navigate
  over to the EC2 console. And then from here I’m gonna
  click on the instances link, which we can see that we have our employee directory
  application still running. And if I select this, I can scroll down and I can see where this is running, which is our default VPC. So what I’m gonna do is
  I’m gonna keep this checked and then I’m gonna select actions and then Image and templates. And then I wanna select
  Launch more like this. And what this does is
  it brings you to a page that has a lot of the configurations for that original instance
  prepopulated over here, so you don’t have to go through and reselect all of the configurations. So we can see that we have Employee
  Directory App prepopulated. I’m gonna just gonna
  go ahead and call this Employee Directory App 2. We can see we have the
  Linux 2 AMI selected here and we also have out t2.micro selected. For the key pair, we do have to select that we want to proceed
  without a key pair again. And then here under network settings this is where we’re gonna
  make most of our changes. We’re going to select the new
  app-vpc that we just created, and then we’re going to
  select what public subnet we want to launch into, Public Subnet 1 or Public Subnet 2. We’re gonna go ahead and
  select Public Subnet 1. And then we’re also ensuring that this auto-assigned public IP is set to enable which it is. Now scrolling down, you can see that we can select our security group. Currently we have the security group that was created previously
  associated with this instance and it’s giving us an error saying that we can’t
  use the security group with this subnet. That’s because the security
  group is tied to the VPC. So we need to create a new security group that will be associated with this new VPC, not the default VPC. So what we wanna do here is
  click Create security group and then we will leave
  the default for the name and we’ll do the same thing that we did when we created our
  original security group, which is we want to
  allow both HTTP traffic on port 80 from the internet and adding a second rule, we want to allow HTTPS traffic
  on port 443 from anywhere. Now scrolling down, we can scroll down to the advanced details
  and expand this here. We can see that the role
  has been prepopulated, so that’s great. And then if we scroll down some more, let’s take a look at that user data. We can see that this also is prepopulated. So now we can click Launch instance. We can click on the instance ID, see that this is in the pending state. And so now we’ll wait a few minutes and come back and try to access it through this public IP address. And if we can access it, that means that all of
  our network configurations were configured correctly. Okay, so now we are back and
  we can see that the instances in the running state. If we copy this IP address and then I’m going to paste
  it into a new tab off screen, drag this tab over, we can see that we can now access the Employee Directory
  application at the IP address of the new instance that was
  launched into our new app-vpc.