Types of Placement Groups

• Cluster Placement Group

• Spread Placement Group

• Partition Placement Group

Cluster Placement Group

Is the logical grouping of instances within an Availability Zone. Cluster Group can span across peered VPCs. Cluster Groups are ideal for scenarios requiring high network throughput or low network latency.

Considerations

• Cannot span across Availability Zones

• Adding instances to existing cluster group may result in insufficient capacity error. Requires re-deployment of the cluster group with the updated number of instances.

• An instances in a cluster group can be stopped but restarting the instance depends on the availability of the hardware. Issues with capacity requires redeployment of the cluster group.

• Multiple Instance types can be launched in a cluster group but the required capacity may not be available.

Spread Placement Group

Instances are deployed on distinct hardware. Each instance has unique set of hardware, and other equipment. Suitable for critical workloads that require high availability. Reduces the risk of simultaneous failures.

Considerations

• Launch request fail if distinct hardware and equipment are not available

• Dedicated Instance types are not supported for spread placement group

Partition Placement Group

EC2 instances are grouped into partitions. An EC2 instances in a partition does not share the same rack with an EC2 instance in other partitions. A hardware failure in one of the partition does not affect the instances of other partitions. Partition placement groups are best for application requiring high availability.

Considerations

• Each Partition Group allows a maximum of seven partitions per Availability Zone.

• The number of Instance in a partition group is only limited by the limit of the AWS account

• Best Effort Even instance distribution to partitions i.e, no guarantee of even distribution of EC2 instances across partitions

• A partition placement group comprising of a Dedicated Instance type of EC2 , can only have a maximum of two partitions

But self-hosting comes with its own set of challenges . How do you access your services over the internet ? How do you secure them ? And how to manage access without overly complicated setup. This led me to using Tailscale. Tailscale is a mostly zero-config mesh VPN, which enables connecting to your devices over the internet through a private network.

In this article , I will guide you through setting up Tailscale on your home lab and use it to access self-hosted services from anywhere. We’ll also explore exposing services to the internet when required.

Signing up for Tailscale

1. Navigate to login.tailscale.com

2. Sign up using your preferred method (Google, GitHub, Microsoft, or email)

3. Download the Tailscale client for your operating system

4. Open the client and sign in — this will automatically register your device to your private Tailscale network (called a tailnet)

5. Repeat the process on any additional devices you want to connect.

To confirm everything is working, try reaching one device from another using its Tailscale IP address — Ping the IP address of one of your devices from the other

Securing Tailnet

Now that devices are able to connect to each other lets move on to securing them before hosting any services. There are multiple ways to implement Access control, the easiest being using tags . We will create tags, assign them to devices and based on the tags restrict the ports.

By default Tailscale allows all devices on the network to talk to each other on all ports. Adding ACL changes this to deny-by-default and only allows if a Access rule is present.

1. In the admin console , navigate to Access Control > Tags.

2. Click on create tags — ideally create at least two tags — server & client.

3. Navigate to the machines tab, and for each devices you have added, you can add the tag by clicking on the three dots > Edit ACL Tags > Add the tag from drop down. Save
   ️Before saving, make sure every device is tagged. Untagged devices will lose the ability to communicate once ACLs are enabled.

4. Now navigate to Access Control > General Access Rule.

5. Click on create rule.

6. Add the tag:client as the source and tag:server as the destination. For the port add tcp:80 and tcp:443. Add other port if your services requires those ports. (Add tcp:22 if you also want to SSH into the server devices). Save.

Now all your server devices can be accessed from the clients only on port 80 — http and 443-https.

Before moving on, it’s worth setting up a few tests in the Tests tab. Tests let you define connections that should always be allowed in your tailnet. Every time you make a change to your access rules, these tests are automatically validated — if any test fails, Tailscale will prevent you from saving the change, protecting you from accidentally breaking access to your services

MagicDNS

Just like on the internet, where you communicate with a server using a URL instead of IP address, you can do that on Tailscale network. Tailscale provides a feature called MagicDNS — a private DNS for your tailnet.
Each tailnet gets a domain somestring.ts.net and devices can be accessed using hostname.somestring.ts.net instead of their IP addresses

MagicDNS is enabled by default, if for some reason it is not navigate to DNS in the admin console and enable it .

You can find your tailnet’s full DNS name on the DNS page of the admin console. Once MagicDNS is active, your devices are reachable using their hostname — for example, if your server is named home-server, you can access a service running on port 8096 at http://home-server:8096 or http://home-server.somestring.ts.net:8096 from any device on your tailnet.

The hostname is taken from the device’s hostname. You can always change it on the machines tab for a devices by clicking on the three dots > Edit machine name.

You now have a private, secure network where your devices can reach each other and your self-hosted services from anywhere. But what if you want to share a service with someone outside your tailnet — without opening ports on your router? In the next article, we’ll look at Tailscale Funnel and how it lets you selectively expose services to the public internet

HTTP History

The HTTP 1.0 protocol developed in the early 1990s, used one host per IP. With the explosion of the internet and the issue with the exhaustion of the IPv4 addresses, HTTP 1.1 was developed . HTTP 1.1 made it possible for IPs to be shared among website with the introduction of the host header. When a client make a request to a server for a website, it would form a TCP connection with the server using the IP and the application layer read the host header of the HTTP request to respond with the appropriate website.

To make these requests secure, TLS (formerly SSL) is used to encrypt the traffic. TLS also faced issues with hosting multiple HTTPS websites, hence SNI (Server Name Indication) was introduced as an extension to TLS. SNI indicates the domain whose certificate the client wants to form the TLS connection with.

The rollout of these features, combined with the lack of proper validation between protocols operating at different layers of the network stack, made this technique possible.

Domain Fronting

Domain Fronting is a technique that leverages CDNs to mask traffic. The client sends a ClientHello to start negotiating the TLS tunnel. In the ClientHello message, the client specifies the front domain (front.example.com) in the SNI field. So the TLS tunnel is formed with the parameters of the front domain.

To an external entity, it maybe companies , governments or any one else viewing the connection, the client would seem communicating with the front domain. The external entities can view the SNI and it is the only way for determine the destination .

Once the TLS tunnel is established, all HTTP requests are now encrypted , which includes the host header with the actual destination domain. The CDNs route the requests to the destination domain using their internal routing. While routing the requests, the CDN does not validate a match between the domain in the SNI and the host fields. This allows Domain Fronting.

Is it still allowed (2025)

Domain Fronting in now blocked by major platforms. While it helps bypassing firewalls, masking destinations and helped overcome censorship, malicious actors also abused the quirks . It was used to connect to command-and-control servers, for distributing malware or also espionage .

In 2018 Russia blocked IPs of all major CDNs to stop Domain Fronting which caused issues for other companies and services using the CDN. Later Google and AWS disabled Domain Fronting, so as not get completely banned. While no direct regulation exists today banning the technique, most providers voluntarily don’t allow it.

Passkeys use asymmetric cryptographic keys for authentication — a public and a private key. When a user register for a service, a the user device creates a pair of public-private key. The private key is stored on the user device, while the public key is sent to and stored on the server.

Each time the user tries to login to a service, the user device digitally signs a challenge from the server. The server then verifies the signature and authenticates the user to the service. Passkeys eliminates user burden of remembering passwords for multiple services.

Passkeys offers numerous security advantages.

• Phishing is thwarted since the public-private key pair is associated with a particular service’s real domain. A change in domain, however subtle or unnoticeable will remain ineffective since the platform used to store the keys, only associated them with the real domain.

• A breach of public keys stored on the servers is worthless since they can neither be used to authenticate nor derive the private key within a feasible period with the existing computational capabilities and mathematical understanding.

• Eliminates developer effort required to develop and maintain complex security measures to safe public keys.

• The authentication process does not involve the transmission of the private key to the server, the key is only used to sign a challenge response

• Passkeys can be stored on a native or 3rd party services and synced across all devices used by the user.

Given the security enhancements and the ease of use passkeys (password-less) authentication will become the primary method for users to authenticate users to a service. Major companies have started the implementation of passkeys and smaller organizations soon following them