AWS Solutions Architect – CORS

January 19, 2018 at 6:10 am


A topic that could come up in your Solutions Architect exams that is easy to overlook is CORS. This stands for Cross-Origin Resource Sharing. It is a way that you can have your client web applications that exist in one domain (for example, to access resources in a different domain ( This feature ties directly to Amazon S3 (Simple Storage Service).

As you might guess, you can enable CORS support using the Management Console, the CLI, or your SDKs.

What would be some sample use cases?

  • You have JavaScript calls on web pages from an S3 bucket that need to access an API endpoint with a different domain name
  • You are hosting a Web site in your S3 bucket that includes web fonts; CORS is required by client browsers in this case

To configure your bucket to allow cross-origin requests you create a CORS configuration that is an XML document. The XML document contains rules that identify the origins that you will allow to access your bucket, the operations (HTTP methods) will support for each origin, and other operation-specific information

You can add up to 100 rules to the configuration.

New Course Coming! AWS Solutions Architect – Networking Services

January 15, 2018 at 4:29 pm


I have a new CBT Nuggets course wrapping up this week that is super exciting for those interested in AWS (especially certification). It is the AWS Solutions Architect – Networking Services course and it sits along with the already completed Compute and Storage Services courses. This networking course is so important because it features content found in all the major Associate Level AWS certifications! Here is the current list of Nuggets that the course will feature. I look forward to your comments below!

  1. Course Introduction
  2. What is a VPC?
  3. Meet the Default VPC
  4. Creating a Custom VPC
  5. Testing a Custom VPC
  6. Stateful Security Groups
  7. Working with Private Subnets
  8. NAT in AWS
  9. Network ACLs
  10. Components of the Global Infrastructure
  11. Route 53
  12. CloudFront
  13. VPNs
  14. Direct Connect
  15. Web Application Firewall
  16. Directory Services
  17. Disaster Recovery

Using the Start VPC Wizard

January 12, 2018 at 4:50 pm


One option for your VPC creation inside of AWS is to use a Wizard. This video demonstrates how this works. This is supplemental material to Anthony Sequeira’s upcoming course on Networking Services in AWS at CBT Nuggets!

AWS Access Management

January 10, 2018 at 10:30 pm

In the AWS Certified Cloud Practitioner course at CBT Nuggets, trainer Anthony Sequeira will help you understand the fundamentals of AWS Cloud, including concepts crucial to the deployment and operation of this platform. Learn about key services, basic security aspects, and administrative components, while preparing for Amazon’s Certified Cloud Practitioner exam. This example Nugget from the course covers Access Management topics in the scope of the exam.

VPC Peerings in AWS

January 10, 2018 at 12:59 am

VPC Peerings

An often overlooked feature with VPCs in AWS is your ability to create peering relationships between them. AWS calls this, appropriately, VPC Peerings. These objects permit you to route traffic between VPCs and offer the following killer features:

  • You can route traffic between your own VPCs
  • You can route traffic between your VPC and a VPC in another AWS account
  • Some regions even support an inter-region VPC Peering connection
  • The VPC Peering is not physical hardware, it is not a gateway or VPN connection; this ensures high availability for the peering using the global infrastructure of AWS

The steps you perform for the creation of a VPC Peering are simple:

  1. Request the peering from a Requestor VPC to an Acceptor VPC
  2. Once the Peering is accepted, manually add the routes you desire to the routing tables in the two VPCs
  3. Modify Security Groups appropriately to permit the desired access to resources across the VPCs

There are important restrictions to keep in mind for intra-region VPC Peerings:

  • The CIDR ranges cannot overlap
  • There is a limit to the overall number of VPC Peerings you can have; this is a soft limit that you can contact AWS about of course
  • You cannot have more than one VPC Peering between two VPCs
  • They do support Placement Groups with some limitations
  • There is no Unicast Reverse Path Forwarding security protections permitted

The restrictions for inter-region VPC Peerings are as follows:

  • The Security Groups cannot reference each other across the regions
  • DNS will not function across the regions seamlessly like within a region
  • IPv6 communications are not supported in this design
  • The MTU is 1500
  • Inter-region VPC Peerings are limited to only certain regions currently

Route 53 in AWS

January 8, 2018 at 10:36 pm

Route 53

A key networking element to AWS is the DNS service named Route 53. Remember, DNS is how we resolve IP addresses to domain names. For example – we access by typing that friendly name in a Web browser. Behind the scenes, DNS finds the correct IP address for this name. Think of DNS as a massive phone book. This phone book is distributed to servers all over the globe to ensure resolution can always occur. Hopefully.

It is no surprise that AWS offers a DNS service. After all, AWS has networks all over the world already. They also want to make sure they can provide DNS names to customers for their resources they build in the cloud.

Here are fun facts that you should know about Route 53:

  • It is completely compliant with IPv6
  • While Route 53 makes it easy to access resources inside of your AWS infrastructure, you could also use it to provide resolution for resources you have outside of their cloud
  • Route 53 is capable of DNS health checks so you can ensure traffic is sent to healthy nodes in your infrastructure
  • Amazon Route 53 Traffic Flow makes it easy for you to manage traffic globally through a variety of routing types, including Latency Based Routing, Geo DNS, Geoproximity, and Weighted Round Robin—all of which can be combined with DNS Failover in order to enable a variety of low-latency, fault-tolerant architectures
  • Route 53 also offers domain name registrations, so if you need a domain name for your organization, you do not have to shop beyond AWS for this service
  • Private DNS services are possible if you want to use the name resolution inside private VPC structures without advertising names to the public Internet
  • Route 53 supports redirection, so you can redirect traffic destined for one domain to another without explicitly impacting the clients
  • S3 Zone Apex support now exists – this makes it possible to permit access to your website using just the domain name – for example,

AWS Cloud Practitioner at CBT Nuggets

A Default VPC in AWS

January 7, 2018 at 7:03 pm


Amazon tries to lower your barrier to entry when it comes to quickly making resources available via the cloud. As such, you are built a nice default VPC. This post walks you through what is created for you.

  • The default VPC itself – there is a unique ID associated with this for identification and a CIDR range (
  • Subnets – you get a subnet in each of your Availability Zones; these subnets are publicly reachable; they are /20 and feature 4091 available addresses
  • Route Table – there is a route table constructed for you; it directs to stay local, and there is a default route ( directing traffic to an Internet Gateway constructed for you
  • Internet Gateway – this allows your default VPC resources to reach the outside world
  • DHCP Options Set – there is an entry done for you which contains the domain name associated with your default VPC
  • Network ACL – there is a Network ACL associated with all three of your subnets; it is completely permissive by default; it allows all traffic inbound and all traffic outbound
  • Security Group – there is a default security group created for you; it is restrictive in nature in that it permits no traffic inbound

Note there are plenty of other VPC components available for your default VPC, but you would need to configure them. These components include:

  • Egress only Internet Gateways
  • Elastic IPs
  • Endpoints
  • Endpoint Services
  • NAT Gateways
  • Peering Connections
  • Customer Gateways
  • Virtual Private Gateways
  • VPN Connections


An Overview of VPCs (Virtual Private Clouds) in AWS

January 5, 2018 at 5:48 pm



You cannot enjoy any associate level AWS certification exam and not be hammered with VPC questions. This makes it a very important topic for those interested in AWS certs. This post reviews key elements of these important constructs with you.

Key Points

  • Think of a VPC as your own data center in the AWS cloud
  • AWS provides you with a default VPC in the region you select; this is to lower the barrier to entry when it comes to providing cloud-based resources quickly
  • When you create a VPC from scratch on your own, this is termed a Custom VPC
  • The default VPC provides public Internet access to all subnets inside it by default; again, this is to lower barriers to entry
  • Subnets in a VPC can be made publicly Internet accessible or private
  • Your VPCs are logically isolated from other customers and resources within AWS
  • You have high levels of control over the components in your VPC; in fact, it is your responsibility (in the shared responsibility model) to properly secure many of these components; for example, when you create a new Security Group for an EC2 instance you are provisioning, you must ensure the correct security rules exist for your appropriate usage
  • An Internet Gateway exists (one per VPC) in order to provide Internet Access
  • A Virtual Private Gateway can be used to provide VPN access
  • You have virtual routers in your VPC that contain route tables that you can manipulate; one important use of this would be to provide routing functions between your VPC subnets
  • Network Access Control Lists exist so you can enforce security rules within your VPC; these ACLs are stateless; one important aspect of this is the fact that if you permit traffic inbound, you must also permit this traffic outbound as this is not automatically provisioned
  • Subnets exist in your VPC and use RFC 1918 private addressing; each subnet is contained in an Availability Zone (AZ)
  • Security Groups can span multiple AZs, they permit you to define traffic rules for access to EC2 (and other) resources
  • Since you can have multiple VPCs in your infrastructure, you can configure VPC peering to permit access between the clouds
    • You can create direct routes using Private IPs to define connectivity
    • You can even provide peering between VPCs of different AWS accounts
    • There is no transitive peering with VPCs; so if VPC A peers with VPC B and VPC C, it does not mean that VPC B and VPC C are also peered; think of the peerings as hub and spoke