With the Beta exam out in late 2017, we certainly knew this day was coming. AWS has announced a new refresh on their most popular certification – the Solutions Architect – Associate.
Since AWS is simply in love with the Frequently Asked Question (FAQ) approach to learning, I thought I would use that format for the details you need to know about this refresh.
- Q: Can I still take the “old” exam? I am almost done with my prep for that version!
- A: You can take the “old exam” still if you like – the last day to test on the old exam is August 11, 2018.
- Q: Where can I find the “old” exam blueprint?
- A: You can find that here.
- Q: Where can I find the new exam blueprint?
- A: You can find that here.
- Q: If I want to register for the new exam – how is it identified?
- A: While both exams are live, you will note the title of the new exam includes data information – “AWS Certified Solution Architect – Associate (Released February 2018)”
- Q: Is the new exam tougher?
- A: No – I would say that overall the new exam is easier. Keep in mind it is updated to cover newer services, however.
- What about the modules at CBT Nuggets for Solutions Architect – Associate? Which exam do those Nuggets cover?
- A: The modules at CBT Nuggets address the “old” exam. On August 12, 2018, the Nuggets will be refreshed to map directly to the new exam. Note on that date, there will only be one exam live – the new exam.
- I would love to start studying right now for the new exam. Are there any free materials available right now?
- A: By far – this homepage of resources is extremely valuable for preparation: click here
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:
- Request the peering from a Requestor VPC to an Acceptor VPC
- Once the Peering is accepted, manually add the routes you desire to the routing tables in the two VPCs
- 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
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.
- 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