Plan Dual-Cloud IPv4 Subnets

Build a dual-cloud subnet plan and compare AWS and Google Cloud capacity.

Introduction

30 Second Summary

A seating plan can look perfect on paper until two venues reserve a different number of seats. The same headcount can fit in one venue and overflow in another.

In this project, you will build a subnet-planning worksheet for the fictional CloudCart environment from the private IPv4 block 10.20.0.0/24. Your worksheet will expose how AWS and Google Cloud reservations change the capacity reported by a traditional subnet calculator.

What You'll Build

Picture showing an interviewer one worksheet that proves four subnets fit perfectly inside 10.20.0.0/24 while catching an AWS capacity shortfall before deployment.

By the end of this project, you'll have:

A four-subnet map with every CIDR boundary visible. The map proves the private block has no gaps or overlaps.
A validated worksheet showing each subnet mask, network address, traditional host range, broadcast address, and total-address count.
A cross-cloud capacity decision that uses traditional plus provider-assignable counts to justify /27 as the smallest safe choice.
Secret Mission: Size a new subnet for 40 current addresses plus 25 percent growth. Choose the smallest prefix that remains safe in both clouds.

Are there any prerequisites?

Basic IPv4 familiarity plus simple powers-of-two arithmetic are the only prerequisites. The project runs entirely in your browser without creating cloud resources or costs.

Before We Start

This checkpoint commits you to building a validated four-subnet IPv4 plan before any calculations begin. Your CIDR sizes must provide enough assignable addresses in both AWS and Google Cloud because each provider reserves a different number of addresses.

Set Up and Validate the Calculator

Your final subnet plan must separate traditional IPv4 boundaries from the assignable counts in AWS and Google Cloud. Accurate calculations depend on understanding which results belong in each column.

In this step, you will validate the Jodies.de IP Calculator against a known /24 result in Microsoft Edge. You will prepare a worksheet for the subnet decisions that follow.

In this step, get ready to:

Open the Jodies.de IP Calculator in Microsoft Edge.
Create the subnet-planning worksheet.
Validate the calculator with a documented /24 sample.

Open Calculator

The calculator takes an address plus a netmask. Its output identifies the network boundary, host range, broadcast address, and traditional host count.

Press the Windows key to open Windows search.
Type Microsoft Edge into the search box.
Press Enter to open Microsoft Edge.
Select the address bar at the top of Microsoft Edge.
Enter https://jodies.de/ipcalc.
Press Enter to load the calculator.
Locate the Address (Host or Network), Netmask (i.e. 24), and Calculate controls.

You should see both input fields above the Calculate button.

Why Start Outside the Cloud Consoles?

A known calculator sample exposes the addressing logic before cloud defaults influence the result. You create no cloud resources, so this approach carries no billing risk.

The calculator provides traditional subnet results. Separate provider columns stop those results from being mistaken for cloud-assignable capacity.

Calculator Page Not Loading?

Confirm that Microsoft Edge can load another website.
Retype https://jodies.de/ipcalc in the address bar.

Ask for help if the page still does not load: help me troubleshoot access to the Jodies.de IP Calculator.

Create Worksheet

The worksheet keeps subnet boundaries beside the capacity decisions they support. Dedicated provider columns preserve the difference between traditional hosts and cloud-assignable addresses.

Create a blank worksheet on a sheet of paper or in a blank document.
Add these headers from left to right: Role, CIDR, Subnet Mask, Network Address, Traditional First Host, Traditional Last Host, Broadcast Address, Total Addresses, AWS Assignable, and Google Cloud Assignable.
Count the worksheet headers.

You should have 10 columns ready for subnet boundaries and capacity results.

Validate Calculator

A known sample gives you a control result. A match confirms that you can interpret the calculator before using it for the CloudCart plan.

Return to the Jodies.de IP Calculator in Microsoft Edge.
Enter 192.168.0.1 in the Address (Host or Network) field.
Enter 24 in the Netmask (i.e. 24) field.

Before you calculate, which network and broadcast boundaries do you expect a /24 to produce?

Select Calculate.

You'll see network 192.168.0.0/24. You'll see broadcast 192.168.0.255.

The traditional host range runs from 192.168.0.1 through 192.168.0.254. The page shows Hosts/Net: 254.

Add a calculator validation note beneath the worksheet headers.
Record 192.168.0.1/24 as the validation input.
Record 192.168.0.0/24 as the network.
Record 192.168.0.255 as the broadcast address.
Record 192.168.0.1 as the traditional first host.
Record 192.168.0.254 as the traditional last host.
Record 254 as the hosts per network.
Compare every recorded value with the calculator result.

Every recorded value should match the calculator. This proves the worksheet uses the traditional subnet fields correctly.

Results Do Not Match?

Confirm that the address field contains 192.168.0.1.
Confirm that the netmask field contains 24.
Select Calculate again after correcting either field.

Ask for help if the output still differs: help me interpret my /24 calculator result.

Good work. Your calculator now has a confirmed baseline for traditional subnet boundaries.

Your calculator and worksheet are ready. Next, you'll calculate the first subnet in the CloudCart plan.

Calculate the First Subnet

Your validated Jodies.de IP Calculator in Microsoft Edge is a trustworthy reference for the worksheet. Now you can derive the first CloudCart subnet from 10.20.0.0/24.

One correctly calculated subnet creates the boundary pattern for the other three. It replaces guesswork with a calculation you can repeat.

In this step, get ready to:

Derive four equal /26 blocks from 10.20.0.0/24.
Record the first 64-address range in your worksheet.
Validate the first subnet with the IP Calculator.

Split the /24 into four equal blocks

The 10.20.0.0/24 private IPv4 block contains 256 total addresses. Its CIDR prefix leaves eight bits for addresses inside the block.

Borrowing two of those bits creates four equal subnets. The six remaining bits produce 64 addresses per subnet.

How Does the Split Work?

Two borrowed bits create four possible subnet combinations. Adding those bits to the prefix changes /24 to /26.

A /26 uses the subnet mask 255.255.255.192. Its block size is 64 addresses.

Return to the subnet-planning worksheet from the previous step.
Record this planning note: The /24 is split by borrowing two host bits. This produces four equal /26 blocks with a 64-address increment.

Your worksheet now records the prefix change. It also records the increment that controls every subnet boundary.

Record the first /26 range

The block size sets the distance between network addresses. Starting at 10.20.0.0 means the first 64-address block ends at 10.20.0.63.

The last address is the broadcast address. The traditional host range runs from 10.20.0.1 through 10.20.0.62.

Return to the first blank row in your subnet-planning worksheet.
Leave the Role cell blank for now.

The role remains pending until you label the complete architecture in the next step.

Enter 10.20.0.0/26 in CIDR.
Enter 255.255.255.192 in Subnet Mask.

The first row now pairs the /26 prefix with its dotted-decimal mask.

Enter 10.20.0.0 in Network Address.
Enter 10.20.0.1 in Traditional First Host.

Your row begins with the network boundary. The first traditional host sits one address above it.

Enter 10.20.0.62 in Traditional Last Host.
Enter 10.20.0.63 in Broadcast Address.

The traditional host range now ends one address below the broadcast boundary.

Enter 64 in Total Addresses.
Record 62 as the traditional host count in the notes for this row.

Your first row now covers 64 total addresses. It contains 62 traditional host addresses.

Validate the first subnet

The calculator provides an independent check on your worksheet. It tests the network boundary against the host range you derived.

Before you calculate, which final address do you expect this /26 block to report? That value is your prediction for the check.

Switch back to the Jodies.de IP Calculator in Microsoft Edge.
Enter 10.20.0.1 in Address (Host or Network).

The address field now points inside the first candidate subnet.

Enter 26 in Netmask (i.e. 24).
Select Calculate.

You'll see network 10.20.0.0/26. You'll see broadcast 10.20.0.63.

The traditional host range runs from 10.20.0.1 through 10.20.0.62. The result reports 62 hosts per network.

Compare the calculator output with every populated value in the first worksheet row.
Mark the first worksheet row as validated.

That is your first subnet locked in. Every boundary now matches an independent calculation.

Calculator Values Do Not Match?

Check that Address (Host or Network) contains 10.20.0.1.
Check that Netmask (i.e. 24) contains 26.
Select Calculate again after correcting either value.

Help me compare my first /26 worksheet row with the calculator result.

Your first /26 block is validated. Next, you'll repeat its 64-address increment to complete the four-subnet map.

Complete the Four-Subnet Map

Your first subnet proves that the /26 pattern works. One bad 64-address increment can still create a gap or overlap across the complete plan.

Now you will extend that pattern across 10.20.0.0/24. A complete CIDR map gives you a clean foundation for the dual-cloud capacity decision.

In this step, get ready to:

Calculate the remaining /26 ranges in 64-address increments.
Assign architecture roles to all four worksheet rows.
Prove that the completed map has no gaps or overlaps.

Extend the 64-address pattern

Every /26 block begins 64 addresses after the previous network address. The final address in each block is its broadcast address.

Complete the second worksheet row for the block beginning at 10.20.0.64.
Compare the first row's broadcast address with the second row's network address.

Check the Second Row

The second row's CIDR is 10.20.0.64/26. Its subnet mask is 255.255.255.192.

The network address is 10.20.0.64. The traditional host range runs from 10.20.0.65 through 10.20.0.126.

The broadcast address is 10.20.0.127. The block contains 64 total addresses.

Complete the third worksheet row for the block beginning at 10.20.0.128.
Compare the second row's broadcast address with the third row's network address.

Check the Third Row

The third row's CIDR is 10.20.0.128/26. Its subnet mask is 255.255.255.192.

The network address is 10.20.0.128. The traditional host range runs from 10.20.0.129 through 10.20.0.190.

The broadcast address is 10.20.0.191. The block contains 64 total addresses.

Complete the fourth worksheet row for the block beginning at 10.20.0.192.
Compare the third row's broadcast address with the fourth row's network address.

Check the Fourth Row

The fourth row's CIDR is 10.20.0.192/26. Its subnet mask is 255.255.255.192.

The network address is 10.20.0.192. The traditional host range runs from 10.20.0.193 through 10.20.0.254.

The broadcast address is 10.20.0.255. The block contains 64 total addresses.

Record 62 traditional hosts beside each of the four rows.

Your worksheet now contains all four equal blocks. Each row has the same mask with the same total-address count.

Label the architecture roles

An architecture role records the intended placement of a subnet. The label alone does not configure routing or internet access.

Enter Public A in the first row's Role column.
Enter Public B in the second row's Role column.

The first two ranges now carry the intended public placement labels.

Enter Private A in the third row's Role column.
Enter Private B in the fourth row's Role column.

The final two ranges now carry the intended private placement labels.

Add a worksheet note stating that role labels do not configure routing or internet access.

What Do the Labels Mean?

Public and private labels document architecture intent. They help you explain where workloads are meant to sit.

The labels do not create routes. They do not provide internet access.

Your four roles now have complete address boundaries. Check your work before using the calculator.

✔️ I'll check the boundaries first

Confirm that every row uses subnet mask 255.255.255.192.
Confirm that every row contains 64 total addresses.
Confirm that each network address follows the previous broadcast address by one.

A consistent mask with consecutive boundaries proves that each row follows the same /26 pattern.

ⓧ Let me check my work

The Public A row uses CIDR 10.20.0.0/26. Its subnet mask is 255.255.255.192.

Its network address is 10.20.0.0. Its traditional host range runs from 10.20.0.1 through 10.20.0.62.

Its broadcast address is 10.20.0.63. The block has 64 total addresses with 62 traditional hosts.

The Public B row uses CIDR 10.20.0.64/26. Its subnet mask is 255.255.255.192.

Its network address is 10.20.0.64. Its traditional host range runs from 10.20.0.65 through 10.20.0.126.

Its broadcast address is 10.20.0.127. The block has 64 total addresses with 62 traditional hosts.

The Private A row uses CIDR 10.20.0.128/26. Its subnet mask is 255.255.255.192.

Its network address is 10.20.0.128. Its traditional host range runs from 10.20.0.129 through 10.20.0.190.

Its broadcast address is 10.20.0.191. The block has 64 total addresses with 62 traditional hosts.

The Private B row uses CIDR 10.20.0.192/26. Its subnet mask is 255.255.255.192.

Its network address is 10.20.0.192. Its traditional host range runs from 10.20.0.193 through 10.20.0.254.

Its broadcast address is 10.20.0.255. The block has 64 total addresses with 62 traditional hosts.

The four ranges cover 10.20.0.0 through 10.20.0.255 exactly once. The role labels do not configure routing or internet access.

Validate the outer subnet boundaries

The Jodies.de IP Calculator in Microsoft Edge provides an independent boundary check. A host address inside a block should resolve to the network recorded in your worksheet.

Switch back to the calculator tab in Microsoft Edge.
Enter 10.20.0.65 in the Address (Host or Network) field.
Enter 26 in the Netmask (i.e. 24) field.
Select Calculate.

You should see network 10.20.0.64/26. The broadcast address should be 10.20.0.127.

The traditional host range should run from 10.20.0.65 through 10.20.0.126. The page should report 62 hosts per network.

That's one boundary confirmed: your second subnet matches the independent calculation.

Calculator Shows a Different Range?

Confirm that the address is 10.20.0.65. Confirm that the netmask is 26.

A misplaced digit can resolve to a different block.

Help me troubleshoot my subnet calculator result.

Before you run the final calculator check, which /26 network do you expect 10.20.0.193 to land inside?

Replace the address with 10.20.0.193.
Keep the netmask set to 26.
Select Calculate.

You should see network 10.20.0.192/26. The broadcast address should be 10.20.0.255.

The traditional host range should run from 10.20.0.193 through 10.20.0.254. The page should report 62 hosts per network.

Before you scan the completed map, do you expect every address from 10.20.0.0 through 10.20.0.255 to appear exactly once?

Return to your subnet-planning worksheet.
Read the CIDR column from top to bottom.
Compare every broadcast address with the next network address.

The CIDR column should read 10.20.0.0/26, 10.20.0.64/26, 10.20.0.128/26, and 10.20.0.192/26.

You should see 10.20.0.63 followed by 10.20.0.64. You should also see 10.20.0.127 followed by 10.20.0.128.

The final join is 10.20.0.191 followed by 10.20.0.192. These consecutive joins prove that the four ranges have no gaps or overlaps.

Your map begins at 10.20.0.0 and ends at 10.20.0.255. The entire 10.20.0.0/24 block is covered exactly once.

Found a Gap or Overlap?

Check that the network starts use final-octet values 0, 64, 128, and 192.

Check that each broadcast address is one less than the next network address.

Help me find a gap or overlap in my four-subnet map.

Your complete subnet map now covers the private block without gaps or overlaps. Next, you will test a workload-sized subnet against cloud capacity rules.

Compare Cloud Address Capacity

Your completed four-subnet IPv4 map covers 10.20.0.0/24 exactly once. That map proves your subnet boundaries are complete.

A traditional host count can make a subnet appear large enough. Provider reservations can reduce its deployable capacity.

You will compare the traditional result with capacity in AWS. You will repeat the capacity check for Google Cloud.

In this step, get ready to:

Evaluate a /28 candidate using traditional host capacity.
Apply provider-specific address reservations.
Decide whether the candidate supports cross-cloud deployment.

Test the traditional /28 result

The Jodies.de IP Calculator reports traditional network boundaries plus the traditional host count. The workload requires at least 12 assignable addresses in either cloud.

Predict whether a traditional /28 meets the 12-address requirement.
Switch back to the Jodies.de IP Calculator in Microsoft Edge.
Enter 10.20.1.0 in Address (Host or Network).
Enter 28 in Netmask (i.e. 24).
Select Calculate.

The result confirms that a /28 contains 16 total addresses. It provides 14 traditional host addresses.

Why Does a /28 Have 14 Traditional Hosts?

A /28 leaves four bits for addresses inside the subnet. Four bits produce 16 total addresses.

Traditional subnetting excludes the network address plus the broadcast address. Subtracting those two addresses leaves 14 traditional hosts.

Calculator Result Look Different?

Confirm that the address is 10.20.1.0.
Confirm that the netmask is 28.
Leave the optional subnetwork field empty.

Ask for help if your calculator still shows different boundaries: help me check my /28 calculator input

Add a capacity comparison row for a workload requiring at least 12 assignable addresses in either cloud.
Enter 10.20.1.0/28 as the candidate.

Your comparison now identifies the requirement plus the candidate being tested.

Record 16 under Total Addresses.
Record 14 as the traditional host capacity.

The candidate appears to provide two addresses beyond the workload requirement.

Mark the initial traditional decision as Pass.

The traditional calculation gives the candidate a clean pass. That is the result a subnet calculator supports on its own.

Apply the AWS reservation rule

AWS makes the first four IPv4 addresses unavailable for assignment to a resource. It also makes the last IPv4 address unavailable.

Predict whether five reserved addresses leave enough capacity for the 12-address workload.
Calculate 16 - 5 in the AWS Assignable cell.

Your result is 11 assignable addresses. The candidate is one address short of the requirement.

Mark the AWS decision as Fail.

The traditional pass has now produced an AWS failure. This shortfall is the capacity trap the comparison was designed to expose.

Why the Calculator Needs a Cloud Check

The calculator reports traditional network boundaries plus the traditional host range. Provider reservations require a separate capacity calculation.

The provider-adjusted count determines how many addresses a cloud workload can actually use.

Compare Google Cloud capacity

A Google Cloud primary subnet range makes the first two IPv4 addresses unusable. It also makes the last two IPv4 addresses unusable.

Predict whether four reserved addresses leave any capacity beyond the 12-address requirement.
Calculate 16 - 4 in the Google Cloud Assignable cell.

Your result is exactly 12 assignable addresses. The candidate meets the requirement with zero spare addresses.

Mark the Google Cloud decision as Pass.
Add No spare capacity beside the Google Cloud decision.

Your provider comparison now contains one pass plus one failure.

Record the final /28 recommendation as Rejected for cross-cloud deployment.

Predict which provider result should control the final recommendation.
Read the completed capacity comparison from the traditional column through the Google Cloud column.

You should see Traditional 14 with an initial Pass. You should see AWS 11 marked Fail.

You should see Google Cloud 12 marked Pass with no spare capacity. The final /28 recommendation should be rejected.

✔️ My Comparison Matches

Great. Your worksheet now separates traditional capacity from provider-assignable capacity.

ⓧ I'd Like to Double Check My Worksheet

Workload requirement: at least 12 assignable addresses in either cloud. Candidate: 10.20.1.0/28.

Total addresses: 16. Traditional host addresses: 14.

Initial traditional decision: Pass.

AWS assignable: 11 after five reserved addresses. Decision: Fail.

Google Cloud primary subnet range assignable: 12 after four reserved addresses. Decision: Pass with no spare capacity.

Final /28 recommendation: rejected for cross-cloud deployment.

You caught the cloud capacity trap. Next, you will test a larger candidate that can satisfy both providers.

Select a Cross-Cloud CIDR

Your /28 comparison exposed a provider-specific gap. Google Cloud meets the 12-address requirement with no spare capacity.

AWS leaves only 11 assignable addresses. Your next goal is one subnet that clears the same requirement in both clouds.

The Jodies.de IP Calculator validates the traditional boundaries. Provider reservation math helps you choose the smallest safe CIDR.

In this step, get ready to:

Validate the boundaries of the /27 candidate.
Calculate the provider-assignable capacity of the candidate.
Record the smallest candidate that meets the cross-cloud requirement.

Validate the /27 boundaries

A /27 contains 32 total addresses. Its dotted-decimal subnet mask is 255.255.255.224.

A traditional host range excludes the network address. It also excludes the broadcast address.

Before you calculate, where do you expect a 32-address block starting at 10.20.1.0 to end?

Return to the Jodies.de IP Calculator tab in Microsoft Edge.
Enter 10.20.1.1 in the Address (Host or Network) field.
Enter 27 in the Netmask (i.e. 24) field.
Select Calculate.

What Should I See?

The network is 10.20.1.0/27.
The subnet mask is 255.255.255.224.
The broadcast address is 10.20.1.31.
The traditional host range runs from 10.20.1.1 through 10.20.1.30.
The traditional host count is 30.

Record the validated values in a new 10.20.1.0/27 candidate row in your 12-address capacity comparison.

Calculator Result Looks Different?

Confirm the Address (Host or Network) field contains 10.20.1.1.
Enter 27 without a slash in the Netmask (i.e. 24) field.
Select Calculate again.

Help me check my /27 calculator result.

Calculate provider-assignable capacity

Provider-assignable capacity starts with the 32 addresses in the block. Each cloud removes its reserved addresses from that total.

Calculate the AWS assignable capacity in the worksheet as 32 - 5 = 27.
Mark the AWS decision as Pass.

Your AWS result now exceeds the 12-address requirement.

Calculate the Google Cloud primary-range capacity in the worksheet as 32 - 4 = 28.
Mark the Google Cloud decision as Pass.

That closes the provider gap. Both cloud columns now clear the requirement.

Why Do the Totals Differ?

AWS reserves the first four IPv4 addresses in the subnet. It also reserves the last IPv4 address.

Google Cloud reserves the first two IPv4 addresses in a primary subnet range. It also reserves the last two IPv4 addresses.

Select the smallest safe candidate

A smallest-fit decision tests candidates from tighter to larger. The first candidate that meets every requirement becomes the recommendation.

Relabel 10.20.1.0/28 as the rejected candidate.
Label 10.20.1.0/27 as the selected recommendation.

Your comparison now shows one rejected candidate. It also shows one selected candidate.

Write /27 is the smallest candidate that supplies at least 12 assignable addresses in both clouds in the comparison.

Before you check the finished comparison, which candidate do you expect to survive both provider rules while using the least address space?

Verify the completed /27 row against the calculator result that remains open.
Compare the provider decisions for /28 versus /27.

What Should the Finished Comparison Show?

The workload requires at least 12 assignable addresses in either cloud.
The rejected candidate is 10.20.1.0/28.
The rejected candidate has 16 total addresses.
Its traditional host count is 14.
Its AWS capacity is 11. The decision is Fail.
Its Google Cloud primary-range capacity is 12. The decision is Pass with no spare capacity.
The selected recommendation is 10.20.1.0/27.
Its subnet mask is 255.255.255.224.
Its network address is 10.20.1.0.
Its traditional host range is 10.20.1.1 to 10.20.1.30.
Its broadcast address is 10.20.1.31.
It has 32 total addresses.
Its traditional host count is 30.
Its AWS assignable capacity is 27.
Its Google Cloud primary-range assignable capacity is 28.
The /27 candidate is the smallest option that supplies at least 12 assignable addresses in both clouds.

You now have a defensible cross-cloud decision backed by calculator results and provider-specific capacity math.

Secret mission

Size for Growth

CloudCart's current 40-address requirement is growing by 25 percent. Derive the new target. Then prove which CIDR is the smallest safe choice for AWS and a Google Cloud primary range.

Clean Up Your Resources

This project created no cloud resources, so there are no ongoing costs. Decide whether to keep your worksheet handy, pause by closing the calculator, or delete the work entirely.

Resources you used:

An active Jodies.de IP Calculator session in Microsoft Edge.
A completed subnet-planning worksheet with the validated four-subnet map.
A 12-address capacity decision covering AWS plus Google Cloud.
A growth-aware recommendation that selects /26 for 50 required addresses.

Keep everything running

No action needed. Choose this if you want to reuse your worksheet for future subnet-planning decisions.

Keep the calculator tab open for more subnet checks.
Retain the subnet-planning worksheet with its validated capacity decisions.
Continue using the worksheet without worrying about cloud charges.

Pause - I'll come back to this later

Close the active browser session while preserving your worksheet. You can return to the same calculations whenever you need them.

Close the Jodies.de IP Calculator tab in Microsoft Edge.
Keep the subnet-planning worksheet in its current location.
Return to the calculator when you are ready to test another CIDR prefix.

Delete - I don't want to use this again

Remove the calculator session plus the worksheet if you want to start the planning exercise again. There are no AWS or Google Cloud resources to delete.

Close the Jodies.de IP Calculator tab in Microsoft Edge.
Delete the subnet-planning worksheet from the app where you recorded it.
Confirm that your worksheet no longer appears in that app.

Nice Work!

You completed the challenge! Your validated worksheet now maps four IPv4 subnets without gaps or overlaps while accounting for provider reservations in AWS and Google Cloud.

You've learned how to:

Produce a validated four-subnet map by dividing 10.20.0.0/24 into four equal /26 ranges that cover every address exactly once.
Distinguish traditional host counts from provider-assignable capacity. This revealed why 10.20.1.0/28 provides 14 traditional hosts but only 11 AWS assignable addresses.
Select /27 as the smallest cross-cloud fit for a 12-address requirement. You documented 27 AWS assignable addresses plus 28 Google Cloud assignable addresses.
Secret Mission: Size a 40-address requirement for 25 percent growth. You proved /26 is the smallest safe choice for 50 addresses. It provides 59 assignable addresses in AWS plus 60 in a Google Cloud primary subnet range.

Ready to quiz yourself?