You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
title: 'Quickstart: Connect to a virtual machine using a private IP address: Azure Bastion'
3
+
description: In this article, learn how to create an Azure Bastion host from a virtual machine and connect securely using a private IP address.
4
+
services: bastion
5
+
author: cherylmc
6
+
7
+
ms.service: bastion
8
+
ms.topic: conceptual
9
+
ms.date: 03/11/2020
10
+
ms.author: cherylmc
11
+
# Customer intent: As someone with a networking background, I want to connect to a virtual machine securely via RDP/SSH without using a public IP address.
12
+
13
+
---
14
+
15
+
# Quickstart: Connect to a virtual machine using a private IP address and Azure Bastion
16
+
17
+
This quickstart article shows you how to connect to a virtual machine using a private IP address. When you connect via Bastion, your virtual machines don't need a public IP address. The steps in this article help you deploy Bastion to your virtual network via your virtual machine in the portal. Once the service is provisioned, the RDP/SSH experience is available to all of the virtual machines in the same virtual network.
18
+
19
+
## <aname="prereq"></a>Prerequisites
20
+
21
+
* An Azure virtual network.
22
+
* An Azure virtual machine located in the virtual network with port 3389 open.
23
+
24
+
### Example values
25
+
26
+
|**Name**|**Value**|
27
+
| --- | --- |
28
+
| Name | VNet1Bastion |
29
+
| Region | eastus |
30
+
| Virtual network | VNet1 |
31
+
| + Subnet Name | AzureBastionSubnet |
32
+
| AzureBastionSubnet addresses | 10.1.254.0/27 |
33
+
| Public IP address | Create new |
34
+
| Public IP address name | VNet1BastionPIP |
35
+
| Public IP address SKU | Standard |
36
+
| Assignment | Static |
37
+
38
+
## <aname="createvmset"></a>Create a bastion host
39
+
40
+
When you create a bastion host in the portal by using an existing virtual machine, various settings will automatically default to correspond to your virtual machine and/or virtual network.
41
+
42
+
1. Open the [Azure portal](https://portal.azure.com). Go to your virtual machine, then click **Connect**.
1. On the Bastion page, fill out the following settings fields:
51
+
52
+
***Name**: Name the bastion host
53
+
***Subnet**: The subnet inside your virtual network to which Bastion resource will be deployed. The subnet must be created with the name **AzureBastionSubnet**. The name lets Azure know which subnet to deploy the Bastion resource to. This is different than a Gateway subnet. Use a subnet of at least /27 or larger (/27, /26, /25, and so on).
54
+
55
+
* Select **Manage subnet configuration**, then select **+ Subnet**.
56
+
* On the Add subnet page, type **AzureBastionSubnet**.
57
+
* Specify the address range in CIDR notation. For example, 10.1.254.0/27.
58
+
* Select **OK** to create the subnet. At the top of the page, navigate back to Bastion to complete the rest of the settings.
59
+
60
+
61
+
***Public IP address**: This is the public IP of the Bastion resource on which RDP/SSH will be accessed (over port 443). Create a new public IP, or use an existing one. The public IP address must be in the same region as the Bastion resource you are creating.
62
+
***Public IP address name**: The name of the public IP address resource.
63
+
1. On the validation screen, click **Create**. Wait for about 5 minutes for the Bastion resource create and deploy.
Copy file name to clipboardExpand all lines: articles/cosmos-db/sql-query-geospatial-index.md
+96-4Lines changed: 96 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ ms.author: tisande
10
10
---
11
11
# Index geospatial data with Azure Cosmos DB
12
12
13
-
We designed Azure Cosmos DB’s database engine to be truly schema agnostic and provide first class support for JSON. The write optimized database engine of Azure Cosmos DB natively understands spatial data represented in the GeoJSON standard.
13
+
We designed Azure Cosmos DB's database engine to be truly schema agnostic and provide first class support for JSON. The write optimized database engine of Azure Cosmos DB natively understands spatial data represented in the GeoJSON standard.
14
14
15
15
In a nutshell, the geometry is projected from geodetic coordinates onto a 2D plane then divided progressively into cells using a **quadtree**. These cells are mapped to 1D based on the location of the cell within a **Hilbert space filling curve**, which preserves locality of points. Additionally when location data is indexed, it goes through a process known as **tessellation**, that is, all the cells that intersect a location are identified and stored as keys in the Azure Cosmos DB index. At query time, arguments like points and Polygons are also tessellated to extract the relevant cell ID ranges, then used to retrieve data from the index.
16
16
@@ -21,6 +21,44 @@ If you specify an indexing policy that includes spatial index for /* (all paths)
21
21
>
22
22
>
23
23
24
+
## Modifying geospatial data type
25
+
26
+
In your container, the `geospatialConfig` specifies how the geospatial data will be indexed. You should specify one `geospatialConfig` per container: geography or geometry. If not specified, the `geospatialConfig` will default to the geography data type. When you modify the `geospatialConfig`, all existing geospatial data in the container will be reindexed.
27
+
28
+
> [!NOTE]
29
+
> Azure Cosmos DB currently supports modifications to the geospatialConfig in the .NET SDK only in versions 3.6 and above.
30
+
>
31
+
32
+
Here is an example for modifying the geospatial data type to `geometry` by setting the `geospatialConfig` property and adding a **boundingBox**:
The following JSON snippet shows an indexing policy with spatial indexing enabled for the **geography** data type. It is valid for spatial data with the geography data type and will index any GeoJSON Point, Polygon, MultiPolygon, or LineString found within documents for spatial querying. If you are modifying the indexing policy using the Azure portal, you can specify the following JSON for indexing policy to enable spatial indexing on your container:
@@ -53,12 +91,66 @@ The following JSON snippet shows an indexing policy with spatial indexing enable
53
91
54
92
> [!NOTE]
55
93
> If the location GeoJSON value within the document is malformed or invalid, then it will not get indexed for spatial querying. You can validate location values using ST_ISVALID and ST_ISVALIDDETAILED.
56
-
>
57
-
>
58
-
>
59
94
60
95
You can also [modify indexing policy](how-to-manage-indexing-policy.md) using the Azure CLI, PowerShell, or any SDK.
61
96
97
+
## Geometry data indexing examples
98
+
99
+
With the **geometry** data type, similar to the geography data type, you must specify relevant paths and types to index. In addition, you must also specify a `boundingBox` within the indexing policy to indicate the desired area to be indexed for that specific path. Each geospatial path requires its own`boundingBox`.
100
+
101
+
The bounding box consists of the following properties:
102
+
103
+
-**xmin**: the minimum indexed x coordinate
104
+
-**ymin**: the minimum indexed y coordinate
105
+
-**xmax**: the maximum indexed x coordinate
106
+
-**ymax**: the maximum indexed y coordinate
107
+
108
+
A bounding box is required because geometric data occupies a plane that can be infinite. Spatial indexes, however, require a finite space. For the **geography** data type, the Earth is the boundary and you do not need to set a bounding box.
109
+
110
+
You should create a bounding box that contains all (or most) of your data. Only operations computed on the objects that are entirely inside the bounding box will be able to utilize the spatial index. You should not make the bounding box significantly larger than necessary because this will negatively impact query performance.
111
+
112
+
Here is an example indexing policy that indexes **geometry** data with **geospatialConfig** set to `geometry`:
113
+
114
+
```json
115
+
{
116
+
"indexingMode": "consistent",
117
+
"automatic": true,
118
+
"includedPaths": [
119
+
{
120
+
"path": "/*"
121
+
}
122
+
],
123
+
"excludedPaths": [
124
+
{
125
+
"path": "/\"_etag\"/?"
126
+
}
127
+
],
128
+
"spatialIndexes": [
129
+
{
130
+
"path": "/locations/*",
131
+
"types": [
132
+
"Point",
133
+
"LineString",
134
+
"Polygon",
135
+
"MultiPolygon"
136
+
],
137
+
"boundingBox": {
138
+
"xmin": -10,
139
+
"ymin": -20,
140
+
"xmax": 10,
141
+
"ymax": 20
142
+
}
143
+
}
144
+
]
145
+
}
146
+
```
147
+
148
+
The above indexing policy has a **boundingBox** of (-10, 10) for x coordinates and (-20, 20) for y coordinates. The container with the above indexing policy will index all Points, Polygons, MultiPolygons, and LineStrings that are entirely within this region.
149
+
150
+
> [!NOTE]
151
+
> If you try to add an indexing policy with a **boundingBox** to a container with `geography` data type, it will fail. You should modify the container's **geospatialConfig** to be `geometry` before adding a **boundingBox**. You can add data and modify the remainder of
152
+
> your indexing policy (such as the paths and types) either before or after selecting the geospatial data type for the container.
153
+
62
154
## Next steps
63
155
64
156
Now that you have learned how to get started with geospatial support in Azure Cosmos DB, next you can:
Copy file name to clipboardExpand all lines: articles/cosmos-db/sql-query-geospatial-intro.md
+9-2Lines changed: 9 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,10 @@ This article is an introduction to the geospatial functionality in Azure Cosmos
20
20
21
21
Spatial data describes the position and shape of objects in space. In most applications, these correspond to objects on the earth and geospatial data. Spatial data can be used to represent the location of a person, a place of interest, or the boundary of a city, or a lake. Common use cases often involve proximity queries, for example, "find all coffee shops near my current location."
22
22
23
-
Azure Cosmos DB's SQL API supports the **geography** data type. The **geography** type represents data in a round-earth coordinate system.
23
+
Azure Cosmos DB's SQL API supports two spatial data types: the **geometry** data type and the **geography** data type.
24
+
25
+
- The **geometry** type represents data in a Euclidean (flat) coordinate system
26
+
- The **geography** type represents data in a round-earth coordinate system.
24
27
25
28
## Supported data types
26
29
@@ -65,7 +68,11 @@ Spatial data types can be embedded in an Azure Cosmos DB document as shown in th
65
68
}
66
69
```
67
70
68
-
### Points in geography coordinate system
71
+
### Points in a geometry coordinate system
72
+
73
+
For the **geometry** data type, GeoJSON specification specifies the horizontal axis first and the vertical axis second.
74
+
75
+
### Points in a geography coordinate system
69
76
70
77
For the **geography** data type, GeoJSON specification specifies longitude first and latitude second. Like in other mapping applications, longitude and latitude are angles and represented in terms of degrees. Longitude values are measured from the Prime Meridian and are between -180 degrees and 180.0 degrees, and latitude values are measured from the equator and are between -90.0 degrees and 90.0 degrees.
0 commit comments